- UTF-8 support is much better now - Document addition of committer to phabricator and moinmoin - v2 is the only common version of ssh now-a-days
		
			
				
	
	
		
			147 lines
		
	
	
	
		
			6 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
			
		
		
	
	
			147 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/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; UTF-8 encoded)</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</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 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>
 | 
						|
 | 
						|
  <h2>Additional Services</h2>
 | 
						|
 | 
						|
  <p>The mentor should add the new committer to the <a
 | 
						|
      href="https://wiki.freebsd.org/DevelopersGroup">Developers
 | 
						|
      group</a> on the wiki and to the <a
 | 
						|
      href="https://reviews.freebsd.org/project/view/3/">committer</a>
 | 
						|
      project on Phabricator.</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>
 |