Page MenuHomeFreeBSD
Files F157777434

D16080.id44698.diff
No OneTemporary
Actions

D16080.id44698.diff
View Options

Index: en_US.ISO8859-1/articles/committers-guide/article.xml
===================================================================
--- en_US.ISO8859-1/articles/committers-guide/article.xml
+++ en_US.ISO8859-1/articles/committers-guide/article.xml
@@ -3171,7 +3171,9 @@
<para>Do not commit to anything under the
<filename>src/contrib</filename>,
<filename>src/crypto</filename>, or
- <filename>src/sys/contrib</filename> trees without
+ <filename>src/sys/contrib</filename>, or
+ <filename>vendor</filename>
+ trees without
<emphasis>explicit</emphasis> approval from the respective
maintainers.</para>
</listitem>
@@ -3328,12 +3330,6 @@
look at the repository logs for the files
in question and see if someone has been working recently
or predominantly in that area.</para>
-
- <para>Other areas of &os; fall under the control of someone
- who manages an overall category of &os; evolution, such as
- internationalization or networking. See <link
- xlink:href="&url.base;/administration.html">https://www.FreeBSD.org/administration.html</link>
- for more information on this.</para>
</listitem>
<listitem>
@@ -3463,55 +3459,83 @@
<listitem>
<para>Test your changes before committing them.</para>
- <!-- XXX Needs update re sparc64 + pc98
- Also, needs more details on which machines are available for testing
- -->
- <para>This may sound obvious, but if it really were so
- obvious then we probably would not see so many cases of
- people clearly not doing this. If your changes are to the
- kernel, make sure you can still compile both GENERIC and
- LINT. If your changes are anywhere else, make sure you
- can still make world. If your changes are to a branch,
+ <para>This may sound obvious, but the requirements are not
+ always obvious. Make sure that
+ <command>make tinderbox</command> still passes. Some
+ changes may pass on one architecture but will fail on
+ another. Seemingly small changes, such as printf format
+ strings, are often the cause of build failures. If your
+ changes are to a branch,
make sure your testing occurs with a machine which is
- running that code. If you have a change which also may
- break another architecture, be sure and test on all
- supported architectures. Please refer to the
+ running that code.
+ Refer to the
<link xlink:href="https://www.FreeBSD.org/internal/">&os;
- Internal Page</link> for a list of available resources.
- As other architectures are added to the &os; supported
- platforms list, the appropriate shared testing resources
- will be made available.</para>
+ Internal Page</link> for a list of available
+ resources to help test.</para>
</listitem>
<listitem>
- <para>Do not commit to anything under the
+ <para>Do not directly commit to anything under
<filename>src/contrib</filename>,
- <filename>src/crypto</filename>, and
+ <filename>src/crypto</filename>, or
<filename>src/sys/contrib</filename> trees without
<emphasis>explicit</emphasis> approval from the respective
maintainers.</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 for
+ when importing newer versions of the software. Strongly
+ 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>Avoid comitting 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>
+
+ <listitem>
+ <para>Avoid private technical discussions.</para>
+
+ <para>Discussing technical topics in public is almost always
+ better than not. &os; is an Open Source project for which
+ <emphasis>Open</emphasis> is as important as writing
+ source code. It is worth reading the section of
+ <link xlink:href="https://producingoss.com/en/setting-tone.html#avoid-private-discussions">Producing Open Source</link> on this topic. The most important portion is
+ reproduced below:</para>
+
+ <blockquote>
+ <para>As slow and cumbersome as public discussion can be,
+ it's almost always preferable in the long run. Public
+ discussion has beneficial side effects that will last
+ beyond whatever ephemeral technical question was at
+ issue:</para>
+
+ <para>The discussion will help train and educate new
+ developers. You never know how many eyes are watching
+ the conversation; even if most people don't participate,
+ many may be lurking silently, gleaning information.</para>
+
+ <para>The discussion will train <emphasis>you</emphasis>in
+ the art of explaining technical issues to people who are
+ not as familiar as you are. This is a skill that requires
+ practice, and you can't get that practice by talking to
+ people who already know what you know.</para>
+
+ <para>The discussion and its conclusions will be available
+ in public archives forever after, enabling future
+ discussions to avoid retracing the same steps.</para>
+ </blockquote>
+
+ <para>The rule is: default to public unless there is an
+ explicit reason for it to be private.</para>
</listitem>
</orderedlist>
</sect2>
@@ -4433,6 +4457,11 @@
adding a patch fixing a buffer overflow.</para>
</listitem>
+ <listitem>
+ <para>Minor version changes that do nothing but fix
+ security or crash-related issues.</para>
+ </listitem>
+
<listitem>
<para>Adding/fixing
<varname>CONFLICTS</varname>.</para>
@@ -5058,28 +5087,6 @@
<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>

File Metadata

Mime Type
text/plain
Expires
Tue, May 26, 1:37 AM (15 h, 36 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
33522063
Default Alt Text
D16080.id44698.diff (7 KB)

Event Timeline