Re: [Q] merging from one (kernel) stable to another?
On Monday 30 March 2009 19:31:18 Daniel Barkalow wrote:
Show 28 quoted lines
> 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.
Show 9 quoted lines
> 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