Message-ID: <20120415065124.GC29563@gmail.com>
Date:	Sun, 15 Apr 2012 08:51:24 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Sergio Correia <lists@...e.net>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk,
	linux-wireless Mailing List <linux-wireless@...r.kernel.org>,
	Sujith Manoharan <c_manoha@....qualcomm.com>,
	"ath9k-devel@...ts.ath9k.org" <ath9k-devel@...ema.h4ckr.net>,
	"John W. Linville" <linville@...driver.com>
Subject: Re: [ 00/78] 3.3.2-stable review


* Felipe Contreras <felipe.contreras@...il.com> wrote:

> On Sat, Apr 14, 2012 at 1:47 PM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > * Felipe Contreras <felipe.contreras@...il.com> wrote:
> >
> >> On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds
> >> <torvalds@...ux-foundation.org> wrote:
> >> > On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
> >> > <felipe.contreras@...il.com> wrote:
> >> >>
> >> >> Sure, but removing that patch from the stable tree is not
> >> >> going the change that information; we already know the
> >> >> patch is wrong.
> >> >
> >> > .. and we wait until it has been fixed in mainline so that
> >> > we *know* that information doesn't get lost.
> >>
> >> So why don't we pick potentially dangerous patches that might
> >> benefit from some testing, put them in 'stable', and if there
> >> are problems, make sure they get fixed in upstream first?
> >>
> >> Or for that matter totally broken patches we want to make sure
> >> they get fixed in upstream.
> >>
> >> Because the priority of the 'stable' tree is *stability*. Is
> >> it not?
> >>
> >> But what you are saying is: *before* the final review, even a
> >> hint that the patch might cause problems is reason enough to
> >> drop it from stable, but *after* the review, if we know the
> >> patch is totally broken, then it's the opposite; we really
> >> want it in.
> >
> > What you don't seem to understand is that there are good reasons
> > why we first fix bugs upstream, then in -stable. Greg explained
> > it to you, Linus explained it to you and so did many others.
> >
> > Having an order of patches *necessarily* means that the
> > development tree will get fixes sooner than the stable tree. In
> > other words, this *necessarily* means that the stable tree - and
> > its users - will have to wait a little bit more to have the fix.
> > In the worst-case this 'have to wait a little bit longer' might
> > span the time between two minor stable kernel releases.
> >
> > You seem to equate this 'have to wait a little bit longer to get
> > the fix' property of the maintenance model with 'we don't care
> > about stable tree users' - that claim is obviously idiotic and
> > most of your arguments in this thread are idiotic as well.
> 
> This is a straw man again. Again; we are not talking about 
> fixes in 'stable' that don't exist in mainline, we are talking 
> about reverting patches from 'stable' that are not part of the 
> upstream release from where the 'stable' branch was forked.

You are misunderstanding the Linux kernel development process 
again:

> You are avoiding the argument you replying to; yesterday a 
> patch was droppable from the stable review queue, but today, 
> after the release, now we *need* it to stay there until it's 
> fixed in the mainline. What changed?

What changed: the stable kernel was released and a new cycle 
started. If something is broken in -stable it needs to be 
reverted upstream. Full stop.

There is a minor engineering process that if a -stable commit 
does not even apply or does not even boot on Greg's box or on 
the handful of boxes that test stable release candidates then it 
obviously cannot become part of the -stable queue. That kind of 
very short term, memory-less integration testing should not be 
confused with the much broader, state-ful, Git commit backed 
testing that the upstream kernel gets.

There's a new stable cycle every 7 days on average, there's a 
new upstream kernel every 7 days on average, and there's very 
good reasons for the stable queue to be memory-less and to not 
do your 'drop a patch from the previous stable version but don't 
bother dropping it from upstream first' kind of messy operation 
on it.

> What makes a patch droppable yesterday, but dependent on 
> mainline today?

Time and version release engineering: once a stable kernel is 
released any temporary integration testing results are flushed - 
the upstream kernel is where we maintain the information of 
which patch is broken and which not.

This memory-less process, amongst other things, helps the *next* 
major stable kernel become more robust, as it removes the 
possibility for version skew between stable and upstream.

If you want a revert you either need to report your problem fast 
enough to be caught in -stable integration testing, or you need 
to work with upstream to push the fix through properly.

People explained this to you, again and again, you refused to 
listen, repeatedly, again and again. There does not appear to be 
any rational set of arguments that will make you admit that you 
were wrong about this.

Anyway, in this discussion you have demonstrated it again why 
you are one of the very few commenters I had to permanently 
block on G+ ...

Thanks,

	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