linux-kernel - Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

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: <20130712033430.GA3798@kroah.com>
Date:	Thu, 11 Jul 2013 20:34:30 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	"John W. Linville" <linville@...driver.com>
Cc:	Theodore Ts'o <tytso@....edu>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	stable@...r.kernel.org,
	ksummit-2013-discuss@...ts.linux-foundation.org
Subject: Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> 
> > In any case, I've been very conservative in _not_ pushing bug fixes to
> > Linus after -rc3 (unless they are fixing a regression or the bug fix
> > is super-serious); I'd much rather have them cook in the ext4 tree
> > where they can get a lot more testing (a full regression test run for
> > ext4 takes over 24 hours), and for people trying out linux-next.
> > 
> > Maybe the pendulum has swung too far in the direction of holding back
> > changes and trying to avoid the risk of introducing regressions;
> > perhaps this would be a good topic to discuss at the Kernel Summit.
> 
> Yes, there does seem to be a certain ebb and flow as to how strict
> the rules are about what should go into stable, what fixes are "good
> enough" for a given -rc, how tight those rule are in -rc2 vs in -rc6,
> etc.  If nothing else, a good repetitive flogging and a restatement of
> the One True Way to handle these things might be worthwhile once again...

The rules are documented in stable_kernel_rules.txt for what I will
accept.

I have been beating on maintainers for 8 years now to actually mark
patches for stable, and only this past year have I finally seen people
do it (we FINALLY got SCSI patches marked for stable in this merge
window!!!)  So now that maintainers are finally realizing that they need
to mark patches, I'll be pushing back harder on the patches that they do
submit, because the distros are rightfully pushing back on me for
accepting things that are outside of the stable_kernel_rules.txt
guidelines.

If you look on the stable@...r list, I've already rejected 3 today and
asked about the huge 21 powerpc patches.  Sure, it's not a lot, when
staring down 174 more to go, but it's a start...

greg k-h
--
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/