Better explain what Reviewed by: and Approved by: means, in the committers
guide. This was discussed a bit on -developers today PR: 38631 Submitted by: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
This commit is contained in:
parent
4b70e9c63a
commit
163dc8b906
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=13535
1 changed files with 20 additions and 14 deletions
|
@ -579,11 +579,11 @@
|
|||
</itemizedlist>
|
||||
|
||||
<para>You will almost certainly get a conflict because
|
||||
of the <literal>$Id: article.sgml,v 1.127 2002-06-21 01:22:10 jmallett Exp $</literal> (or in FreeBSD's case,
|
||||
of the <literal>$Id: article.sgml,v 1.128 2002-07-02 00:04:18 trhodes Exp $</literal> (or in FreeBSD's case,
|
||||
<literal>$<!-- stop expansion -->FreeBSD<!-- stop expansion -->$</literal>) lines, so you will have to edit
|
||||
the file to resolve the conflict (remove the marker lines and
|
||||
the second <literal>$Id: article.sgml,v 1.127 2002-06-21 01:22:10 jmallett Exp $</literal> line, leaving the original
|
||||
<literal>$Id: article.sgml,v 1.127 2002-06-21 01:22:10 jmallett Exp $</literal> line intact).</para>
|
||||
the second <literal>$Id: article.sgml,v 1.128 2002-07-02 00:04:18 trhodes Exp $</literal> line, leaving the original
|
||||
<literal>$Id: article.sgml,v 1.128 2002-07-02 00:04:18 trhodes Exp $</literal> line intact).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
@ -2457,28 +2457,34 @@ cvs add: use 'cvs commit' to add this file permanently
|
|||
<row>
|
||||
<entry><literal>Submitted by:</literal></entry>
|
||||
<entry>The name and e-mail address of the person that
|
||||
submitted the fix.</entry>
|
||||
submitted the fix; for committers, just the username on
|
||||
the FreeBSD cluster.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>Reviewed by:</literal></entry>
|
||||
<entry>The name and e-mail address of the person or people
|
||||
that reviewed the change. If a patch was submitted to a
|
||||
mailing list for review, and the review was favorable,
|
||||
then just include the list name.</entry>
|
||||
that reviewed the change; for committers, just the
|
||||
username on the FreeBSD cluster. If a patch was
|
||||
submitted to a mailing list for review, and the review
|
||||
was favorable, then just include the list name.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>Approved by:</literal></entry>
|
||||
<entry>The name and e-mail address of the person or people
|
||||
that approved the change. It is customary to get prior
|
||||
approval for a commit if it is to an area of the tree to
|
||||
which you do not usually commit. In addition, during the
|
||||
run up to a new release all commits
|
||||
that approved the change; for committers, just the
|
||||
username on the FreeBSD cluster. It is customary to get
|
||||
prior approval for a commit if it is to an area of the
|
||||
tree to which you do not usually commit. In addition,
|
||||
during the run up to a new release all commits
|
||||
<emphasis>must</emphasis> be approved by the release
|
||||
engineer. If these are your first commits then you should
|
||||
have passed them past your mentor first for approval, and
|
||||
you should list your mentor.</entry>
|
||||
engineering team. If these are your first commits then
|
||||
you should have passed them past your mentor first, and
|
||||
you should list your mentor, as in
|
||||
``<replaceable>username-of-mentor</replaceable>
|
||||
<literal>(mentor)</literal>''.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
|
|
Loading…
Reference in a new issue