Re: [AppArmor 00/44] AppArmor security module overview

[Dave Jones <davej@redhat.com>]

On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:

 > I suspect that we're at the stage of having to decide between
 > 
 > a) set aside the technical issues and grudgingly merge this stuff as a
 >    service to Suse and to their users (both of which entities are very
 >    important to us) and leave it all as an object lesson in
 >    how-not-to-develop-kernel-features.
 > 
 >    Minimisation of the impact on the rest of the kernel is of course
 >    very important here.
 > 
 > versus
 > 
 > b) leave it out and require that Suse wear the permanent cost and
 >    quality impact of maintaining it out-of-tree.  It will still be an
 >    object lesson in how-not-to-develop-kernel-features.

How is this different from Red Hat wearing the permanent cost of
carrying Execshield or other vetoed-by-upstream features ?

Given the choice, I'd ship a kernel for Fedora with nothing added
that isn't upstream, but we have something of a legacy from our
dumber days. (Though we've managed to drop lots of the more invasive
stuff over time thankfully.. 4g4g for eg).

 > Sigh.  Please don't put us in this position again.  Get stuff upstream
 > before shipping it to customers, OK?  It ain't rocket science.

Indeed.  The idea of granting exceptions to our usual acceptance
criteria just because "some distro shipped it" strikes me as wrong
on so many levels, regardless of its technical flaws.

And this isn't just because this is a patch from a competitor,
I'd expect the exact same criteria to be applied if I tried
to ram execshield etc down everyones throats.

	Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/