linux-kernel - Re: Linux v2.6.27-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0807290945030.3334@nehalem.linux-foundation.org>
Date:	Tue, 29 Jul 2008 09:59:18 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: Linux v2.6.27-rc1

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/