lkml.org 
[lkml]   [2005]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFD: Kernel release numbering
On Wed, Mar 02, 2005 at 05:20:49PM -0800, Andrew Morton wrote:
> Dave Jones <davej@redhat.com> wrote:
> >
> > So what was broken with the 2.6.8.1 type of 'hotfix kernel' release ?
>
> That's an alternative, of course.
>
> But that _is_ a branch, and does need active forward- and (mainly)
> backward-porting work.
>
> There's nothing wrong with it per-se, but it becomes a "stabilised version
> of the kernel.org tree" or even a "production version of the kernel.org
> tree". In other words it's somewhere on the line between the mainline
> kernel.org tree and a distribution. How far along that line should it
> be positioned?

In an ideal world, we'd see a single 'y' release of 2.6.x.y, but if x+1 takes
too long to be released, bits of x+1 should also appear in x.y+1
The only question in my mind is 'how critical does a bug have to be to
justify a .y release. Once a new 'x' release comes out, the previous x.y
would likely no longer get any further fixes (unless someone decides the
new 'x' sucked so bad).

Linus using bitkeeper should actually remove most of the pain from this
multiple branch thing though. If fixes alternatively get checked into x.y
and new development goes into x+1, x+1 could do a daily pull of x.y
Thus saving the having to check in fixes to two seperate branches.
(which really really sucks under some SCMs).

Dave

-
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:10    [W:0.433 / U:13.172 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site