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
@@ -3168,13 +3168,14 @@
- Do not commit to anything under the
- src/contrib,
- src/crypto, or
- src/sys/contrib trees without
+ Do not commit to contributed software without
explicit approval from the respective
maintainers.
+
+
+ Avoid private technical discussions.
+ As noted, breaking some of these rules can be grounds for
@@ -3328,12 +3329,6 @@
look at the repository logs for the files
in question and see if someone has been working recently
or predominantly in that area.
-
- Other areas of &os; fall under the control of someone
- who manages an overall category of &os; evolution, such as
- internationalization or networking. See https://www.FreeBSD.org/administration.html
- for more information on this.
@@ -3463,55 +3458,73 @@
Test your changes before committing them.
-
- 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,
+ This may sound obvious, but the requirements are not
+ always obvious. Make sure that
+ make tinderbox 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
&os;
- Internal Page 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.
+ Internal Page for a list of available
+ resources to help test.
- Do not commit to anything under the
- src/contrib,
- src/crypto, and
- src/sys/contrib trees without
+ Do not commit to contributed software without
explicit approval from the respective
maintainers.
+ Contributed software is anything under the
+ src/contrib,
+ src/crypto, or
+ src/sys/contrib trees.
+
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
- explicit approval from the maintainer
- (or you are the maintainer), do not
- commit there!
+ 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.
-
- 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
- not commit there by yourself!
+ 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.
+
+ 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.
+
+
+
+ Avoid private technical discussions.
+
+ Discussing technical topics in public is almost always
+ better than not. &os; is an Open Source project for which
+ Open is as important as writing
+ source code. Default to public unless there is an
+ explicit and clear reason for it to be private.
+
+ People who are not a part of the immediate convertion
+ will be interested in both the result, and the motivation
+ for how that decision was made.
+
+ This default applies to both private emails between
+ developers, and the internal adminstrative lists (such as
+ &a.developers;.) This does not provide the right to
+ reveal private conversations without permission, but you
+ encouraged to withhold a reply until the requestor asks in
+ a more public forum.
+
+ It is worth reading the section of
+ Producing Open Source on this topic.
- Contact the &a.core; if you wish to take up
- maintainership of an unmaintained part of the tree.
@@ -4433,6 +4446,11 @@
adding a patch fixing a buffer overflow.
+
+ Minor version changes that do nothing but fix
+ security or crash-related issues.
+
+
Adding/fixing
CONFLICTS.
@@ -5058,28 +5076,6 @@
Miscellaneous Questions
-
-
- Why are trivial or cosmetic changes to files on a
- vendor branch a bad idea?
-
-
-
-
-
- From now on, every new vendor release of that file
- will need to have patches merged in by hand.
-
-
-
- From now on, every new vendor release of that file
- will need to have patches
- verified by hand.
-
-
-
-
-
How do I add a new file to a branch?