diff options
author | Eitan Adler <eadler@FreeBSD.org> | 2018-08-16 05:04:47 +0000 |
---|---|---|
committer | Eitan Adler <eadler@FreeBSD.org> | 2018-08-16 05:04:47 +0000 |
commit | 93b15fee8d803e760d6982348fa3231f95028da2 (patch) | |
tree | b375073829583ac442bbcbf3396f7d49cb24f342 /en_US.ISO8859-1/articles/committers-guide | |
parent | fde8f57fc825bd207a17f4a27e587b31491d769b (diff) |
Notes
Diffstat (limited to 'en_US.ISO8859-1/articles/committers-guide')
-rw-r--r-- | en_US.ISO8859-1/articles/committers-guide/article.xml | 77 |
1 files changed, 28 insertions, 49 deletions
diff --git a/en_US.ISO8859-1/articles/committers-guide/article.xml b/en_US.ISO8859-1/articles/committers-guide/article.xml index 87cc74e38f..5548c749b6 100644 --- a/en_US.ISO8859-1/articles/committers-guide/article.xml +++ b/en_US.ISO8859-1/articles/committers-guide/article.xml @@ -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> - - <!-- 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>Contact the &a.core; if you wish to take up - maintainership of an unmaintained part of the tree.</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> + + <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>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> @@ -5090,28 +5091,6 @@ Do you want to commit? (no = start a shell) [y/n]</screen> <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> </question> |