Tom Wijsman wrote: > Greg KH 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.
If it does then it should never be applied, unless the user specifically asks for it, imo, and the resultant kernel is labelled -exp as you suggest. > 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. Please, just keep a copy of the original patch as well as the modified output from the script, somewhere reasonable to you, if you are doing any editing. Traceability is essential here. Personally I think it ill-advised, and would prefer simply that the patch were not applied if the above process in your testing prior to usage, showed that it would affect other parts of the build inappropriately, even when configured off. Or it's known to do so, like aufs. Unless of course the user specifically requests it. This can be a simple variable with a list of required patches, or whatever. > > 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 agree that users love doing this sort of thing, and that it makes sense to provide a standard opt-in mechanism, so that it's immediately obvious in bug-reports that a custom, non-upstream, kernel patch is in use. > > 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... As you said, users love doing this sort of thing, so it's happening under our noses in any case; that's the nature of a source distribution. In such a case it makes sense to have the info in a bug-report from the beginning. > 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. This makes a lot of sense. Since the point of this is to bring simplicity to the process for the user, and more useful bug reports for Gentoo, it seems like a requirement. > > 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. :) Yup. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
