cfd9e12239
- Move includes.nav*.sgml to share/sgml/navibar.ent and
<lang>/share/sgml/nabibar.l10n.ent.
- Move includes.sgml and includes.xsl to
share/sgml/common.ent, share/sgml/header.ent, <lang>/share/sgml/l10n.ent,
and <lang>?share/sgml/header.l10n.ent.
- Move most of XSLT libraries to share/sgml/*.xsl and
<lang>/share/sgml/*.xsl.
- Move news.xml and other *.xml files for the similar purpose
to share/sgml/*.xml and <lang>/share/sgml/*.xml.
- Switch to use a custom DTD for HTML document. Now we use
"-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension", which is
HTML 4.01 + some entities previously pulled via
"<!ENTITY % includes SYSTEM "includes.sgml"> %includes;" line.
The location of entity file will be resolved by using catalog file.
- Add DOCTYPE declearation to XML documents. This makes the followings
possible:
* Use of &foo; entities for SGML in an XML file instead of defining
{$foo} as the same content.
* &symbolic; entities for Latin characters.
- Duplicated information between SGML and XML, or English and
translated doc, has been removed as much as possible.
120 lines
4.6 KiB
Text
120 lines
4.6 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.18 2006/05/26 10:21:48 glebius 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; 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>
|