Source string Read only

(itstool) path: footnote/para
82/820
Context English State
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/>
Maintenance
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.
As of this writing, there were 269 committers in the project. When they commit a change to a branch, that constitutes a new release. It is very common for users in the community to track a particular branch. The immediate existence of a new release makes the changes widely available right away and allows for rapid feedback from the community. This also gives the community the response time they expect on issues that are of importance to them. This makes the community more engaged, and thus allows for more and better feedback that again spurs more maintenance and ultimately should create a better product.
Before making changes to code in parts of the tree that has a history unknown to the committer, the committer is required to read the commit logs to see why certain features are implemented the way they are in order not to make mistakes that have previously either been thought through or resolved.
Problem reporting
Before FreeBSD 10, FreeBSD included a problem reporting tool called <command>send-pr</command>. Problems include bug reports, feature requests, feature enhancements and notices of new versions of external software that are included in the project. Although <command>send-pr</command> is available, users and developers are encouraged to submit issues using our <link xlink:href="https://bugs.freebsd.org/submit/"> problem report form</link>.
Problem reports are sent to an email address where it is inserted into the Problem Reports maintenance database. A <xref linkend="role-bugbuster"/> classifies the problem and sends it to the correct group or maintainer within the project. After someone has taken responsibility for the report, the report is being analysed. This analysis includes verifying the problem and thinking out a solution for the problem. Often feedback is required from the report originator or even from the FreeBSD community. Once a patch for the problem is made, the originator may be asked to try it out. Finally, the working patch is integrated into the project, and documented if applicable. It there goes through the regular maintenance cycle as described in section <xref linkend="model-maintenance"/>. These are the states a problem report can be in: open, analyzed, feedback, patched, suspended and closed. The suspended state is for when further progress is not possible due to the lack of information or for when the task would require so much work that nobody is working on it at the moment.
Process summary: problem reporting
_ external ref='proc-pr' md5='__failed__'
<imageobject><imagedata fileref="proc-pr"/></imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Refer to paragraph below for a screen-reader friendly version.</phrase> </textobject>
A problem is reported by the report originator. It is then classified by a bugbuster and handed to the correct maintainer. They verify the problem and discuss the problem with the originator until they have enough information to create a working patch. This patch is then committed and the problem report is closed.
The roles included in this process are: <_:orderedlist-1/>
<citation><xref linkend="freebsd-handle-pr"/></citation>. <citation><xref linkend="freebsd-send-pr"/></citation>
Reacting to misbehavior

Loading…

No matching activity found.

Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: footnote/para
Flags
read-only
Source string location
book.translate.xml:1930
String age
a year ago
Source string age
a year ago
Translation file
books/dev-model.pot, string 284