On Sat, Jan 10, 2015 at 9:16 AM, Pacho Ramos <pa...@gentoo.org> wrote: > > But I must admit I lost the track of this issue some time ago and I > don't remember why the eclass is still allowed and then both policies > are being used in parallel depending on the maintainer, that is the > reason I haven't suggested the Council to deprecate games.eclass > finally :/ >
There is an immediate reason for this, and a deeper underlying issue. (IMHO.) The immediate issue was that the Council was dealing with a crisis with the games herd and wanted to take the minimum initial action to break the logjam. That meant removing the requirement that all games have to be under the control of the herd, but not interfering with how the herd itself was managed. There have been some attempts since to try to get a games team organized, but so far I don't think there has been much interest in that. It would be far better for a bunch of devs interested in games to get together, work out how to clean up the mess, and do it versus just having the council step into that role with a club. If that doesn't get anywhere then we can always revisit the situation and ask whether the current games policies are a serious problem, and if so should we turn that into some kind of QA issue with mandatory cleanup. In general, though, we try to aim for minimal-interference at the Council level. That brings me to... The deeper underlying issues, IMHO, might have something to do with the fact that a distro that is designed around letting every user have it their own way tends to lead to a culture of developers who all want to have everything their own way as well. :) That, and things like this: "Projects may well conflict with other projects. That's okay." [1] games.eclass is really just one more manifestation of this, though a more obvious one. How many foo-cleaner/foo-updater/etc scripts do we have out there now for things that aren't cleanly updated by portage, and how consistent is the syntax from one to the next? There are many package-to-package inconsistencies with how things get done. Of course, most of those aren't the result of outright disagreements. In general we tend to leave many things up to maintainers to "do the right thing" and I think that most of us tend to like it that way. I think the areas for Council involvement are ones like: 1. Outright conflict between maintainers/projects. 2. Cases where maintainers aren't really in active conflict, but consistency would benefit everybody and isn't particularly onerous to achieve. 3. Decisions that really affect the direction of the distro as a whole. [1] - https://wiki.gentoo.org/wiki/GLEP:39 -- Rich
