Re: Slow DOWN, please!!!

[Jeff Garzik <jeff@garzik.org>]

Linus Torvalds wrote:
> 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.

linux-next is _supposed_ to be solely the stuff that is ready to be sent 
to you upon window-open.

The only thing that isn't reliable are the commit ids -- and that's at 
the request of a large majority of maintainers, who noted to Stephen R 
that the branch he was pulling from them might get rebased -- thus 
necessitating the daily tree regeneration.

So, I think a 'next' branch from you would open cans o worms:

- one more tree to test, and judging from linux-next and -mm it's tough 
to get developers to test more than just upstream

- is the value of holy penguin pee great enough to overcome this 
another-tree-to-test obstacle?

- opens all the debates about running parallel branches, such as, would 
it be better to /branch/ for 2.6.X-rc, and then keep going full steam on 
the trunk?  After all, the primary logic behind 2.6.X-rc is to only take 
bug fixes, theoretically focusing developers more on that task.  But now 
we are slowly undoing that logic, or at least openly admitting that has 
been the reality all along.

	Jeff