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
@@ -3480,24 +3480,25 @@
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,
- 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
+ This may sound obvious, but developers do occasionally
+ break the build. Merging a change tested against an older
+ base revision fail due to a mismerge. A change may work on
+ one architecture but fail to compile on others, often for
+ seemingly minor reasons such as &man.printf.3; format
+ strings. Use make tinderbox to compile
+ changes on all supported architectures before committing.
+ always obvious.
+
+ When committing changes to a stable or release branch,
+ test your changes on a machine running that branch. If
+ merging a change from HEAD which broke the build or
+ introduced regressions, include followup fixes from HEAD
+ in the merge as a single commit.
+
+ 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
+ testing resources.