1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD$">
<!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.</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 in <= 7 days. For them, timeout is set
at 7 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 (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 commit bits, an entry
should also be added to the <tt>mentors</tt> file in SVN 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>
&footer;
</body>
</html>
|
