lkml.org 
[lkml]   [2005]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: starting with 2.7
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@tmr.com)
"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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.348 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site