Source string Read only

(itstool) path: sect1/para
443/4430
Context English State
Finally, all FreeBSD developers who are going to use <trademark class="registered">Coverity</trademark> are always encouraged to ask for more details and usage information, by posting any questions to the mailing list of the FreeBSD developers.
The FreeBSD Committers' Big List of Rules
Everyone involved with the FreeBSD project is expected to abide by the <emphasis>Code of Conduct</emphasis> available from <link xlink:href="@@URL_RELPREFIX@@/internal/code-of-conduct.html">https://www.FreeBSD.org/internal/code-of-conduct.html</link>. As committers, you form the public face of the project, and how you behave has a vital impact on the public perception of it. This guide expands on the parts of the <emphasis>Code of Conduct</emphasis> specific to committers.
Respect other committers.
Respect other contributors.
Discuss any significant change <emphasis>before</emphasis> committing.
Respect existing maintainers (if listed in the <varname>MAINTAINER</varname> field in <filename>Makefile</filename> or in <filename>MAINTAINER</filename> in the top-level directory).
Any disputed change must be backed out pending resolution of the dispute if requested by a maintainer. Security related changes may override a maintainer's wishes at the Security Officer's discretion.
Changes go to FreeBSD-CURRENT before FreeBSD-STABLE unless specifically permitted by the release engineer or unless they are not applicable to FreeBSD-CURRENT. Any non-trivial or non-urgent change which is applicable should also be allowed to sit in FreeBSD-CURRENT for at least 3 days before merging so that it can be given sufficient testing. The release engineer has the same authority over the FreeBSD-STABLE branch as outlined for the maintainer in rule #5.
Do not fight in public with other committers; it looks bad.
Respect all code freezes and read the <literal>committers</literal> and <literal>developers</literal> mailing lists in a timely manner so you know when a code freeze is in effect.
When in doubt on any procedure, ask first!
Test your changes before committing them.
Do not commit to contributed software without <emphasis>explicit</emphasis> approval from the respective maintainers.
As noted, breaking some of these rules can be grounds for suspension or, upon repeated offense, permanent removal of commit privileges. Individual members of core have the power to temporarily suspend commit privileges until core as a whole has the chance to review the issue. In case of an <quote>emergency</quote> (a committer doing damage to the repository), a temporary suspension may also be done by the repository meisters. Only a 2/3 majority of core has the authority to suspend commit privileges for longer than a week or to remove them permanently. This rule does not exist to set core up as a bunch of cruel dictators who can dispose of committers as casually as empty soda cans, but to give the project a kind of safety fuse. If someone is out of control, it is important to be able to deal with this immediately rather than be paralyzed by debate. In all cases, a committer whose privileges are suspended or revoked is entitled to a <quote>hearing</quote> by core, the total duration of the suspension being determined at that time. A committer whose privileges are suspended may also request a review of the decision after 30 days and every 30 days thereafter (unless the total suspension period is less than 30 days). A committer whose privileges have been revoked entirely may request a review after a period of 6 months has elapsed. This review policy is <emphasis>strictly informal</emphasis> and, in all cases, core reserves the right to either act on or disregard requests for review if they feel their original decision to be the right one.
In all other aspects of project operation, core is a subset of committers and is bound by the <emphasis>same rules</emphasis>. Just because someone is in core this does not mean that they have special dispensation to step outside any of the lines painted here; core's <quote>special powers</quote> only kick in when it acts as a group, not on an individual basis. As individuals, the core team members are all committers first and core second.
Details
This means that you need to treat other committers as the peer-group developers that they are. Despite our occasional attempts to prove the contrary, one does not get to be a committer by being stupid and nothing rankles more than being treated that way by one of your peers. Whether we always feel respect for one another or not (and everyone has off days), we still have to <emphasis>treat</emphasis> other committers with respect at all times, on public forums and in private email.
Being able to work together long term is this project's greatest asset, one far more important than any set of changes to the code, and turning arguments about code into issues that affect our long-term ability to work harmoniously together is just not worth the trade-off by any conceivable stretch of the imagination.
To comply with this rule, do not send email when you are angry or otherwise behave in a manner which is likely to strike others as needlessly confrontational. First calm down, then think about how to communicate in the most effective fashion for convincing the other persons that your side of the argument is correct, do not just blow off some steam so you can feel better in the short term at the cost of a long-term flame war. Not only is this very bad <quote>energy economics</quote>, but repeated displays of public aggression which impair our ability to work well together will be dealt with severely by the project leadership and may result in suspension or termination of your commit privileges. The project leadership will take into account both public and private communications brought before it. It will not seek the disclosure of private communications, but it will take it into account if it is volunteered by the committers involved in the complaint.
All of this is never an option which the project's leadership enjoys in the slightest, but unity comes first. No amount of code or good advice is worth trading that away.
You were not always a committer. At one time you were a contributor. Remember that at all times. Remember what it was like trying to get help and attention. Do not forget that your work as a contributor was very important to you. Remember what it was like. Do not discourage, belittle, or demean contributors. Treat them with respect. They are our committers in waiting. They are every bit as important to the project as committers. Their contributions are as valid and as important as your own. After all, you made many contributions before you became a committer. Always remember that.
Consider the points raised under <xref linkend="respect"/> and apply them also to contributors.
The repository is not where changes are initially submitted for correctness or argued over, that happens first in the mailing lists or by use of the Phabricator service. The commit will only happen once something resembling consensus has been reached. This does not mean that permission is required before correcting every obvious syntax error or manual page misspelling, just that it is good to develop a feel for when a proposed change is not quite such a no-brainer and requires some feedback first. People really do not mind sweeping changes if the result is something clearly better than what they had before, they just do not like being <emphasis>surprised</emphasis> by those changes. The very best way of making sure that things are on the right track is to have code reviewed by one or more other committers.
When in doubt, ask for review!
Respect existing maintainers if listed.
Many parts of FreeBSD are not <quote>owned</quote> in the sense that any specific individual will jump up and yell if you commit a change to <quote>their</quote> area, but it still pays to check first. One convention we use is to put a maintainer line in the <filename>Makefile</filename> for any package or subtree which is being actively maintained by one or more people; see <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/developers-handbook/policies.html">https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/policies.html</link> for documentation on this. Where sections of code have several maintainers, commits to affected areas by one maintainer need to be reviewed by at least one other maintainer. In cases where the <quote>maintainer-ship</quote> of something is not clear, look at the repository logs for the files in question and see if someone has been working recently or predominantly in that area.
This may be hard to swallow in times of conflict (when each side is convinced that they are in the right, of course) but a version control system makes it unnecessary to have an ongoing dispute raging when it is far easier to simply reverse the disputed change, get everyone calmed down again and then try to figure out what is the best way to proceed. If the change turns out to be the best thing after all, it can be easily brought back. If it turns out not to be, then the users did not have to live with the bogus change in the tree while everyone was busily debating its merits. People <emphasis>very</emphasis> rarely call for back-outs in the repository since discussion generally exposes bad or controversial changes before the commit even happens, but on such rare occasions the back-out should be done without argument so that we can get immediately on to the topic of figuring out whether it was bogus or not.
Changes go to FreeBSD-CURRENT before FreeBSD-STABLE unless specifically permitted by the release engineer or unless they are not applicable to FreeBSD-CURRENT. Any non-trivial or non-urgent change which is applicable should also be allowed to sit in FreeBSD-CURRENT for at least 3 days before merging so that it can be given sufficient testing. The release engineer has the same authority over the FreeBSD-STABLE branch as outlined in rule #5.
This is another <quote>do not argue about it</quote> issue since it is the release engineer who is ultimately responsible (and gets beaten up) if a change turns out to be bad. Please respect this and give the release engineer your full cooperation when it comes to the FreeBSD-STABLE branch. The management of FreeBSD-STABLE may frequently seem to be overly conservative to the casual observer, but also bear in mind the fact that conservatism is supposed to be the hallmark of FreeBSD-STABLE and different rules apply there than in FreeBSD-CURRENT. There is also really no point in having FreeBSD-CURRENT be a testing ground if changes are merged over to FreeBSD-STABLE immediately. Changes need a chance to be tested by the FreeBSD-CURRENT developers, so allow some time to elapse before merging unless the FreeBSD-STABLE fix is critical, time sensitive or so obvious as to make further testing unnecessary (spelling fixes to manual pages, obvious bug/typo fixes, etc.) In other words, apply common sense.
Changes to the security branches (for example, <literal>releng/9.3</literal>) must be approved by a member of the Security Officer Team <email>security-officer@FreeBSD.org</email>, or in some cases, by a member of the Release Engineering Team <email>re@FreeBSD.org</email>.

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: sect1/para
Flags
read-only
Source string location
article.translate.xml:3428
String age
a year ago
Source string age
a year ago
Translation file
articles/committers-guide.pot, string 666