144 lines
6 KiB
XML
144 lines
6 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
|
|
"http://www.FreeBSD.org/XML/doc/share/xml/xhtml10-freebsd.dtd" [
|
|
<!ENTITY title "New Account Creation Procedure">
|
|
]>
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<title>&title;</title>
|
|
|
|
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
|
|
</head>
|
|
|
|
<body class="navinclude.docs">
|
|
|
|
<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. For some guidelines on how the
|
|
proposal itself should be written, please see <a
|
|
href="proposing-committers.html">a brief summary</a>.
|
|
</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 after voting is finished or when the timeout is hit.
|
|
The timeout for core@ and portmgr@ is set to 7 days while for doceng@ it is
|
|
14 days, however, as indicated, this is just a worst case and team members
|
|
may finish voting 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>username (lowercase a-z and 0-9)</p></li>
|
|
<li><p>Full Name (as would go in a GECOS field)</p></li>
|
|
<li><p>optional additional GECOS information (phone, location etc)</p></li>
|
|
<li><p>shell (sh, csh/tcsh, bash, zsh are available)</p></li>
|
|
<li><p>ssh V2 public key (<strong>version 2 ONLY</strong>)</p></li>
|
|
</ul>
|
|
|
|
<p>Any non-ASCII characters for the <em>Full Name</em> field should be encoded
|
|
in UTF-8. Be aware that we have very limited support for this and caution
|
|
that they are likely to be frequently corrupted. The number of characters
|
|
should kept to a minimum.</p>
|
|
|
|
<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 and username, the mentor's
|
|
name and what area the new committer will start to work in.
|
|
An entry should also be added to the <tt>mentors</tt> file in
|
|
the respective Subversion repository 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.</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.</p>
|
|
|
|
</body>
|
|
</html>
|