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:	Mon, 15 Jul 2013 08:54:53 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Josh Boyer <jwboyer@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [ 00/19] 3.10.1-stable review

On Thu, 2013-07-11 at 18:14 -0400, Josh Boyer wrote:
>    Why are subsystem maintainers holding on to fixes that are
> >   _supposedly_ affecting all users?  I mean, 21 powerpc core changes
> >   that I don't see until a -rc1 merge?  It's as if developers don't
> >   expect people to use a .0 release and are relying on me to get the
> >   fixes they have burried in their trees out to users.  

Let me guess, a lot of these are Power8 fixes ... This is a bit special
this time around... we introduced some of the support in 3.9 and added a
bunch in 3.10. We found bugs, it's brand new HW (not even final yet),
and nobody out there has access to it nor will for a little while
longer, so indeed nobody is going to use 3.10.0.

I've been pushing back on a lot of it as a maintainer (which is why a
lot of stuff ended up in 3.10 instead of 3.9), but granted probably not
enough this time around.

It's hard because the guys are getting a LOT of pressure in part because
of distro schedules.

As you are aware (and I mentioned in another email), some enterprise
distros impose a very specific schedule for stuff to go upstream, and if
that misses, well .... you are out of the game for years or lots of $ to
convince them otherwise. Additionally, one of them has brain damaged
rules about preserving kernel ABIs which prevents any significant
addition for the entire lifetime of the distro major release.

This is bad, this should not affect upstream in theory, but in practice
it does because if we don't get into the damn enterprise distro, the
whole exercise is pointless to begin with and we may as well not release
the machines and stop the Linux business altogether.

So I make compromises. I delay some stuff because it's really not ready,
and I take some because it affects things like thread_struct layout
which I know *WILL* break kABI and will be VERY hard to get back to the
distro later, fully expecting that various bits of fixes are going to
eventually trickle later on until it's ready for public consumption.

Ben.


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