On Fri, 5 Jul 2013 09:38:10 +0100 "Steven J. Long" <[email protected]> wrote:
> Tom Wijsman wrote: > > > > Yes, we currently have "base" and "extras" tarballs for genpatches; > > it is trivial to add a "experimental" tarball to this set, all the > > optional experimental patches will be in that tarball. This is also > > handy for maintainers of other distros whom use genpatches. > > That's cool. The bit about the user explicitly opting-in to 'fragile' > patches still is of concern, however. Why is this still of concern? (See the next response before replying) > > There shouldn't be a problem here unless the user applies a lot of > > patches that could introduce a colliding patch; in this case the > > user either has to fix the conflicting patch or exclude ours. We > > can't know for ourselves which patches will be troublesome in this > > light; but well, I feel like this only happens on a very > > exceptional basis. If an user keeps this amount of patches, ours > > are probably not needed. > > No, the problem is as mentioned, with patches for which disabling the > configure option, does not stop the patch from changing anything. Such > as aufs, as has been outlined by Greg K-H earlier in the thread. My original post mentions "3) The patch should not affect the build by default.", which I later clarified with "It's just a matter of embedding each + block in the diff with a config check and updating the counts."; in detail we QA check whether all blocks contain such a config check. It does not change anything other than insert some code which won't be parsed if you don't enable the relevant option in the menu config. > [... SNIP ...]; and can hardly be called "Proper integration", imo. Why not? > After all, these are experimental patches. If they don't play nicely, > don't let them out of the sandbox, unless the user tells us to. It's the user that can let each individual patch out of its sandbox. > Having a clear "policy" on that makes negotiating with patch authors > much simpler too, and it's far more likely they'll fall into line > where possible, just as upstreams are usually quite happy to apply > portability patches: it means they get more users and feedback. Not sure what is meant by this; but given my above clarifications, I think you were missing a detail in the approach that is taken. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
