From: Jesse Barnes <jbarnes@...>
Subject: Re: Linux v2.6.27-rc1
Date: Jul 29, 12:27 pm 2008

On Monday, July 28, 2008 8:23 pm Linus Torvalds wrote:
> Much of -rc1 was in linux-next, but certainly not everything. We'll see
> how that whole thing ends up evolving - it certainly didn't solve all
> problems, and there was some bickering about things that weren't there
> (and some things that mostly were ;), but maybe it helped.

I think linux-next has been a *huge* help.  It's been great at catching merge 
conflicts and build bugs (though not so much when you don't use it[1]!), and 
Stephen is really easy to work with.  So I, for one, would love to see it 
continue.

Jesse

[1] http://marc.info/?t=121699085400001&r=1&w=2
--


From: Linus Torvalds <torvalds@...>
Subject: Re: Linux v2.6.27-rc1
Date: Jul 29, 12:59 pm 2008

On Tue, 29 Jul 2008, Jesse Barnes wrote:
> 
> I think linux-next has been a *huge* help.  It's been great at catching merge 
> conflicts and build bugs (though not so much when you don't use it[1]!), and 
> Stephen is really easy to work with.  So I, for one, would love to see it 
> continue.

I don't think anybody wants it to go away. The question in my mind is more 
along the way of how/whether it should be changed. There was some 
bickering about patches that weren't there, and some about how _partial_ 
series were there but then the finishing touches broke things.

I don't personally really think that it's reasonable to expect everything 
to be in -next (but hey, I'm willing to be convinced otherwise). And don't 
get me wrong - it certainly wouldn't bother _me_ to have everything go 
through next, since it just makes it likelier that I have less to worry 
about.

BUT. I do think 'next' as it is has a few issues that either need to be 
fixed (unlikely - it's not the point of next) or just need to be aired as 
issues and understood:

 - I don't think it does 'quality control', and I think that's pretty 
   fundamental.

   Now, admittedly I don't look much at the patches of people I trust 
   either (that's what the whole point of that 'trust' is, after all - to 
   make me not be the part that limits development speed), but that's 
   still different from 'largely automated merging'.

   So I _do_ check the things that aren't obvious "maintainer works on his 
   own subsystem" or are so core that I really feel like I need to know 
   what's up. I seldom actually say "that's so broken that I refuse to 
   pull it", but I tend to do that a couple of times per release.

   That may not sound like much, but it's enough to make me worry about 
   'next'. I worry that 'it has been in next' has become a code-word for 
   "pull this, because it's good", and I'm not at all convinced that 
   'next' sees any real critical checking.

 - I don't think the 'next' thing works as well for the occasional 
   developer that just has a few patches pending as it works for subsystem 
   maintainers that are used to it.

   IOW, I think 'next' needs enough infrastructure setup from the 
   developer side that I don't think it's reasonable for _everything_ to 
   go through next. And that in turn means that I'm not entirely thrilled 
   when people then complain "that wasn't in next". I think people should 
   accept that not everything will be in next.

But I don't think either of the above issues is a 'problem' - I just think 
they should be acknowledged. I think 'next' is a good way for the big 
subsystem developers to be able to see problems early, but I really hope 
that nobody will _ever_ see next as a "that's the way into Linus' tree", 
because for the above two reasons I do not think it can really work that 
way.

			Linus
--


From: Andrew Morton <akpm@...>
Subject: Re: Linux v2.6.27-rc1
Date: Jul 30, 5:03 am 2008

On Tue, 29 Jul 2008 09:59:18 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:

>  - I don't think the 'next' thing works as well for the occasional 
>    developer that just has a few patches pending as it works for subsystem 
>    maintainers that are used to it.

Those people's patches are in -mm, which now holds maybe 100 or more
"trees", many of which are small or empty.

My project within the next couple of weeks is to get most of that
material into linux-next.  Stephen will be involved ;)

>    IOW, I think 'next' needs enough infrastructure setup from the 
>    developer side that I don't think it's reasonable for _everything_ to 
>    go through next.

True.  But

a) some of the problematic changes which we've seen simply _should_
   have been in linux-next.  Some of them were even coming from
   developers whose trees are already in linux-next.

b) A lot of the bugs which hit your tree would have been quickly
   found in linux-next too.


But it's all shuffling deckchairs, really.  Are we actually merging
better code as a reasult of all of this?  Are we being more careful and
reviewing better and testing better?

Don't think so.

> And that in turn means that I'm not entirely thrilled 
>    when people then complain "that wasn't in next". I think people should 
>    accept that not everything will be in next.

Oh sure.  But it depends on the _reason_ why it wasn't in linux-next. 
If the reason is a good one then fine.  But if the reason is "I was too
slack", or "I only wrote it five minutes ago" then the system is good,
and the developer isn't.

--


From: Roland Dreier <rdreier@...>
Subject: Re: Linux v2.6.27-rc1
Date: Jul 29, 1:31 pm 2008

>    That may not sound like much, but it's enough to make me worry about 
 >    'next'. I worry that 'it has been in next' has become a code-word for 
 >    "pull this, because it's good", and I'm not at all convinced that 
 >    'next' sees any real critical checking.

I've been mentioning that my trees have been in next as code for, "I
don't think this should break the build or clash too badly with anything
else."  And next has been useful to me on several occasions for catching
that sort of problem before things hit mainline.

 - R.
--