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

> "Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> +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).
>
> I think this is technically not optimal, but is good enough for the
> sake of simplicity and brevity[*].
> 
> [Footnote]
>
>  * An very old but still severe bug in tagged versions would want to
>    be fixed ideally not on top of 'maint' but on top of the latest
>    tagged version in the same maintenance track.  E.g. if the commit
>    X introduced the bug, you may ask "git describe --contains X" the
>    oldest version the commit appears in, say "v2.30.0-rc2-gXXXXXX".
>    Then you would run "git checkout -b fix v2.30.9" to start the
>    branch to fix it.

>> +* 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.
>
> "unstable" is not the primary reason why you shouldn't build on
> 'next'.  It is "your work, if queued on 'next', cannot be merged to
> 'master' without pulling all the other undercooked stuff still in
> 'next'", as you describe in the next paragraph.  But that is
> different from being unstable.  I'd suggest to use something like
> this instead:
>
> 	... not designed to be used as a base for new work---they
> 	are there only to make sure that topics in flight work well
> 	together.  A topic that is literally built on top of 'next'
> 	cannot be merged to 'master' without dragging all the other
> 	topics in 'next', some of which may not be ready.  In
> 	addition, `seen` is frequently re-integrated with incoming
> 	patches ...