[Q] merging from one (kernel) stable to another?

[Q] merging from one (kernel) stable to another?

[Brian Foster]

  Whilst this question involves linux(-mips) kernel tree,
 it's a git(-related?) question, not a kernel question ....

  We are currently in the process of upgrading our embedded
 system from kernel 2.6.21(-ish) to at least 2.6.26.8;  and
 later, at some time in the future on to 2.6.3x or something.
 Going from 2.6.21 to .22 to .23 and so on to .26, then to
 .26.1 and so on to .26.8 is “easy” in the sense there are
 very few conflicts with our existing baseline (e.g., just
 2 or 3 in 2 or 3 files).

  .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master
     \              \       \           \      \
     .21-stable  .22-stable .23-stable   \     .27-stable
                                        .26.8
                                           \
                                           .26-stable

  But (using 2.6.21-stable and 2.6.22-stable as proxies),
 tests indicate that going from .26.8 to .27 or anything
 later will have numerous conflicts (100s? in more than
 30 files).  Thinking about it, this isn't too surprising
 since the -stable branches cherry-pick important/benign
 fixes from later revisions.

  What's frustrating is that in essentially all “conflict”
 cases, the resolution is simple:  Use the later version.
 Very few conflicts are caused by our local changes.  But
 the merge tool I used (‘tkdiff’ via ‘git mergetool’) for
 my tests doesn't seem to make that resolution an easy
 thing to do — I (seem to) have to manually check each
 and every conflict, which very quickly becomes tedious
 (read: error-prone).

  Is there a (relatively) easy way to manage this situation?
 Trying some internet searches didn't find much of anything,
 albeit just what to search for isn't too clear.

 Thanks for any suggestions (including “RFT<a named>M”).
cheers!
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

Re: [Q] merging from one (kernel) stable to another?

[Andreas Ericsson]

Brian Foster wrote:
>   Whilst this question involves linux(-mips) kernel tree,
>  it's a git(-related?) question, not a kernel question ....
> 
>   We are currently in the process of upgrading our embedded
>  system from kernel 2.6.21(-ish) to at least 2.6.26.8;  and
>  later, at some time in the future on to 2.6.3x or something.
>  Going from 2.6.21 to .22 to .23 and so on to .26, then to
>  .26.1 and so on to .26.8 is “easy” in the sense there are
>  very few conflicts with our existing baseline (e.g., just
>  2 or 3 in 2 or 3 files).
> 
>   .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master
>      \              \       \           \      \
>      .21-stable  .22-stable .23-stable   \     .27-stable
>                                         .26.8
>                                            \
>                                            .26-stable
> 
>   But (using 2.6.21-stable and 2.6.22-stable as proxies),
>  tests indicate that going from .26.8 to .27 or anything
>  later will have numerous conflicts (100s? in more than
>  30 files).  Thinking about it, this isn't too surprising
>  since the -stable branches cherry-pick important/benign
>  fixes from later revisions.
> 
>   What's frustrating is that in essentially all “conflict”
>  cases, the resolution is simple:  Use the later version.

The trouble is "essentially all", as opposed to "all". Git
can never know which of the conflicts are which, so it will
leave it all up to you.

A possibly better approach for you is to "git format-patch"
your own changes and apply them to a clean 2.6.26.8 tree
instead of trying to merge 2.6.26.8 into 2.6.21. That's
how we do such things where I work (although not with the
kernel), and it's working wonderfully (we had that multi-
conflict problem earlier too). Note that this will cause
you to either get a new branch-name for your release-
branch, or your current release-branch to get rebuilt.

Neither is actually horrible in this case, since you could
easily justify taking a flag-day when doing a kernel upgrade.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Q] merging from one (kernel) stable to another?

[Johannes Sixt]

Andreas Ericsson schrieb:
> A possibly better approach for you is to "git format-patch"
> your own changes and apply them to a clean 2.6.26.8 tree
> instead of trying to merge 2.6.26.8 into 2.6.21.

After you have successfully done *that*, you know how the resulting tree
must look like, and you give it a tag, say "like-this". If you really want
to have a merge, then you can just repeat the merge with your original
branch, at which time you will get tons of conflicts. Now you just 'git
checkout like-this -- .' and you have all your conflicts resolved in the
way you need them.

-- Hannes

Re: [Q] merging from one (kernel) stable to another?

[Brian Foster]

On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:
> Andreas Ericsson schrieb:
> > A possibly better approach for you is to "git format-patch"
> > your own changes and apply them to a clean 2.6.26.8 tree
> > instead of trying to merge 2.6.26.8 into 2.6.21.
[ I'm going from .21 to .26.8, so I think you've got that reversed? ]
> 
> After you have successfully done *that*, you know how the resulting
> tree must look like, and you give it a tag, say "like-this".
> If you really want to have a merge, then you can just repeat the
> merge with your original branch, at which time you will get tons
> of conflicts.  Now you just 'git checkout like-this -- .' and you
> have all your conflicts resolved in the way you need them.

Andreas & Hannes,

  Thanks for the suggestion.  I'll have to experiment,
 but off-the-top-of-my-head, I think I do want a merge,
 so that it's easier to track the history of individual
 local changes.  Having said that, I'm not entirely sure
 I follow your suggestions.  What I think you mean is:

  (1)  Create a patch which is all (local) changes
         (née diffs) from linux-mips.21 to our.21;
  (2)  Checkout linux-mips.26.8 (e.g.);
  (3)  Apply the patch created in (1), above;
  (4)  Tag the result `like-this';
  (5)  Checkout our.21;  and
  (6)  Merge with `like-this'.

 I admit that now that I write the steps out, it seems
 to make sense ....?   Am I understanding correctly?

  Thanks for the suggestions.  Other suggestions are also
 quite welcome.
cheers!
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

Re: [Q] merging from one (kernel) stable to another?

[Johannes Sixt]

Brian Foster schrieb:
> On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:
>> Andreas Ericsson schrieb:
>>> A possibly better approach for you is to "git format-patch"
>>> your own changes and apply them to a clean 2.6.26.8 tree
>>> instead of trying to merge 2.6.26.8 into 2.6.21.
> [ I'm going from .21 to .26.8, so I think you've got that reversed? ]
>> After you have successfully done *that*, you know how the resulting
>> tree must look like, and you give it a tag, say "like-this".
>> If you really want to have a merge, then you can just repeat the
>> merge with your original branch, at which time you will get tons
>> of conflicts.  Now you just 'git checkout like-this -- .' and you
>> have all your conflicts resolved in the way you need them.
> 
> Andreas & Hannes,
> 
>   Thanks for the suggestion.  I'll have to experiment,
>  but off-the-top-of-my-head, I think I do want a merge,
>  so that it's easier to track the history of individual
>  local changes.  Having said that, I'm not entirely sure
>  I follow your suggestions.  What I think you mean is:
> 
>   (1)  Create a patch which is all (local) changes
>          (née diffs) from linux-mips.21 to our.21;
>   (2)  Checkout linux-mips.26.8 (e.g.);
>   (3)  Apply the patch created in (1), above;

format-patch creates a patch series. You apply the whole series, e.g. with
'git am'. But for this workflow you could also just create a single patch
and apply it to linux-mips.26.8, just as you wrote.

The important point is that you forge this tree into the shape that you
finally want to have in the merge (that you will make later). At this
point you only have to deal with conflicts and regressions that arise from
your own changes, which makes your life much easier than if you also had
to deal with conflicts that are outside your own changes.

>   (4)  Tag the result `like-this';
>   (5)  Checkout our.21;  and
>   (6)  Merge with `like-this'.

No, you merge with linux-mips.26.8. This will again give you a lot of
conflicts. But you do

   (7) git checkout like-this -- .

that is, you overwrite the merge result (that has conflicts) with your
known-good tree called "like-this". This resolves all conflicts in the way
that you wanted them.

-- Hannes

Re: [Q] merging from one (kernel) stable to another?

[Andreas Ericsson]

Brian Foster wrote:
> On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:
>> Andreas Ericsson schrieb:
>>> A possibly better approach for you is to "git format-patch"
>>> your own changes and apply them to a clean 2.6.26.8 tree
>>> instead of trying to merge 2.6.26.8 into 2.6.21.
> [ I'm going from .21 to .26.8, so I think you've got that reversed? ]
>> After you have successfully done *that*, you know how the resulting
>> tree must look like, and you give it a tag, say "like-this".
>> If you really want to have a merge, then you can just repeat the
>> merge with your original branch, at which time you will get tons
>> of conflicts.  Now you just 'git checkout like-this -- .' and you
>> have all your conflicts resolved in the way you need them.
> 
> Andreas & Hannes,
> 
>   Thanks for the suggestion.  I'll have to experiment,
>  but off-the-top-of-my-head, I think I do want a merge,
>  so that it's easier to track the history of individual
>  local changes.  Having said that, I'm not entirely sure
>  I follow your suggestions.  What I think you mean is:
> 
>   (1)  Create a patch which is all (local) changes
>          (née diffs) from linux-mips.21 to our.21;

This is wrong. Create several git-patches, each containing
the equivalence of one commit (complete with diff, author
info and commit message).

>   (2)  Checkout linux-mips.26.8 (e.g.);
>   (3)  Apply the patch created in (1), above;

Except it'll be "apply the patches, re-creating history
as if it had been done with a different base from the
start".

>   (4)  Tag the result `like-this';
>   (5)  Checkout our.21;  and
>   (6)  Merge with `like-this'.
> 

Merge is not necessary.

>  I admit that now that I write the steps out, it seems
>  to make sense ....?   Am I understanding correctly?
> 

Almost. "git help format-patch" and "git help am" will get
you the rest of the way, I think.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Q] merging from one (kernel) stable to another?

[Brian Foster]

On Monday 30 March 2009 14:19:08 Johannes Sixt wrote:
> Brian Foster schrieb:
>[ ... ]
> >   Thanks for the suggestion.  I'll have to experiment,
> >  but off-the-top-of-my-head, I think I do want a merge,
> >  so that it's easier to track the history of individual
> >  local changes.  Having said that, I'm not entirely sure
> >  I follow your suggestions.  What I think you mean is:
> > 
> >   (1)  Create a patch which is all (local) changes
> >          (née diffs) from linux-mips.21 to our.21;
> >   (2)  Checkout linux-mips.26.8 (e.g.);
> >   (3)  Apply the patch created in (1), above;
> 
> format-patch creates a patch series.  You apply the whole series,
> e.g. with 'git am'. But for this workflow you could also just create
> a single patch and apply it to linux-mips.26.8, just as you wrote.

  Point taken.  I was being a bit sloppy there; I well know
 `git format-patch' (which we use in our internal workflow)
 generates a patch series, and that `git am' applies them.
 Apologies for the confusion.  Sorry!

> The important point is that you forge this tree into the shape that
> you finally want to have in the merge (that you will make later).
> At this point you only have to deal with conflicts and regressions
> that arise from your own changes, which makes your life much easier
> than if you also had to deal with conflicts that are outside your
> own changes.

  Gottcha.  Thanks for clarifying.

> >   (4)  Tag the result `like-this';
> >   (5)  Checkout our.21;  and
> >   (6)  Merge with `like-this'.
> 
> No, you merge with linux-mips.26.8. This will again give you a lot
> of conflicts. But you do
> 
>    (7) git checkout like-this -- .
> 
> that is, you overwrite the merge result (that has conflicts) with
> your known-good tree called "like-this". This resolves all conflicts
> in the way that you wanted them.

  Ah!  Neat.  I think I get it (er, git it?) now ....
 Many thanks for your patient and very helpful replies!
cheers!
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

Re: [Q] merging from one (kernel) stable to another?

[Brian Foster]

On Monday 30 March 2009 14:19:11 Andreas Ericsson wrote:
> Brian Foster wrote:
> >[ ... ]
> >   (1)  Create a patch which is all (local) changes
> >          (née diffs) from linux-mips.21 to our.21;
> 
> This is wrong.  Create several git-patches, each containing
> the equivalence of one commit (complete with diff, author
> info and commit message).

  Yes, I was being sloppy there.  Internally, we use both
 `git format-patch' and `git am', but have a bad(?) habit
 of referring to a patch series as “a patch”.  Apologies
 for the confusion.  Sorry!

> >   (2)  Checkout linux-mips.26.8 (e.g.);
> >   (3)  Apply the patch created in (1), above;
> 
> Except it'll be "apply the patches, re-creating history
> as if it had been done with a different base from the
> start".

  Yes.

> >   (4)  Tag the result `like-this';
> >   (5)  Checkout our.21;  and
> >   (6)  Merge with `like-this'.
> 
> Merge is not necessary.

  <Shrugs/>  I'll going to try in both ways (with and without
 merging) to better understand just what the results are like.

> >  I admit that now that I write the steps out, it seems
> >  to make sense ....?   Am I understanding correctly?
> 
> Almost. "git help format-patch" and "git help am" will get
> you the rest of the way, I think.

  ;-)   Well, I did say “RTF<a named>M” is useful....!

  Many thanks for your patient and very helpful replies.
cheers!
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

Re: [Q] merging from one (kernel) stable to another?

[Andreas Ericsson]

Brian Foster wrote:
> On Monday 30 March 2009 14:19:11 Andreas Ericsson wrote:
>> Brian Foster wrote:
> 
>>>   (4)  Tag the result `like-this';
>>>   (5)  Checkout our.21;  and
>>>   (6)  Merge with `like-this'.
>> Merge is not necessary.
> 
>   <Shrugs/>  I'll going to try in both ways (with and without
>  merging) to better understand just what the results are like.

If you get the tree into the state you want and simply want to
connect the histories, you can do

  git merge -s ours $other_branch

which will record the tree from the current commit as the tree
for the merge-commit (ie, all changes from $other_branch are
thrown away, and the merge always succeeds without conflicts).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Q] merging from one (kernel) stable to another?

[Ping Yin]

On Mon, Mar 30, 2009 at 5:33 PM, Andreas Ericsson <ae@op5.se> wrote:
> Brian Foster wrote:
>>
>>  Whilst this question involves linux(-mips) kernel tree,
>>  it's a git(-related?) question, not a kernel question ....
>>
>>  We are currently in the process of upgrading our embedded
>>  system from kernel 2.6.21(-ish) to at least 2.6.26.8;  and
>>  later, at some time in the future on to 2.6.3x or something.
>>  Going from 2.6.21 to .22 to .23 and so on to .26, then to
>>  .26.1 and so on to .26.8 is “easy” in the sense there are
>>  very few conflicts with our existing baseline (e.g., just
>>  2 or 3 in 2 or 3 files).
>>
>>  .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master
>>     \              \       \           \      \
>>     .21-stable  .22-stable .23-stable   \     .27-stable
>>                                        .26.8
>>                                           \
>>                                           .26-stable
>>
>>  But (using 2.6.21-stable and 2.6.22-stable as proxies),
>>  tests indicate that going from .26.8 to .27 or anything
>>  later will have numerous conflicts (100s? in more than
>>  30 files).  Thinking about it, this isn't too surprising
>>  since the -stable branches cherry-pick important/benign
>>  fixes from later revisions.
>>
>>  What's frustrating is that in essentially all “conflict”
>>  cases, the resolution is simple:  Use the later version.
>
> The trouble is "essentially all", as opposed to "all". Git
> can never know which of the conflicts are which, so it will
> leave it all up to you.
>
> A possibly better approach for you is to "git format-patch"
> your own changes and apply them to a clean 2.6.26.8 tree
> instead of trying to merge 2.6.26.8 into 2.6.21.

Or just (say, always use rebase instead of merge)

git rebase -i 2.6.26.8 --onto 2.6.27

Re: [Q] merging from one (kernel) stable to another?

[Daniel Barkalow]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2135 bytes --]

On Mon, 30 Mar 2009, Brian Foster wrote:

>   Whilst this question involves linux(-mips) kernel tree,
>  it's a git(-related?) question, not a kernel question ....
> 
>   We are currently in the process of upgrading our embedded
>  system from kernel 2.6.21(-ish) to at least 2.6.26.8;  and
>  later, at some time in the future on to 2.6.3x or something.
>  Going from 2.6.21 to .22 to .23 and so on to .26, then to
>  .26.1 and so on to .26.8 is “easy” in the sense there are
>  very few conflicts with our existing baseline (e.g., just
>  2 or 3 in 2 or 3 files).
> 
>   .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master
>      \              \       \           \      \
>      .21-stable  .22-stable .23-stable   \     .27-stable
>                                         .26.8
>                                            \
>                                            .26-stable
> 
>   But (using 2.6.21-stable and 2.6.22-stable as proxies),
>  tests indicate that going from .26.8 to .27 or anything
>  later will have numerous conflicts (100s? in more than
>  30 files).  Thinking about it, this isn't too surprising
>  since the -stable branches cherry-pick important/benign
>  fixes from later revisions.

Why are you going from .26.8 to .27? Based on the -stable policy, there 
should be no reason not to skip .26.x between .26 and .27. In fact, it's 
not unlikely that merging both .26.8 and .27 will introduce bugs when the 
same issue was fixed in different places in the two branches: a narrow 
patch to paper over the identified problem in -stable and an intrusive 
patch to change some API to make simpler code correct in the mainline.

That is, the correct way of merging changes from -stable with the latest 
mainline series is always to take the mainline version, even if the 
-stable changes don't conflict at all.

It should actually be ideal to just merge your local changes directly with 
the mainline kernel you want to end up using. But you might want to merge 
first with earlier mainline kernels in order to get fewer or easier 
conflicts per step.

	-Daniel
*This .sig left intentionally blank*

Re: [Q] merging from one (kernel) stable to another?

[Uwe Kleine-König]

On Mon, Mar 30, 2009 at 10:24:08AM +0200, Brian Foster wrote:
>   Whilst this question involves linux(-mips) kernel tree,
>  it's a git(-related?) question, not a kernel question ....
> 
>   We are currently in the process of upgrading our embedded
>  system from kernel 2.6.21(-ish) to at least 2.6.26.8;  and
>  later, at some time in the future on to 2.6.3x or something.
>  Going from 2.6.21 to .22 to .23 and so on to .26, then to
>  .26.1 and so on to .26.8 is “easy” in the sense there are
>  very few conflicts with our existing baseline (e.g., just
>  2 or 3 in 2 or 3 files).
> 
>   .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master
>      \              \       \           \      \
>      .21-stable  .22-stable .23-stable   \     .27-stable
>                                         .26.8
>                                            \
>                                            .26-stable
> 
>   But (using 2.6.21-stable and 2.6.22-stable as proxies),
>  tests indicate that going from .26.8 to .27 or anything
>  later will have numerous conflicts (100s? in more than
>  30 files).  Thinking about it, this isn't too surprising
>  since the -stable branches cherry-pick important/benign
>  fixes from later revisions.
Assuming you have your master on top of .21-stable and want to go to
.26-stable, the following might work better for you:

	$ git checkout -b mydot26stable .26-stable
	$ git merge -s ours .21-stable
	$ git checkout master
	$ git merge mydot26stable	

Note this is not tested, just came to my mind...

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Re: [Q] merging from one (kernel) stable to another?

[Kris Shannon]

2009/3/30 Andreas Ericsson <ae@op5.se>
>
> Brian Foster wrote:
>>
>>  Whilst this question involves linux(-mips) kernel tree,
>>  it's a git(-related?) question, not a kernel question ....
>>
...
>>  But (using 2.6.21-stable and 2.6.22-stable as proxies),
>>  tests indicate that going from .26.8 to .27 or anything
>>  later will have numerous conflicts (100s? in more than
>>  30 files).  Thinking about it, this isn't too surprising
>>  since the -stable branches cherry-pick important/benign
>>  fixes from later revisions.
>>
>>  What's frustrating is that in essentially all “conflict”
>>  cases, the resolution is simple:  Use the later version.
>
> The trouble is "essentially all", as opposed to "all". Git
> can never know which of the conflicts are which, so it will
> leave it all up to you.

git mailing list <git@vger.kernel.org>

What you could do is something like:

git checkout -b mystable-27 linux-2.6.27-stable
git merge -s ours linux-2.6.26-stable
git checkout local-changes-26
git merge mystable-27

The extra merge might allow git to distinguish between 26->27
conflicts and conflicts due to your local-changes.

BTW, when doing these merges between release branches you
probably want to increase merge.renamelimit.

Re: [Q] merging from one (kernel) stable to another?

[Brian Foster]

On Monday 30 March 2009 19:31:18 Daniel Barkalow wrote:
> On Mon, 30 Mar 2009, Brian Foster wrote:
> >   Whilst this question involves linux(-mips) kernel tree,
> >  it's a git(-related?) question, not a kernel question ....
> > 
> >   We are currently in the process of upgrading our embedded
> >  system from kernel 2.6.21(-ish) to at least 2.6.26.8;  and
> >  later, at some time in the future on to 2.6.3x or something.
> >  Going from 2.6.21 to .22 to .23 and so on to .26, then to
> >  .26.1 and so on to .26.8 is “easy” in the sense there are
> >  very few conflicts with our existing baseline (e.g., just
> >  2 or 3 in 2 or 3 files).
> > 
> >   .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master
> >      \              \       \           \      \
> >      .21-stable  .22-stable .23-stable   \     .27-stable
> >                                         .26.8
> >                                            \
> >                                            .26-stable
> > 
> >   But (using 2.6.21-stable and 2.6.22-stable as proxies),
> >  tests indicate that going from .26.8 to .27 or anything
> >  later will have numerous conflicts (100s? in more than
> >  30 files).  Thinking about it, this isn't too surprising
> >  since the -stable branches cherry-pick important/benign
> >  fixes from later revisions.
> 
> Why are you going from .26.8 to .27? Based on the -stable policy,
> there should be no reason not to skip .26.x between .26 and .27.

Daniel,

  That's a good question!  The policy to-date has been to
 ignore the -stable branches entirely, and go from release
 to release; i.e., .21 to .22 to ... to .26 to .27 et al.
 We (deliberately!) stay several releases behind (being
 bang-up-to-date isn't too important to our market/product,
 but having a robust secure system is extremely important).

  The current feeling is we should probably be moving from
 -stable to -stable, i.e., .21-stable to .22-stable to ...
 to .26-stable and later to .27-stable and so on.  This is
 based, in part, on observing the changes that are in -stable
 and realizing some of them are highly desirable.  This new
 idea/plan of going from -stable to -stable can change if
 there's a good reason.  It's currently in a state of flux.

  So I somewhat incorrectly described the thinking, mixing
 up our historical practice with the proposed new policy.
 In my defense, my I point out that we are particularly
 interested in some MIPS changes on .26-stable, and, at the
 the moment, have decided to not go to .27 for this cycle.
 (Admittedly, with the release of .29, the decision not to
 go to .27 has been challenged, but the issue hasn't been
 looked into in any detail (yet? as far as I know).)

  Anyways, good catch!  I take your point.  Many thanks.

>                                                            In fact, it's
> not unlikely that merging both .26.8 and .27 will introduce bugs when the
> same issue was fixed in different places in the two branches: a narrow
> patch to paper over the identified problem in -stable and an intrusive
> patch to change some API to make simpler code correct in the mainline.
> 
> That is, the correct way of merging changes from -stable with the latest
> mainline series is always to take the mainline version, even if the
> -stable changes don't conflict at all.

  Yep!  We don't want to merge changes from -stable
 into master (mainline).  That was a mistake in my
 description.  Again, thanks for pointing it out.

> It should actually be ideal to just merge your local changes directly with
> the mainline kernel you want to end up using. But you might want to merge
> first with earlier mainline kernels in order to get fewer or easier
> conflicts per step.

  Indeed.  We are progressing one release at a time.
 (I've been insisting on this!)  However, given we're
 not targeting .27 or later at this cycle, and that
 we know there are changes on .26-stable we want/need,
 it's (almost) a dead cert our next release will be
 based on some point in .26-stable (I'm using .26.8
 as a proxy as it's the latest (when I checked) tag
 on .26-stable).

  Things are in flux, and suggestions are certainly
 welcome.  Thanks for your very helpful observations.

cheers!
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com