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

--