Source string Read only

(itstool) path: listitem/para
43/430
Context English State
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
Committing during code freezes without the approval of the Release Engineering team - 2 days
Committing to a security branch without approval - 2 days
Commit wars - 5 days to all participating parties
Impolite or inappropriate behavior - 5 days
<citation><xref linkend="freebsd-committer"/></citation> has a number of rules that committers should follow. However, it happens that these rules are broken. The following rules exist in order to be able to react to misbehavior. They specify what actions will result in how long a suspension of the committer's commit privileges. <_:itemizedlist-1/> <citation><xref linkend="ref-freebsd-trenches"/></citation>
For the suspensions to be efficient, any single core member can implement a suspension before discussing it on the <quote>core</quote> mailing list. Repeat offenders can, with a 2/3 vote by core, receive harsher penalties, including permanent removal of commit privileges. (However, the latter is always viewed as a last resort, due to its inherent tendency to create controversy.) All suspensions are posted to the <quote>developers</quote> mailing list, a list available to committers only.
It is important that you cannot be suspended for making technical errors. All penalties come from breaking social etiquette.
Hats involved in this process: <_:itemizedlist-1/>
Release engineering
The FreeBSD project has a Release Engineering team with a principal release engineer that is responsible for creating releases of FreeBSD that can be brought out to the user community via the net or sold in retail outlets. Since FreeBSD is available on multiple platforms and releases for the different architectures are made available at the same time, the team has one person in charge of each architecture. Also, there are roles in the team responsible for coordinating quality assurance efforts, building a package set and for having an updated set of documents. When referring to the release engineer, a representative for the release engineering team is meant.
When a release is coming, the FreeBSD project changes shape somewhat. A release schedule is made containing feature- and code-freezes, release of interim releases and the final release. A feature-freeze means no new features are allowed to be committed to the branch without the release engineers' explicit consent. Code-freeze means no changes to the code (like bugs-fixes) are allowed to be committed without the release engineers' explicit consent. This feature- and code-freeze is known as stabilising. During the release process, the release engineer has the full authority to revert to older versions of code and thus "back out" changes should they find that the changes are not suitable to be included in the release.
.0 releases are the first release of a major version. These are branched of the -CURRENT branch and have a significantly longer release engineering cycle due to the unstable nature of the -CURRENT branch
.X releases are releases of the -STABLE branch. They are scheduled to come out every 4 months.
.X.Y releases are security releases that follow the .X branch. These come out only when sufficient security fixes have been merged since the last release on that branch. New features are rarely included, and the security team is far more involved in these than in regular releases.
There are three different kinds of releases: <_:orderedlist-1/>
Many commercial vendors use these images to create CD-ROMs that are sold in retail outlets.
For releases of the -STABLE-branch, the release process starts 45 days before the anticipated release date. During the first phase, the first 15 days, the developers merge what changes they have had in -CURRENT that they want to have in the release to the release branch. When this period is over, the code enters a 15 day code freeze in which only bug fixes, documentation updates, security-related fixes and minor device driver changes are allowed. These changes must be approved by the release engineer in advance. At the beginning of the last 15 day period a release candidate is created for widespread testing. Updates are less likely to be allowed during this period, except for important bug fixes and security updates. In this final period, all releases are considered release candidates. At the end of the release process, a release is created with the new version number, including binary distributions on web sites and the creation of CD-ROM images. However, the release is not considered "really released" until a <xref linkend="tool-pgp"/>-signed message stating exactly that, is sent to the mailing list freebsd-announce; anything labelled as a "release" before that may well be in-process and subject to change before the PGP-signed message is sent. <_:footnote-1/>.
The releases of the -CURRENT-branch (that is, all releases that end with <quote>.0</quote>) are very similar, but with twice as long timeframe. It starts 8 weeks prior to the release with announcement of the release time line. Two weeks into the release process, the feature freeze is initiated and performance tweaks should be kept to a minimum. Four weeks prior to the release, an official beta version is made available. Two weeks prior to release, the code is officially branched into a new version. This version is given release candidate status, and as with the release engineering of -STABLE, the code freeze of the release candidate is hardened. However, development on the main development branch can continue. Other than these differences, the release engineering processes are alike.
.0 releases go into their own branch and are aimed mainly at early adopters. The branch then goes through a period of stabilisation, and it is not until the <xref linkend="role-releng"/> decides the demands to stability have been satisfied that the branch becomes -STABLE and -CURRENT targets the next major version. While this for the majority has been with .1 versions, this is not a demand.

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: listitem/para
Flags
read-only
Source string location
book.translate.xml:2145
String age
a year ago
Source string age
a year ago
Translation file
books/dev-model.pot, string 303