Explain that src/contrib, src/crypto, and src/sys/contrib are off
limits without explicit maintainer approval. Asked about but thread drifted off into other matters on: developers@
This commit is contained in:
Dima Dorfman
parent
df4c942868
commit
b8a47158e4
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=9525
2 changed files with 84 additions and 8 deletions
en_US.ISO8859-1/articles/committers-guide
en_US.ISO_8859-1/articles/committers-guide
|
|
@ -19,7 +19,7 @@
|
|||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/articles/committers-guide/article.sgml,v 1.67 2001/05/13 15:44:20 nik Exp $</pubdate>
|
||||
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/articles/committers-guide/article.sgml,v 1.68 2001/05/29 19:29:25 gsutter Exp $</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>1999</year>
|
||||
|
|
@ -516,11 +516,11 @@
|
|||
</itemizedlist>
|
||||
|
||||
<para>You'll almost certainly get a conflict because
|
||||
of the <literal>$Id: article.sgml,v 1.68 2001-05-29 19:29:25 gsutter Exp $</literal> (or in FreeBSD's case,
|
||||
of the <literal>$Id: article.sgml,v 1.69 2001-06-02 05:45:59 dd Exp $</literal> (or in FreeBSD's case,
|
||||
<literal>$FreeBSD<!-- stop expansion -->$</literal>) lines, so you'll have to edit
|
||||
the file to resolve the conflict (remove the marker lines and
|
||||
the second <literal>$Id: article.sgml,v 1.68 2001-05-29 19:29:25 gsutter Exp $</literal> line, leaving the original
|
||||
<literal>$Id: article.sgml,v 1.68 2001-05-29 19:29:25 gsutter Exp $</literal> line intact).</para>
|
||||
the second <literal>$Id: article.sgml,v 1.69 2001-06-02 05:45:59 dd Exp $</literal> line, leaving the original
|
||||
<literal>$Id: article.sgml,v 1.69 2001-06-02 05:45:59 dd Exp $</literal> line intact).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -1319,6 +1319,15 @@ docs:Documentation Bug:nik:</programlisting>
|
|||
<listitem>
|
||||
<para>Test your changes before committing them.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don't commit to anything under the
|
||||
<filename>src/contrib</filename>,
|
||||
<filename>src/crypto</filename>, and
|
||||
<filename>src/sys/contrib</filename> trees without
|
||||
<emphasis>explicit</emphasis> approval from the respective
|
||||
maintainer(s).</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>As noted, breaking some of these rules can be grounds for
|
||||
|
|
@ -1635,6 +1644,35 @@ docs:Documentation Bug:nik:</programlisting>
|
|||
list, the appropriate shared testing resources will be
|
||||
made available.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don't commit to anything under the
|
||||
<filename>src/contrib</filename>,
|
||||
<filename>src/crypto</filename>, and
|
||||
<filename>src/sys/contrib</filename> trees without
|
||||
<emphasis>explicit</emphasis> approval from the respective
|
||||
maintainer(s).</para>
|
||||
|
||||
<para>The trees mentioned above are for contributed software
|
||||
usually imported onto a vendor branch. Committing something
|
||||
there, even if it doesn't take the file off the vendor branch,
|
||||
may cause unnecessary headaches for those responsible for
|
||||
maintaining that particular piece of software. Thus, unless
|
||||
you have <emphasis>explicit</emphasis> approval from the
|
||||
maintainer (or you are the maintainer), do
|
||||
<emphasis>not</emphasis> commit there!</para>
|
||||
|
||||
<para>Please note that this doesn't mean you shouldn't try to
|
||||
improve the software in question; you are still more than
|
||||
welcome to do so. Ideally, you should submit your patches to
|
||||
the vendor. If your changes are FreeBSD-specific, talk to the
|
||||
maintainer; they may be willing to apply them locally. But
|
||||
whatever you do, do <emphasis>not</emphasis> commit there by
|
||||
yourself!</para>
|
||||
|
||||
<para>Contact the &a.core; if you wish to take up maintainership
|
||||
of an unmaintained part of the tree.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/articles/committers-guide/article.sgml,v 1.67 2001/05/13 15:44:20 nik Exp $</pubdate>
|
||||
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/articles/committers-guide/article.sgml,v 1.68 2001/05/29 19:29:25 gsutter Exp $</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>1999</year>
|
||||
|
|
@ -516,11 +516,11 @@
|
|||
</itemizedlist>
|
||||
|
||||
<para>You'll almost certainly get a conflict because
|
||||
of the <literal>$Id: article.sgml,v 1.68 2001-05-29 19:29:25 gsutter Exp $</literal> (or in FreeBSD's case,
|
||||
of the <literal>$Id: article.sgml,v 1.69 2001-06-02 05:45:59 dd Exp $</literal> (or in FreeBSD's case,
|
||||
<literal>$FreeBSD<!-- stop expansion -->$</literal>) lines, so you'll have to edit
|
||||
the file to resolve the conflict (remove the marker lines and
|
||||
the second <literal>$Id: article.sgml,v 1.68 2001-05-29 19:29:25 gsutter Exp $</literal> line, leaving the original
|
||||
<literal>$Id: article.sgml,v 1.68 2001-05-29 19:29:25 gsutter Exp $</literal> line intact).</para>
|
||||
the second <literal>$Id: article.sgml,v 1.69 2001-06-02 05:45:59 dd Exp $</literal> line, leaving the original
|
||||
<literal>$Id: article.sgml,v 1.69 2001-06-02 05:45:59 dd Exp $</literal> line intact).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -1319,6 +1319,15 @@ docs:Documentation Bug:nik:</programlisting>
|
|||
<listitem>
|
||||
<para>Test your changes before committing them.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don't commit to anything under the
|
||||
<filename>src/contrib</filename>,
|
||||
<filename>src/crypto</filename>, and
|
||||
<filename>src/sys/contrib</filename> trees without
|
||||
<emphasis>explicit</emphasis> approval from the respective
|
||||
maintainer(s).</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>As noted, breaking some of these rules can be grounds for
|
||||
|
|
@ -1635,6 +1644,35 @@ docs:Documentation Bug:nik:</programlisting>
|
|||
list, the appropriate shared testing resources will be
|
||||
made available.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don't commit to anything under the
|
||||
<filename>src/contrib</filename>,
|
||||
<filename>src/crypto</filename>, and
|
||||
<filename>src/sys/contrib</filename> trees without
|
||||
<emphasis>explicit</emphasis> approval from the respective
|
||||
maintainer(s).</para>
|
||||
|
||||
<para>The trees mentioned above are for contributed software
|
||||
usually imported onto a vendor branch. Committing something
|
||||
there, even if it doesn't take the file off the vendor branch,
|
||||
may cause unnecessary headaches for those responsible for
|
||||
maintaining that particular piece of software. Thus, unless
|
||||
you have <emphasis>explicit</emphasis> approval from the
|
||||
maintainer (or you are the maintainer), do
|
||||
<emphasis>not</emphasis> commit there!</para>
|
||||
|
||||
<para>Please note that this doesn't mean you shouldn't try to
|
||||
improve the software in question; you are still more than
|
||||
welcome to do so. Ideally, you should submit your patches to
|
||||
the vendor. If your changes are FreeBSD-specific, talk to the
|
||||
maintainer; they may be willing to apply them locally. But
|
||||
whatever you do, do <emphasis>not</emphasis> commit there by
|
||||
yourself!</para>
|
||||
|
||||
<para>Contact the &a.core; if you wish to take up maintainership
|
||||
of an unmaintained part of the tree.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue