[committer guide] update rules for contrib software.

- Most notably don't require talking to core@ to take on maintainership.
- Merge an FAQ into the main body of the text
- Wordsmith
- Remove references to CVS

Approved by:	core
This commit is contained in:
Eitan Adler 2018-08-16 05:04:47 +00:00
parent fde8f57fc8
commit 93b15fee8d
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=52130

View file

@ -3185,10 +3185,7 @@ Relnotes: yes</programlisting>
</listitem>
<listitem>
<para>Do not commit to anything under the
<filename>src/contrib</filename>,
<filename>src/crypto</filename>, or
<filename>src/sys/contrib</filename> trees without
<para>Do not commit to contributed software without
<emphasis>explicit</emphasis> approval from the respective
maintainers.</para>
</listitem>
@ -3495,34 +3492,38 @@ Relnotes: yes</programlisting>
</listitem>
<listitem>
<para>Do not commit to anything under the
<filename>src/contrib</filename>,
<filename>src/crypto</filename>, and
<filename>src/sys/contrib</filename> trees without
<para>Do not commit to contributed software without
<emphasis>explicit</emphasis> approval from the respective
maintainers.</para>
<para>Contributed software is anything under the
<filename>src/contrib</filename>,
<filename>src/crypto</filename>, or
<filename>src/sys/contrib</filename> trees.</para>
<para>The trees mentioned above are for contributed software
usually imported onto a vendor branch. Committing
something there, even if it does not 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>
something there may cause unnecessary headaches
when importing newer versions of the software. As a
general consider sending patches upstream to the vendor.
Patches may be committed to FreeBSD first with permission
of the maintainer.</para>
<!-- FIXME: this paragraph should be rewritten -->
<para>Please note that this does not mean you should not try
to improve the software in question; you are still more
than welcome to do so. Ideally, submit your
patches to the vendor. If your changes are
&os;-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>Reasons for modifying upstream software range from
wanting strict control over a tightly coupled dependency
to lack of portability in the canonical
repository's distribution of their code. Regardless of the
reason, effort to minimize the maintenance burden of
fork is helpful to fellow maintainers. Avoid committing
trivial or cosmetic changes to files
since it makes every merge thereafter more
difficult: such patches need to be manually re-verified
every import.</para>
<para>Contact the &a.core; if you wish to take up
maintainership of an unmaintained part of the tree.</para>
<para>If a particular piece of software lacks a maintainer,
you're encouraged to take up owership. If you're unsure
of the current maintainership email &a.arch; and
ask.</para>
</listitem>
</orderedlist>
</sect2>
@ -5088,28 +5089,6 @@ Do you want to commit? (no = start a shell) [y/n]</screen>
<title>Miscellaneous Questions</title>
<qandaset>
<qandaentry>
<question>
<para>Why are trivial or cosmetic changes to files on a
vendor branch a bad idea?</para>
</question>
<answer>
<itemizedlist>
<listitem>
<para>From now on, every new vendor release of that file
will need to have patches merged in by hand.</para>
</listitem>
<listitem>
<para>From now on, every new vendor release of that file
will need to have patches
<emphasis>verified</emphasis> by hand.</para>
</listitem>
</itemizedlist>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>How do I add a new file to a branch?</para>