SubmittingPatches: explain why 'next' and above are inappropriate base

The 'next' branch is primarily meant to be a testing ground to make
sure that topics that are reasonably well done work well together.
Building a new work on it would mean everything that was already in
'next' must have graduated to 'master' before the new work can also
be merged to 'master', and that is why we do not encourage basing
new work on 'next'.

Helped-by: Linus Arver <linusa@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c500fb4398c2abb04568b004f9436d90db3b4d39..42ce0a5939c872da6b030e8b775055aa7a53b1de 100644 (file)
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -57,10 +57,14 @@ latest HEAD commit of `maint` or `master` based on the following cases:
 
 This also means that `next` or `seen` are inappropriate starting points
 for your work, if you want your work to have a realistic chance of
-graduating to `master`.  They are simply not designed to provide a
-stable base for new work, because they are (by design) frequently
-re-integrated with incoming patches on the mailing list and force-pushed
-to replace previous versions of these branches.
+graduating to `master`.  They are simply not designed to be used as a
+base for new work; they are only there to make sure that topics in
+flight work well together. This is why both `next` and `seen` are
+frequently re-integrated with incoming patches on the mailing list and
+force-pushed to replace previous versions of themselves. A topic that is
+literally built on top of `next` cannot be merged to `master` without
+dragging in all the other topics in `next`, some of which may not be
+ready.
 
 For example, if you are making tree-wide changes, while somebody else is
 also making their own tree-wide changes, your work may have severe