On Fri, 5 Jul 2013 09:38:10 +0100
"Steven J. Long" <slong@rathaus.eclipse.co.uk> 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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D