linux-kernel - Re: [git pull] x86 updates for v2.6.30, final bits

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: <20090329011953.GA15450@elte.hu>
Date:	Sun, 29 Mar 2009 03:19:53 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Nick Piggin <npiggin@...e.de>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [git pull] x86 updates for v2.6.30, final bits


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Sat, 28 Mar 2009, Ingo Molnar wrote:
> > 
> > [ The sched.c bit is an odd one out: due to previous cpumask changes 
> >   it developed a dependency/conflict on the cpumask tree which 
> >   depended on the x86 tree. Should i have started a separate branch 
> >   for it? I didnt want to merge the x86 tree into the scheduler 
> >   tree. We had really excessive dependencies and cross-merges in
> >   this cycle around the x86 tree and i very much hope this is an
> >   exception
> 
> The problem is that you've been hoping for this "exception" for 
> the last three kernel releases.
> 
> The details differ, but you do seem to mix things up too much. I'm 
> not at all happy. I think quality control is slipping, because 
> there's this absolutely _humongous_ amount of crap that gets in 
> through you. You seem to have a hard time saying "no".
> 
> And yes, you boot-test things pretty well, but I really wish you 
> had more focus. This "everything under the sun" thing is very 
> annoying, and I think you are too damn eager to merge the random 
> new feature of the day.
> 
> So instead of "hoping", how about you look at making sure it 
> really _does_ become an exception. And that really fundamentally 
> means that it can't happen every release.
> 
> How about trying one release to just say "no" if you start seeing 
> all these kinds of things. We don't allow non-x86 architectures to 
> just tie things together this way. The fact that you have the same 
> tree seems to just encourage badness by making it "easier" to just 
> mix things up.

Yes, will do that - sorry about this. We'll also take more care and 
will try to cook up more scripting to make sure such crappy-looking 
circular criss-cross merges and compound trees dont happen again.

The remaining trees we have for this merge window are all 
single-purpose. We sent five of them in the last couple of hours and 
they have the kind of structure that we intend to use in the future 
too. If you still see _any_ problems with them, please let me know 
so i can fix the workflow ASAP.

	Ingo
--
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/