Date:	Wed, 30 Apr 2008 20:47:42 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Paul Mackerras <paulus@...ba.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>
Subject: Re: Slow DOWN, please!!!



On Thu, 1 May 2008, Paul Mackerras wrote:
> 
> Having things ready by the time the merge window opens is difficult
> when you don't know when the merge window is going to open.  OK, after
> you release a -rc6 or -rc7, we know it's close, but it could still be
> three weeks off at that point.  Or it could be tomorrow.

Well, if the tree is ready, you shouldn't need to care ;)

That said:

> By the way, if you do want to make that rule, then there's a really
> easy way to do it - just pull linux-next, and make that one pull be
> the entire merge window. :)  But please give us at least a week's
> notice that you're going to do that.

I'm not going to pull linux-next, because I hate how it gets rebuilt every 
time it gets done, so I would basically have to pick one at random, and 
then that would be it.

I also do actually try to spread the early pulls out a _bit_, so that 
if/when problems happen, there's some amount of information in the fact 
that something started showing up between -git2 and -git3.

HOWEVER.

One thing that was discussed when linux-next was starting up was whether I 
would maintain a next branch myself, that people could actually depend on 
(unlike linux-next, which gets rebuilt).

And while I could do that for really core infrastructure changes, I really 
would hate to see something like that become part of the flow - because 
I'd hope things that really require it should be so rare that it's not 
worth it for me to maintain a separate branch for it.

But there could be some kind of carrot here - maybe I could maintain a 
"next" branch myself, not for core infrastructure, but for stuff where the 
maintainer says "hey, I'm ready early, you can pull me into 'next' 
already".

In other words, it wouldn't be "core infrastructure", it would simply be 
stuff that you already know you'd send to me on the first day of the merge 
window. And if by maintaining a "next" branch I could encourage people to 
go early, _and_ let others perhaps build on it and sort out merge 
conflicts (which you can't do well on linux-next, exactly because it's a 
bit of a quick-sand and you cannot depend on merging the same order or 
even the same base in the end), maybe me having a 'next' branch would be 
worth it.

But it would have to be low-maintenance. Something I might open after 
-rc4, say, and something where I'd expect people to only ask me to pull 
_once_ (because they really are mostly ready, and can sort out the rest 
after the merge window), and if they have no open regressions (again, the 
"carrot" for good behaviour).

I'm not saying it's a great idea, but if that kind of flow makes sense to 
people, maybe it should be on the table as an idea or at least see if it 
might work.

But let's see how linux-next works out. Maybe all the subsystem 
maintainers can just get their tree in shape, see that it merges in 
linux-next, and not even need anything else. Then, when the merge window 
opens, if you're ready, just let me know.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists