On Mon, 1 Jul 2013 12:33:30 -0700 Greg KH <gre...@gentoo.org> wrote: > On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote: > > On Mon, 1 Jul 2013 14:09:57 -0500 > > Matthew Summers <quantumsumm...@gentoo.org> wrote: > > > If the patchset patches the kernel's core, it doesn't matter what > > > CONFIG_* option is set the core kernel code > > > _has_now_been_changed_. This is the crux of the argument, I > > > believe. AUFS simply being one example of this. I'm sure there > > > are others. > > > > As per my response to that point, this statement is no longer true. > > > > Let me re-iterate it here: > > > > Earlier I mentioned "3) The patch should not affect the build by > > default."; if it does, we have to adjust it to not do that, this is > > something that can be easily scripted. It's just a matter of > > embedding each + block in the diff with a config check and updating > > the counts. > > Wonderful, now you are maintaining a patch that looks nothing like the > one created by the original developers, nor tested by anyone else > other than gentoo developers.
I can convert the original developer's patch whenever he updates it; or on top of that, write a script to generate the original patch back. > Playing fast-and-loose with kernel patches is a fun thing to do, but > really, why? Users love doing this type of thing, but the > interactions of different kernel patches with core subsystems is > almost always a non-trivial thing. Our main intent is to provide them and deduplicate work; if users have a problem with one of the patches and it isn't clear to us, we can forward them to the authors. Nothing in this proposal inherits that we must support the patches; especially not, since they are "experimental". > I'm not saying not to do this, but consider this a friendly warning > that this is going to be a MAJOR pain to maintain and debug over the > long-run. Maybe, maybe not; plan is to do a slow start, congestion avoidance. :) > But hey, what do I know? It's not like I've ever done this before and > had the experience of the resulting fall-out that took years to > recover from on user's production systems, causing a number of > enterprise Linux companies to swear that they would never do this > type of thing again... I covered this in the conditions as well as the F.A.Q.; feel free to read about it again, this does not affect them unless they explicitly want them to enable CONFIG_GENTOO_EXPERIMENTAL which help includes a warning; thinking it through, we might even suffix -exp to version. > Personally, I wish you luck, it will push the sane users to the > vanilla-sources tree, which I strongly encourage :) I will push them to keep CONFIG_GENTOO_EXPERIMENTAL disabled. :) > greg "kids, get off my lawn!" k-h Gentoo (Penguin) and Larry do not necessarily like grass; they might like ice, fire, water, earth, ... whatever their appetite craves. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
