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 @@ Do not commit to anything under the src/contrib, src/crypto, or - src/sys/contrib trees without + src/sys/contrib, or + vendor + trees without explicit approval from the respective maintainers. @@ -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. - - 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 +3459,83 @@ 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 + Do not directly commit to anything under src/contrib, - src/crypto, and + src/crypto, or src/sys/contrib trees without explicit approval from the respective maintainers. 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. - Contact the &a.core; if you wish to take up - maintainership of an unmaintained part of the tree. + 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. It is worth reading the section of + Producing Open Source on this topic. The most important portion is + reproduced below: + +
+ 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: + + 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. + + The discussion will train youin + 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. + + The discussion and its conclusions will be available + in public archives forever after, enabling future + discussions to avoid retracing the same steps. +
+ + The rule is: default to public unless there is an + explicit reason for it to be private. @@ -4433,6 +4457,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 +5087,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?