On Mon, 1 Jul 2013 12:23:24 -0700 Greg KH <gre...@gentoo.org> wrote: > > 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. > > Look at aufs as a specific example of why you can't do that, > otherwise, don't you think that the aufs developer(s) wouldn't have > done so? > > The goal of "don't touch any other kernel code" is a very good one, > but not always true for these huge out-of-tree kernel patches. > Usually that is the main reason why these patches aren't merged > upstream, because those changes are not acceptable. > > So be very careful here, you are messing with things that are rejected > by upstream.
It sounds to me like some of those developers don't care about providing an option yet; because they would introduce it as an afterthought, based on its need and not just because they can. I don't see why this would be problematic, embedding it in config checks as well as checking whether the patch introduces non-conditional code are trivial to implement; why do you think this is not always true? Thank you for making us aware, feedback on this is nice. -- 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
