Re: starting with 2.7

[Bill Davidsen]

Adrian Bunk wrote:
> On Thu, Jan 06, 2005 at 03:03:26PM +0100, Paolo Ciarrocchi wrote:
>
> > What's wrong in keeping the release management as is now plus
> > introducing a 2.6.X.Y series of kernels ?
> >
> > In short:
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=109882220123966&w=2
>
>
> Currently (2.6.10), there would have been 11 such branches.
>
> If a security vulnerability was found today, this meant backporting and 
> applying the patch to 11 different kernel versions, the oldest one being 
> more than one year old.
>
> With more 2.6 versions, there would be even more branches, and the 
> oldest ones becoming more and more different from the current codebase.
>
> You could at some point start dropping the oldest branches, but this 
> would mean a migration to a more recent branch for all users of this 
> branch.
>
> OTOH, if you migrated relatively late at 2.4.17 to the 2.4 branch, this 
> branch is still actively maintained today, more than 3 years later.

I don't think that's what he meant (I hope not) and I know it's not what 
I had in mind. What I was suggesting is that until 2.6.11 comes out, all 
patches which are fixes (existing feature doesn't work, oops, security 
issues, or other "unusable with the problem triggered" cases) would go 
into 2.6.10.N, where N would be a small number unless we had another 100 
day release cycle.

This wouldn't be a blank check to maintain a version forever, and since 
the patch from 2.6.10 to 2.6.11 will be against a 2.6.10 base there will 
not be a lot of rediffing beyond what's needed if someone submits a 
patch against -mm or -bk or whatever. It's not zero work, but it's small 
work.

When 2.6.11 came out, the 2.6.10.N effort would stop, or perhaps 
continue for a short time in the unlikely event that some huge security 
hole was found within the first week or so after 2.6.11. That seems to 
happen at most a few times a year. In general once 2.6.N+1 is out, 
2.6.N.x is frozen.

Since the mechanism is already in place to generate -bk versions against 
both the base and previous -bk version, I don't see any reason why both 
can't be available.

Unless I'm missing something this would involve only a small amount of 
work which wouldn't be done anyway, and would provide a bugfix path 
which people could use with a high probability of unwanted side effects.

--
   -bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/