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

[Rich Freeman]

On Mon, Jul 1, 2013 at 7:16 AM, Chí-Thanh Christopher Nguyễn
<chithanh@g.o> wrote:
>
> 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.

As far as I'm concerned, kids who can't get along can go play
someplace else.  If you want your own apache ebuild that can't be
touched by anybody but you, that's what overlays are for.

Don't like that, please don't vote for me.  I have no issues with real
alternate implementations (openrc vs systemd, udev vs eudev,
consolekit vs logind, alsa sorta-vs pulseaudio, etc).  However,
projects that discuss their plans openly, embrace our philosophy of
choice, and which properly support their work to our quality standards
will be able to take dumps on your packages if you put them in the
main tree and there is nothing you'll be able to do about it.  Call it
tyranny of the majority if it makes you happier, but a distro that
gives every developer veto-power over any change is destined for
extinction.  Innovation will always come from individual developers;
the role of the Council is not to try to mandate innovation, but to
get the roadblocks out of the way so that it can flourish.

Gentoo has never needed internal forks simply because developers
cannot get along.  I don't see single-text-file additions to packages
as a reason that we should start.

> 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.

Is it more work?  Only in the sense that not being able to drop stable
versions is.  If things get out of hand we'll deal with them, but
polluting the package namespace with internal forks is a really ugly
technical solution to a really simple people problem.

Rich