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
next prev parent 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