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

Source string Read only

(itstool) path: sect1/para
Context English State
The FreeBSD developers mailing list is for the exclusive use of FreeBSD committers. To develop FreeBSD, committers must have the ability to openly discuss matters that will be resolved before they are publicly announced. Frank discussions of work in progress are not suitable for open publication and may harm FreeBSD.
All FreeBSD committers are expected not to not publish or forward messages from the FreeBSD developers mailing list outside the list membership without permission of all of the authors. Violators will be removed from the FreeBSD developers mailing list, resulting in a suspension of commit privileges. Repeated or flagrant violations may result in permanent revocation of commit privileges.
This list is <emphasis>not</emphasis> intended as a place for code reviews or for any technical discussion. In fact using it as such hurts the FreeBSD Project as it gives a sense of a closed list where general decisions affecting all of the FreeBSD using community are made without being <quote>open</quote>. Last, but not least <emphasis>never, never ever, email the FreeBSD developers mailing list and CC:/BCC: another FreeBSD list</emphasis>. Never, ever email another FreeBSD email list and CC:/BCC: the FreeBSD developers mailing list. Doing so can greatly diminish the benefits of this list.
SSH Quick-Start Guide
If you do not wish to type your password in every time you use <citerefentry><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>, and you use keys to authenticate, <citerefentry><refentrytitle>ssh-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry> is there for your convenience. If you want to use <citerefentry><refentrytitle>ssh-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry>, make sure that you run it before running other applications. X users, for example, usually do this from their <filename>.xsession</filename> or <filename>.xinitrc</filename>. See <citerefentry><refentrytitle>ssh-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details.
Generate a key pair using <citerefentry><refentrytitle>ssh-keygen</refentrytitle><manvolnum>1</manvolnum></citerefentry>. The key pair will wind up in your <filename>$HOME/.ssh/</filename> directory.
Only <acronym>ECDSA</acronym>, <acronym>Ed25519</acronym> or <acronym>RSA</acronym> keys are supported.
Send your public key (<filename>$HOME/.ssh/id_ecdsa.pub</filename>, <filename>$HOME/.ssh/id_ed25519.pub</filename>, or <filename>$HOME/.ssh/id_rsa.pub</filename>) to the person setting you up as a committer so it can be put into <filename><replaceable>yourlogin</replaceable></filename> in <filename>/etc/ssh-keys/</filename> on <systemitem>freefall</systemitem>.
Now <citerefentry><refentrytitle>ssh-add</refentrytitle><manvolnum>1</manvolnum></citerefentry> can be used for authentication once per session. It prompts for the private key's pass phrase, and then stores it in the authentication agent (<citerefentry><refentrytitle>ssh-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry>). Use <command>ssh-add -d</command> to remove keys stored in the agent.
Test with a simple remote command: <command>ssh freefall.FreeBSD.org ls /usr</command>.
For more information, see <package>security/openssh-portable</package>, <citerefentry><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>ssh-add</refentrytitle><manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>ssh-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>ssh-keygen</refentrytitle><manvolnum>1</manvolnum></citerefentry>, and <citerefentry><refentrytitle>scp</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
For information on adding, changing, or removing <citerefentry><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry> keys, see <uri xlink:href="https://wiki.freebsd.org/clusteradm/ssh-keys">this article</uri>.
<trademark class="registered">Coverity</trademark> Availability for FreeBSD Committers
All FreeBSD developers can obtain access to <application>Coverity</application> analysis results of all FreeBSD Project software. All who are interested in obtaining access to the analysis results of the automated <application>Coverity</application> runs, can sign up at <uri xlink:href="http://scan.coverity.com/">Coverity Scan</uri>.
The FreeBSD wiki includes a mini-guide for developers who are interested in working with the <trademark class="registered">Coverity</trademark> analysis reports: <uri xlink:href="https://wiki.freebsd.org/CoverityPrevent">https://wiki.freebsd.org/CoverityPrevent</uri>. Please note that this mini-guide is only readable by FreeBSD developers, so if you cannot access this page, you will have to ask someone to add you to the appropriate Wiki access list.
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.

Loading…

No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: sect1/para
Flags
read-only
Source string location
article.translate.xml:3315
String age
a year ago
Source string age
a year ago
Translation file
articles/committers-guide.pot, string 651