Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
>> I did not say that maintainers can ignore policy. The removal of
>> ebuilds must follow certain rules which are set in policy.
> IMO this really doesn't say anything at all.  Of course maintainers
> have to follow policy.  The question is what should the policy be?

I think I am beginning to understand what you want to say. You want the
council (or some other body) to act as enforcer to bring maintainers in
line with prevailing opinion. Sorry, I am not supporting that.

> The original question was whether we should be forking or splitting
> packages over adding single files when the maintainer doesn't want
> them in the original package.  Right now we have no explicit policy
> governing this.

Yes, and due to the absence of policy it is the maintainer who has the
final say. That is how it is currently, and how I think it should be in
the future too. GLEP 39 specifically says that you cannot monopolize the
package, and anyone can fork the ebuild. That is sufficient remedy
against uncooperative maintainers in my eyes.

I wrote in a previous message that I would reconsider my position if the
amount of forked packages grew to unmanageable proportions. But until
then, if the kids cannot get along they shall play on separate playgrounds.

>> With x32 specifically, a number of people including some upstreams think
>> that the whole concept is a bad idea. A case could be made for patches
>> that #ifdef x32 and which compile to a no-op on other arches, but even
>> those must be maintained. What if the patch no longer applies after a
>> version bump?
> Well, since I'm only talking about WELL-SUPPORTED project-related
> work, just ask the project team to fix the patch.  If they don't in a
> reasonable timeframe, then it isn't well-supported and the maintainer
> can do whatever they want with it.  Project teams should only take on
> patches if they think they can sustain them.  Most likely for
> something like x32 they'd only do it for strategic packages anyway
> (toolchain, etc).

But in this hypothetical scenario you have unloaded additional work on
the maintainer. He just wants to bring the latest and greatest version
to his users, and the failing patch prevents him from doing that. He has
to request and then wait for the a new patch, and if he bumps the
package anyway after timeout risks breaking x32 users' systems.
If he does this voluntarily, fine. If the patch was forced on him,
putting him in this dilemma is not fair.


Best regards,
Chí-Thanh Christopher Nguyễn