diff options
Diffstat (limited to 'en_US.ISO8859-1/htdocs/internal/new-account.xml')
| -rw-r--r-- | en_US.ISO8859-1/htdocs/internal/new-account.xml | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/en_US.ISO8859-1/htdocs/internal/new-account.xml b/en_US.ISO8859-1/htdocs/internal/new-account.xml new file mode 100644 index 0000000000..b2fa9f426d --- /dev/null +++ b/en_US.ISO8859-1/htdocs/internal/new-account.xml @@ -0,0 +1,139 @@ +<?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/sgml/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. + </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><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 and doc commit + bits, 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, + 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> + + + </body> +</html> |