lkml.org 
[lkml]   [2005]   [Mar]   [2]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    DateWed, 2 Mar 2005 20:27:07 -0500
    FromDave Jones <>
    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    [from the cache]
    ©2003-2008