134 lines
5.4 KiB
Text
134 lines
5.4 KiB
Text
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
|
|
<!ENTITY base CDATA "..">
|
|
<!ENTITY date "$FreeBSD: www/en/internal/new-account.sgml,v 1.23 2011/02/14 03:42:27 linimon Exp $">
|
|
<!ENTITY title "New Account Creation Procedure">
|
|
<!ENTITY % navinclude.docs "INCLUDE">
|
|
]>
|
|
|
|
<html>
|
|
&header;
|
|
|
|
<h2>Proposing a new committer</h2>
|
|
|
|
<p>If you want to propose a new committer, you should send the following
|
|
information to the appropriate entity:
|
|
</p>
|
|
<ul>
|
|
<li>Information on what established (FreeBSD) track record the
|
|
nominee has. This is <em>not</em> optional.</li>
|
|
<li>Who has volunteered to become the mentor for the new
|
|
committer.</li>
|
|
<li>The email address of the nominee (remarkably often this
|
|
is omitted).</li>
|
|
</ul>
|
|
|
|
<p>Any commit bit requests that do not follow the guidelines outlined
|
|
above will be delayed (at best) or earn you negative vibrations from the
|
|
respective team / team secretary.
|
|
</p>
|
|
|
|
<p>Responsible party for this procedure is:</p>
|
|
<ul>
|
|
<li>src --> core@</li>
|
|
<li>doc --> doceng@</li>
|
|
<li>ports --> portmgr@</li>
|
|
</ul>
|
|
|
|
<p> You will get ACK after the message is seen, and core@, doceng@ and portmgr@
|
|
will give you a response in <= 7 days. For them, timeout is set
|
|
at 7 days.
|
|
If voting finishes earlier then the nominator/nominee are informed
|
|
earlier.</p>
|
|
|
|
<h2>Authorizing A New Account</h2>
|
|
|
|
<p>Someone from the list below sends a PGP-signed email to
|
|
accounts@, the person assigned as the mentor to the new
|
|
committer, and copied to core@FreeBSD.org confirming the approval of
|
|
the new account. This email should include a link to this document
|
|
so the mentor/mentee know what is expected of them.</p>
|
|
|
|
<p>New account approvals are only valid from these PGP entities:</p>
|
|
|
|
<ul>
|
|
<li><p>core-secretary (for src commit bits)</p></li>
|
|
<li><p>portmgr-secretary (for ports commit bits)</p></li>
|
|
<li><p>doceng (for doc commit bits)</p></li>
|
|
</ul>
|
|
|
|
<p><i>NOTE: New account requests from anyone other than these
|
|
entities or requests signed with PGP keys other than from these
|
|
entities will not be acted upon. No exceptions. In case of
|
|
a new ports or doc committer the account request email should be
|
|
CC:-ed to core.</i></p>
|
|
|
|
<h2>Information Needed From The Mentor</h2>
|
|
|
|
<p>The person assigned as the new committers' mentor needs to collect
|
|
and send the following information to accounts@:</p>
|
|
|
|
<ul>
|
|
<li><p><tt>master.passwd</tt> line containing preferred username,
|
|
shell, and GECOS info (no password is needed)</p></li>
|
|
<li><p>ssh V2 public key (<strong>version 2 ONLY</strong>)</p></li>
|
|
</ul>
|
|
|
|
<p>The mentor is responsible for obtaining this information from the
|
|
new committer in a secure fashion, and providing it to accounts@ in
|
|
a secure fashion. PGP-signed email, with the mentor's public key
|
|
already committed to the Handbook, is the preferred method for the
|
|
mentor to send the information to accounts@. If this is impossible
|
|
for some reason an acceptable substitute is for the mentor to place
|
|
the account information in their home directory on freefall and then
|
|
tell accounts@ where to find it. We need to be sure the account
|
|
information really is coming from the Mentor and unsigned email is
|
|
not sufficient for this these days. Since accounts@ has no way to
|
|
verify anything from the new Committer this information needs to
|
|
be sent to accounts@ by the Mentor, not the new Committer.</p>
|
|
|
|
<h2>accounts@ Creates New Account</h2>
|
|
|
|
<p>accounts@ creates the new account with the above
|
|
information on the FreeBSD.org cluster and notifies the mentor and
|
|
the new committer.</p>
|
|
|
|
<h2>Mentor Activates New Committer's Commit Bit</h2>
|
|
|
|
<p>After the new committer confirms that the account works, the mentor
|
|
adds the new committer to the correct <tt>access</tt> file,
|
|
using an appropriate commit message. The commit message should at least
|
|
contain the committer's full name, the mentor's name and what area
|
|
the new committer will start to work in. For src commit bits, an entry
|
|
should also be added to the <tt>mentors</tt> file in SVN to indicate
|
|
the mentor relationship. Having done all that,
|
|
the new committer and mentor jointly go through the first commit
|
|
operations.</p>
|
|
|
|
<p>Reading the <a
|
|
href="&base;/doc/en_US.ISO8859-1/articles/committers-guide/index.html">Committer's
|
|
Guide</a> is considered a good first step for new committers, especially
|
|
the <a
|
|
href="&base;/doc/en_US.ISO8859-1/articles/committers-guide/conventions.html">Conventions
|
|
and Traditions</a> section.</p>
|
|
|
|
<h2>End Of Mentorship</h2>
|
|
|
|
<p>There is no pre-set duration for a mentorship. Once the mentor feels
|
|
the mentee is ready to 'fly solo' the mentor notifies the developer
|
|
community by removing the entry from the <tt>mentors</tt> file in SVN,
|
|
or via a forced commit to <tt>access</tt> in CVS with an appropriate
|
|
commit message.</p>
|
|
|
|
<h2>Transfer Of Mentorship</h2>
|
|
|
|
<p>Should a need arise to transfer mentorship for a committer
|
|
please email the responsible party, as described for a new account
|
|
proposal. Typically this request is rubberstamped as-is.
|
|
In Subversion, the <tt>mentors</tt> file should be updated.
|
|
In CVS, a forced commit to <tt>access</tt> with an appropriate commit
|
|
message is to be used to inform the world of the transfer.</p>
|
|
|
|
&footer;
|
|
|
|
</body>
|
|
</html>
|