The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: imageobject/imagedata This is a reference to an external file such as an image or video. When the file changes, the md5 hash will change to let you know you need to update your localized copy. The msgstr is not used at all. Set it to whatever you like once you have updated your copy of the file.
Context English State
_ external ref='proc-contrib' md5='__failed__'
<imageobject><imagedata fileref="proc-contrib"/></imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Refer to paragraphs below and above for a screen-reader friendly version.</phrase> </textobject>
The difference when a contributor makes a code contribution is that they submit the code through the Bugzilla interface. This report is picked up by the maintainer who reviews the code and commits it.
Hats included in this process are: <_:orderedlist-1/>
Core election
The first Core election was held September 2000
Core elections are held at least every two years. <_:footnote-1/> Nine core members are elected. New elections are held if the number of core members drops below seven. New elections can also be held should at least 1/3 of the active committers demand this.
When an election is to take place, core announces this at least 6 weeks in advance, and appoints an election manager to run the elections.
Only committers can be elected into core. The candidates need to submit their candidacy at least one week before the election starts, but can refine their statements until the voting starts. They are presented in the <link xlink:href="">candidates list</link>. When writing their election statements, the candidates must answer a few standard questions submitted by the election manager.
During elections, the rule that a committer must have committed during the 12 past months is followed strictly. Only these committers are eligible to vote.
When voting, the committer may vote once in support of up to nine nominees. The voting is done over a period of four weeks with reminders being posted on <quote>developers</quote> mailing list that is available to all committers.
The election results are released one week after the election ends, and the new core team takes office one week after the results have been posted.
Should there be a voting tie, this will be resolved by the new, unambiguously elected core members.
Votes and candidate statements are archived, but the archives are not publicly available.
Process summary: Core elections
_ external ref='proc-elections' md5='__failed__'
<imageobject><imagedata fileref="proc-elections"/></imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Refer to paragraph below for a screen-reader friendly version.</phrase> </textobject>
Core announces the election and selects an election manager who prepares the elections, and when ready, candidates can announce their candidacies through submitting their statements. The committers then vote. After the vote is over, the election results are announced and the new core team takes office.
Hats in core elections are: <_:itemizedlist-1/>
Development of new features
Within the project there are sub-projects that are working on new features. These projects are generally done by one person <citation><xref linkend="jorgensen2001"/></citation>. Every project is free to organise development as it sees fit. However, when the project is merged to the -CURRENT branch it must follow the project guidelines. When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch.
The requirements of the project are given by developer wishes, requests from the community in terms of direct requests by mail, Problem Reports, commercial funding for the development of features, or contributions by the scientific community. The wishes that come within the responsibility of a developer are given to that developer who prioritises their time between the request and their wishes. A common way to do this is maintain a TODO-list maintained by the project. Items that do not come within someone's responsibility are collected on TODO-lists unless someone volunteers to take the responsibility. All requests, their distribution and follow-up are handled by the <xref linkend="tool-bugzilla"/> tool.
Requirements analysis happens in two ways. The requests that come in are discussed on mailing lists, both within the main project and in the sub-project that the request belongs to or is spawned by the request. Furthermore, individual developers on the sub-project will evaluate the feasibility of the requests and determine the prioritisation between them. Other than archives of the discussions that have taken place, no outcome is created by this phase that is merged into the main project.
As the requests are prioritised by the individual developers on the basis of doing what they find interesting, necessary, or are funded to do, there is no overall strategy or prioritisation of what requests to regard as requirements and following up their correct implementation. However, most developers have some shared vision of what issues are more important, and they can ask for guidelines from the release engineering team.
More and more tests are however performed when building the system (<quote>make world</quote>). These tests are however a very new addition and no systematic framework for these tests have yet been created.
The verification phase of the project is two-fold. Before committing code to the current-branch, developers request their code to be reviewed by their peers. This review is for the most part done by functional testing, but also code review is important. When the code is committed to the branch, a broader functional testing will happen, that may trigger further code review and debugging should the code not behave as expected. This second verification form may be regarded as structural verification. Although the sub-projects themselves may write formal tests such as unit tests, these are usually not collected by the main project and are usually removed before the code is committed to the current branch. <_:footnote-1/>
sendmail and named are examples of code that has been merged from other platforms.
It is an advantage to the project to for each area of the source have at least one person that knows this area well. Some parts of the code have designated maintainers. Others have de-facto maintainers, and some parts of the system do not have maintainers. The maintainer is usually a person from the sub-project that wrote and integrated the code, or someone who has ported it from the platform it was written for. <_:footnote-1/> The maintainer's job is to make sure the code is in sync with the project the code comes from if it is contributed code, and apply patches submitted by the community or write fixes to issues that are discovered.
The main bulk of work that is put into the FreeBSD project is maintenance. <citation><xref linkend="jorgensen2001"/></citation> has made a figure showing the life cycle of changes.
Here <quote>development release</quote> refers to the -CURRENT branch while <quote>production release</quote> refers to the -STABLE branch. The <quote>pre-commit test</quote> is the functional testing by peer developers when asked to do so or trying out the code to determine the status of the sub-project. <quote>Parallel debugging</quote> is the functional testing that can trigger more review, and debugging when the code is included in the -CURRENT branch.


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: imageobject/imagedata This is a reference to an external file such as an image or video. When the file changes, the md5 hash will change to let you know you need to update your localized copy. The msgstr is not used at all. Set it to whatever you like once you have updated your copy of the file.
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/dev-model.pot, string 272