Re: [PATCH v2 5/5] SubmittingPatches: simplify guidance for choosing a starting point

> +There is one guiding principle for choosing the right starting point: in
> +general, always base your work on the oldest integration branch that
> +your change is relevant to (see "Merge upwards" in
> +linkgit:gitworkflows[7]).  What this principle means is that for the
> +vast majority of cases, the starting point for new work should be the
> +latest HEAD commit of `maint` or `master` based on the following cases:
> +
> +* If you are fixing bugs in the released version, use `maint` as the
> +  starting point (which may mean you have to fix things without using
> +  new API features on the cutting edge that recently appeared in
> +  `master` but were not available in the released version).

> +* Otherwise (such as if you are adding new features) use `master`.
> +
> +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.

> +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
> +overlap with the other person's work.  This situation may tempt you to
> +use `next` as your starting point (because it would have the other
> +person's work included in it), but doing so would mean you'll not only
> +depend on the other person's work, but all the other random things from
> +other contributors that are already integrated into `next`.  And as soon
> +as `next` is updated with a new version, all of your work will need to
> +be rebased anyway in order for them to be cleanly applied by the
> +maintainer.
> +
> +Under truly exceptional circumstances where you absolutely must depend
> +on a select few topic branches that are already in `next` but not in
> +`master`, you may want to create your own custom base-branch by forking
> +`master` and merging the required topic branches to it. You could then
> +work on top of this base-branch.  But keep in mind that this base-branch
> +would only be known privately to you.  So when you are ready to send
> +your patches to the list, be sure to communicate how you created it in
> +your cover letter.  This critical piece of information would allow
> +others to recreate your base-branch on their end in order for them to
> +try out your work.