a159ef4454
a lot of spam. - Do not use full form of accounts@ email address, to avoid spam harvesting of this address.
121 lines
4.7 KiB
Text
121 lines
4.7 KiB
Text
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
|
|
<!ENTITY base CDATA "..">
|
|
<!ENTITY date "$FreeBSD: www/en/internal/new-account.sgml,v 1.17 2006/02/22 13:28:14 joel Exp $">
|
|
<!ENTITY title "New Account Creation Procedure">
|
|
<!ENTITY % navincludes SYSTEM "../includes.navdocs.sgml"> %navincludes;
|
|
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
|
]>
|
|
|
|
<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; it has become
|
|
standard practice over the last couple of years.</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@ and doceng@
|
|
will give you a response in <= 7 days. For them, timeout is set
|
|
at 7 days. Timeout for portmgr@ is set at 14 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</p></li>
|
|
<li><p>portmgr-secretary</p></li>
|
|
<li><p>doceng</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 their account works, the mentor
|
|
activates the new committer's commit bit and guides them through the
|
|
rest of the initial process.</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 via a forced commit to <tt>access</tt> 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.
|
|
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>
|