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]
Date:	Thu, 12 Apr 2012 15:02:54 -0700
From:	"Luis R. Rodriguez" <mcgrof@...jolero.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Felipe Contreras <felipe.contreras@...il.com>,
	"ath9k-devel@...ts.ath9k.org" <ath9k-devel@...ema.h4ckr.net>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-wireless Mailing List <linux-wireless@...r.kernel.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	"John W. Linville" <linville@...driver.com>,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk
Subject: Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

On Thu, Apr 12, 2012 at 2:44 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Apr 12, 2012 at 2:34 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> So just reverting it from stable, *WITHOUT LEARNING THE LESSON*, is
>> not a no-op at all, it's a sign of being a f*cking moron.
>
> Btw, the revert is now in my tree (commit 011afa1ed8c4), and marked
> for stable. So *now* Greg can revert it from stable too.
>
> But the important lesson to everybody should be that "we don't lose
> fixes from -stable". If a problem was found in stable, it needs to be
> fixed upstream. In fact, quite often people *do* find problems in
> stable, because it tends to have more users more quickly than
> mainline. That makes it really really important to make sure that
> those problems get fixed upstream, and not hidden in stable due to
> some kind of dieseased "it's a no-op to revert it" thinking.
>
> End of story.

FWIW if people want stable fixes propagated faster (before Linus sucks
it in or Greg sucks it in after Linus) things like compat-wireless (to
be renamed to compat-drivers) allows us to get these out, but we label
them properly [0]. We in fact have a place holder for even other type
of non-upstream patches that any PHB may come up with as required but
-- the key is to

1) help categorize these properly
2) keep metrics of them
3) prioritize upstream first

The pending-stable/ patches get patches out to the community faster
than Linus / Greg can apply them or before we even get the community
to test them. We get these sucked out by looking for the Cc:
stable@...r.kernel.org The linux-next-cherry-pick/ allows you suck out
non-stable patches and I gladly accept such patches so long as they
are in linux-next and I can suck them out automatically if you Cc:
stable@...it-lab.org. There are similar tricks for the other types of
patches.

[0] http://wireless.kernel.org/en/users/Download/stable/#Additional_patches_to_stable_releases

  Luis
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ