Re: merge status

From: James Bottomley (James.Bottomley_at_SteelEye.com)
Date: 11/10/05

  • Next message: Willy Tarreau: "Re: Linux 2.4.32-rc3"
    To: Andrew Morton <akpm@osdl.org>
    Date:	Wed, 09 Nov 2005 19:24:00 -0500
    
    

    On Wed, 2005-11-09 at 15:01 -0800, Andrew Morton wrote:
    > James Bottomley <James.Bottomley@SteelEye.com> wrote:
    > >
    > > it's my contributors who drop me in it
    > > by leaving their patch sets until you declare a kernel, dumping the
    > > integration testing on me in whatever time window is left.
    >
    > Yes, I think I'm noticing an uptick in patches as soon as a kernel is
    > released.
    >
    > It's a bit irritating, and is unexpected (here, at least). I guess people
    > like to hold onto their work for as long as possible so when they release
    > it, it's in the best possible shape.

    Well ... I can guess how it goes:

    Manager: "2.6.x is out, are our patches in it"
    Developer: .oO(crap I forgot about this, better get my skates on)
               "No, but they will be in the next kernel"
                .oO(As long as I get them in the current merge window)

    > I guess all we can do is to encourage people to merge up when it's working,
    > not when it's time to merge it into mainline.

    OK ... I'd really like that, but I think in order to do that I think we
    have to have a tree that represents only everything that's going
    upstream. That would be a -mm but without the patches that aren't going
    to be included in the next release. I suppose we could do this today
    simply by making it the sum of all the git trees and nothing else. The
    closer this tree is to what mainline will be next release, the easier it
    will be to encourage people to test it.

    > One could just say "if I don't have it by the time 2.6.n is released, it
    > goes into 2.6.n+2", but that's probably getting outside the realm of
    > practicality.

    We could always try it. Practically the way to do this is to reduce the
    merge window down to a single day, but to do that you obviously have to
    give us prior notice of a 2.6.<x> release, which might be the
    impractical bit ...

    James

    -
    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/


  • Next message: Willy Tarreau: "Re: Linux 2.4.32-rc3"

    Relevant Pages

    • Re: 2.6.8-rc2 crashes
      ... I get my patches from ... >| kernel.org, either from the main Linus tree, or Andrews akpm tree. ... Additions to this message made by Gene Heskett are Copyright 2004, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.8-rc2 crashes
      ... I get my patches from ... |>| kernel.org, either from the main Linus tree, or Andrews akpm tree. ... |>| after a long session of doing something else that fails. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: new dev model (was Re: Default cache_hot_time value back to 10ms)
      ... >> Major developers such as David and Al don't have trees that see wide ... >> allow for stabilization of the main tree prior to relesae. ... That's 500 patches which are either non-bugfixes or minor ... 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/ ...
      (Linux-Kernel)
    • Re: RFD: Kernel release numbering
      ... > some patches that belong in the 2.6.X.Y tree go straight to you/Andrew, ... Think of how the -mm tree has evolved - with me and Andrew learning how ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: merge status
      ... > practicality. ... majos subsystem git trees too: where the maintainer tree is well enough ... well-defined target audiences. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)