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?