Re: merge status

[James Bottomley <James.Bottomley@SteelEye.com>]

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