Junio C Hamano [off-list ref] writes:

"Linus Arver via GitGitGadget" [off-list ref] writes:

quoted

+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.

In this example, are we using v2.30.9 as a starting point, not v2.30.0
because v2.30.9 is the latest tagged version that is in 'maint'? 

I think this nugget of knowledge should be included in a v3 of this
series. Will update.

quoted

+* 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 ...

Will update. Thanks.