Re: [gentoo-dev] Re: qa last rites -- long list

[Rich Freeman]

On Sat, Jan 10, 2015 at 9:16 AM, Pacho Ramos <pacho@g.o> 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