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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
