Source string Read only

(itstool) path: section/para
625/6250
Context English State
Bugbuster
A person who will either find the right person to solve the problem, or close the PR if it is a duplicate or otherwise not an interesting one.
Mentor
A mentor is a committer who takes it upon them to introduce a new committer to the project, both in terms of ensuring the new committer's setup is valid, that the new committer knows the available tools required in their work, and that the new committer knows what is expected of them in terms of behavior.
Vendor
The person(s) or organisation whom external code comes from and whom patches are sent to.
Reviewers
People on the mailing list where the request for review is posted.
Processes
The following section will describe the defined project processes. Issues that are not handled by these processes happen on an ad-hoc basis based on what has been customary to do in similar cases.
Adding new and removing old committers
The Core team has the responsibility of giving and removing commit privileges to contributors. This can only be done through a vote on the core mailing list. The ports and documentation sub-projects can give commit privileges to people working on these projects, but have to date not removed such privileges.
Normally a contributor is recommended to core by a committer. For contributors or outsiders to contact core asking to be a committer is not well thought of and is usually rejected.
If the area of particular interest for the developer potentially overlaps with other committers' area of maintainership, the opinion of those maintainers is sought. However, it is frequently this committer that recommends the developer.
When a contributor is given committer status, they are assigned a mentor. The committer who recommended the new committer will, in the general case, take it upon themselves to be the new committers mentor.
When a contributor is given their commit bit, a <xref linkend="tool-pgp"/>-signed email is sent from either <xref linkend="role-core-secretary"/>, <xref linkend="role-ports-manager"/>, or nik@freebsd.org to both admins@freebsd.org, the assigned mentor, the new committer, and core confirming the approval of a new account. The mentor then gathers a password line, <xref linkend="tool-ssh2"/> public key, and PGP key from the new committer and sends them to <xref linkend="role-admin"/>. When the new account is created, the mentor activates the commit bit and guides the new committer through the rest of the initial process.
Process summary: adding a new committer
_ external ref='proc-add-committer' md5='__failed__'
<imageobject><imagedata fileref="proc-add-committer"/></imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject><phrase>Refer to paragraph below for a screen-reader friendly version.</phrase> </textobject>
When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is given commit privileges. If they recommend this to core, core will vote on this recommendation. If the vote is in favour, a mentor is assigned the new committer and the new committer has to email their details to the administrators for an account to be created. After this, the new committer is all set to make their first commit. By tradition, this is by adding their name to the committers list.
Recall that a committer is considered to be someone who has committed code during the past 12 months. However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked. <citation><xref linkend="freebsd-expiration-policy"/></citation> There are, however, no automatic procedures for doing this. For reactions concerning commit privileges not triggered by time, see <link linkend="process-reactions">section 1.5.8</link>.
Process summary: removing a committer
_ external ref='proc-rm-committer' md5='__failed__'
<imageobject><imagedata fileref="proc-rm-committer"/></imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Refer to paragraph below for a screen-reader friendly version.</phrase> </textobject>
When Core decides to clean up the committers list, they check who has not made a commit for the past 18 months. Committers who have not done so have their commit bits revoked and their account removed by the administrators.
It is also possible for committers to request that their commit bit be retired if for some reason they are no longer going to be actively committing to the project. In this case, it can also be restored at a later time by core, should the committer ask.
Roles in this process: <_:orderedlist-1/>
Committing code
The committing of new or modified code is one of the most frequent processes in the FreeBSD project and will usually happen many times a day. Committing of code can only be done by a <quote>committer</quote>. Committers commit either code written by themselves, code submitted to them, or code submitted through a <link linkend="model-pr">problem report</link>.
When code is written by the developer that is non-trivial, they should seek a code review from the community. This is done by sending mail to the relevant list asking for review. Before submitting the code for review, they should ensure it compiles correctly with the entire tree and that all relevant tests run. This is called <quote>pre-commit test</quote>. When contributed code is received, it should be reviewed by the committer and tested the same way.
When a change is committed to a part of the source that has been contributed from an outside <xref linkend="role-vendor"/>, the maintainer should ensure that the patch is contributed back to the vendor. This is in line with the open source philosophy and makes it easier to stay in sync with outside projects as the patches do not have to be reapplied every time a new release is made.

Loading…

User avatar None

New source string

FreeBSD Doc / books_dev-modelEnglish

New source string 5 months ago
Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: section/para
Flags
read-only
Source string location
book.translate.xml:1465
String age
5 months ago
Source string age
5 months ago
Translation file
books/dev-model.pot, string 234