Message-ID: <CAMP44s05k3YkXSLGdYjJ42d+uEM+bLS9uZ+2ztUBWqcO6kyUtA@mail.gmail.com>
Date:	Sun, 15 Apr 2012 01:09:25 +0300
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Adrian Chadd <adrian@...ebsd.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Sergio Correia <lists@...e.net>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, torvalds@...ux-foundation.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

On Sun, Apr 15, 2012 at 12:21 AM, Stefan Richter
<stefanr@...6.in-berlin.de> wrote:
> On Apr 14 Felipe Contreras wrote:
>> On Sat, Apr 14, 2012 at 8:55 PM, Stefan Richter
>> <stefanr@...6.in-berlin.de> wrote:
>> > Generally, "commit + push out" makes it undroppable.  In case of -stable,
>> > commit/ push out/ tag are close and virtually identical.
>> >
>> > After a change was pushed out, the choice narrows down to add a reverting
>> > change for a subsequent release or to rebase to a point before the
>> > defective commit.  The latter is not done to -stable, obviously.  (3.3.2
>> > is not being restarted from 3.3 if a regression from 3.3 to 3.3.1 was
>> > discovered.)
>>
>> That's irrelevant; whether you rebase and drop the patch, or you
>> revert it, the resulting code is *exactly* the same. It's also the
>> same if Greg drops it from his quilt queue before pushing (assuming
>> that's what he uses).
>
> The result may be the same (sometimes it actually isn't),

If the result is not the same, then that's a different situation; I'm
talking about true reverts/drops in which the result is *exactly* the
same. OK?

>> Let's avoid this semantic red herring, by undroppable I mean
>> unrevertable, or undiscardable, or anything that effectively makes the
>> patch not be there.
>
> How do you "make it not be there"?  By adding a reverting patch.
>
> The reverting patch needs to come from somewhere, and the only
> disagreement is basically through which channels the patch should be
> allowed to come, or which qualifications this reverting patch should
> fulfill.

If the patch was tagged in a release, yes, but if the patch was in the
queue, but never tagged, it can be dropped.

The question that has not been answered is what makes them different, and why.

>> >> But *why*? You say you *really* need to problem to fixed in mainline,
>> >> that's why it cannot be dropped, but that applies also to patches in
>> >> the queue *before* the tag is made, doesn't it? If you find a patch in
>> >> the stable review queue causes problems, why don't you leave it there?
>> >
>> > As Willy wrote, that's actually what is done sometimes.  I didn't know
>> > that.
>>
>> Don't avoid the question.
>
> Willy answered that, hence I didn't think I have to.  The patch can in
> fact be kept in the stable queue as a reminder, it just should not be
> applied to stable as long as there is no resolution for mainline.

>> I don't mean just leave it in the queue, I mean leave it so it gets
>> tagged in the release.
>
> That would be even sillier than the discussion which we are having.

Exactly!

I'm glad you see it's silly to put bad patches in the stable release
just so they get properly tracked for mainline, but that's exactly
what you arguing for.

Now all you have to do is explain why it's silly before the tag, but not after.

-- 
Felipe Contreras
--
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