mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: Linux v2.6.27-rc1
Date: Tue, 29 Jul 2008 09:59:18 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0807290945030.3334@nehalem.linux-foundation.org> (raw)
In-Reply-To: <200807290927.12101.jbarnes@virtuousgeek.org>



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

  reply	other threads:[~2008-07-29 17:03 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-29  3:23 Linus Torvalds
2008-07-29  4:01 ` Nick Piggin
2008-07-29  9:49 ` 2.6.27-rc1: zd1211rw association fails Alistair John Strachan
2008-07-29 10:09   ` Johannes Berg
2008-07-29 11:25     ` Alistair John Strachan
2008-07-29 11:26       ` Johannes Berg
2008-07-29 11:37         ` Hugh Dickins
2008-07-29 11:46         ` Kalle Valo
2008-07-29 11:55         ` Alistair John Strachan
2008-07-29 12:04     ` Theodore Tso
2008-07-29 12:09       ` Johannes Berg
2008-07-29 12:15         ` Johannes Berg
2008-07-29 15:18           ` Theodore Tso
2008-07-29 17:52           ` John W. Linville
2008-07-30  4:48             ` David Miller
2008-07-29 13:57 ` Oops in microcode sysfs registration, Alistair John Strachan
2008-07-29 16:22   ` Pekka Paalanen
2008-07-29 16:50     ` Alistair John Strachan
2008-07-30  9:07       ` Dmitry Adamushko
2008-07-30 10:35         ` Dmitry Adamushko
2008-07-30 13:28           ` Peter Oruba
2008-07-31 12:49           ` Alistair John Strachan
2008-07-31 16:56           ` Ingo Molnar
2008-07-31 19:52             ` Dmitry Adamushko
2008-07-31 19:55               ` Dmitry Adamushko
2008-07-29 16:27 ` Linux v2.6.27-rc1 Jesse Barnes
2008-07-29 16:59   ` Linus Torvalds [this message]
2008-07-29 17:31     ` Roland Dreier
2008-07-30  9:03     ` Andrew Morton
2008-07-31 22:22       ` Linux v2.6.27-rc1: linux-next Rafael J. Wysocki
2008-07-29 20:49 ` Linux v2.6.27-rc1: problem with firmware stuff Rafael J. Wysocki
2008-07-29 21:01   ` Rafael J. Wysocki
2008-07-29 21:01     ` Linus Torvalds
2008-07-29 22:26       ` David Woodhouse
2008-07-29 21:37 ` Linux v2.6.27-rc1 Sam Ravnborg
2008-07-29 21:42   ` Linus Torvalds
2008-07-29 21:59     ` Sam Ravnborg
2008-07-29 22:03       ` Linus Torvalds
2008-07-29 22:30         ` Sam Ravnborg
2008-07-29 22:03 ` Linux v2.6.27-rc1: fails to compile Grant Coady
2008-07-29 22:40   ` Frederik Deweerdt
2008-07-29 23:46     ` Grant Coady
2008-07-29 11:23 Linux v2.6.27-rc1 Martin Knoblauch
2008-07-29 11:57 ` Peter Zijlstra
2008-07-29 12:08 Martin Knoblauch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.1.10.0807290945030.3334@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome