Forking ebuilds

Here’s a response to an email thread I sent recently. This was on a private alias but I’m not exposing the context or quoting anybody, so I’m not leaking anything but my own opinion which has no reason to be secret.

GLEP39 explicitly states that projects can be competing. I don’t see how you can exclude competing ebuilds from that since nothing prevents anybody from starting a project dedicated to maintaining an ebuild.

So, if you want to prevent devs from pushing competing ebuilds to the tree you have to change GLEP 39 first. No arguing or “hey all, hear my opinion” emails on whatever list will be able to change that.

Some are against forking ebuilds and object duplicating effort and lack of manpower. I will bluntly declare those people shortsighted. Territoriality is exactly what prevents us from getting more manpower. I’m interested in improving package X but developer A who maintains it is an ass and won’t yield on anything. At best I’ll just fork it in an overlay (with all the issues that having a package in an overlay entail, i.e. no QA, it’ll die pretty quickly, etc…), at worst I’m moving to Arch, or Exherbo, or else… What have we gained by not duplicating effort? We have gained negative manpower.

As long as forked ebuilds can cohabit peacefully in the tree using say a virtual (note: not talking about the devs here but about the packages) we should see them as progress. Gentoo is about choice. Let consumers, i.e. users and devs depending on the ebuild in various ways, have that choice. They’ll quickly make it known which one is best, at which point the failing ebuild will just die by itself. Let me say it again: Gentoo is about choice.

If it ever happened that devs of forked ebuilds could not cohabit peacefully on our lists or channels, then I would consider that a deliberate intention of not cooperating. As with any deliberate transgression of our rules if I were devrel lead right now I would simply retire all involved developers on the spot without warning. Note the use of the word “deliberate” here. It is important we allow devs to make mistakes, even encourage it. But we are adults. If one of us knowingly chooses to not play by the rules he or she should not be allowed to play. “Do not be an ass” is one of those rules. We’ve been there before with great success and it looks like we are going to have to go there again soon.

There you have it. You can start sending me your hate mail in 3… 2… 1…

4 thoughts on “Forking ebuilds”

  1. I don’t think that forking is a good solution. It is absolutely bad from a user perspective. However, this does not mean that I think that innovation should not happen. It means that the current maintainer (actually the herd maintaining the ebuild as no package should have a lone maintainer) needs to work with the proposer to solve the problem. If that can’t happen this means either the council or devrel needs to be involved. The council when a technical choice needs to be made that can not be agreed upon, devrel when the process stalls because of someone “being an ass” (btw. that can be the proposer as well as the package maintainer). Forking the ebuild is a copout.

  2. No hate from me. I’m not a Gentoo developer (mostly due to the protracted process required), but as a user, choice is a huge benefit. It’s the reason I migrated from Arch; they were encroaching upon user choices and Gentoo as a project goes to great lengths to give users choice and control. It’s unlike any other distro I’ve used.

  3. I agree. Forking is a good thing. Too many disagreeing people working on the same thing often leads to “design by committee”, where everybody is equally unhappy in the end. Choosing the best solutions and ideas by competition is much better.

    1. I’m not sure I’d call it competition… it’s just two (or more) different ideologies going their separate ways. I think it’s a mistake to consider it competition and it ruins the feel of FOSS. It’s not a sport, it’s just building and using software that we feel is best.

Leave a Reply