[gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.

[Steven J. Long]

Tom Wijsman wrote:
> "Steven J. Long" wrote:
> > The bit about the user explicitly opting-in to 'fragile' patches still
> > is of concern, however.
>
> Why is this still of concern?
..
> 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.

In which case you're either not dealing with patches like aufs, or you're
modifying them, when afaic they're still fragile, and the modification
shouldn't even be done. Just let the user opt-in to patches that the QA
process has picked up, or are known to affect the kernel unconditionally.

> > [... SNIP ...]; and can hardly be called "Proper integration", imo.
>
> Why not?

Because of this:
> > 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.

Not when you default them all to on, given one USE flag, they're not.
 
> > 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.

If you're saying you want to press ahead with modified patches, for things
like aufs, then I think you should reconsider. As it sounds like a god-awful
hack that will lead to complexity where it's not needed, nor useful, as well
as a maintenance burden.

Keep it simple, and let the user explicitly opt-in to patchsets like aufs, so
the maintenance responsibility is theirs from the beginning, and they feel
ownership of the wider implications of that decision[1]. That's all Walter and
I are after (afaict in his regard, ofc.)

It's also easier to implement, and draws the demarcation that I mentioned above,
such that patchset authors have an incentive to "do the right thing" and again,
the maintenance burden shifts to where it belongs: not on your shoulders.

Regards,
steveL, slightly puzzled as to why you *want* to add make-work.

[1] No, asserting that "it's all under the experimental flag" is not enough.
It's just a cop-out, afaic.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)