[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090612125335.GH31845@elte.hu>
Date: Fri, 12 Jun 2009 14:53:35 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Linus <torvalds@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
paulus@...ba.org, ppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: linux-next: origin tree build failure
* Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> > Ah - thanks. The bug was caused by me being a bit too optimistic
> > in applying the shiny-new Power7 support patches on the last
> > day. (nice CPU btw.)
>
> In that case paulus tells me it's actually Peter screwing up
> moving something from the powerpc code to generic :-)
Yes, but i committed it and it's my task to make sure that the thing
works as a whole so it's my fault still :)
> .../...
>
> > Such bugs happen, and they are easy enough to fix. What matters
> > arent the 1-2 short-lived bugs that do happen when a new
> > combination of trees is created, but the long-lived combination
> > bugs and conflicts.
>
> I'm not saying -next would fix world hunger ... but in this case
> we have two sets of issues, perfctr and the init ordering change
> which both got merged totally bypassing -next... We should at
> least -try- to follow the process we've defined, don't you think ?
You are trying to define a process that does not exist in that form
and which never existed in that form.
It was never true that new code _MUST_ go via linux-next - and i
hope it will never be true.
linux-next has integration testing so that interactions between
maintainer trees are mapped and that architectures that otherwise
few people use get build-tested too (well beyond their practical
relevance, i have to add) - but there's little critical review done
in linux-next. Nor should it be the forum for that, it simply
contains way too much stuff and has a weird history format with
daily rebases that makes review hard and expensive in that form.
linux-next should not be second-guessing maintainers and should not
act as an "approval forum" for controversial features, increasing
the (already quite substantial) pressure on maintainers to apply
more crap.
And that is true even if it's a new feature that i happen to support
- as in this case - it sure would have been handy to have more
perfcounters test coverage, every little bit of extra testing helps.
If linux-next wants to do that then it should be renamed to
something else and not called linux-next.
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/
Powered by blists - more mailing lists