[gentoo-dev] The request to abolish games team policy

[Michał Górny]

Dear Community,

First of all, please do not take this personally. I don't want to
attack any member of the games team or the team in general. I respect
their experience and long-term contribution to Gentoo. However,
I strongly disagree with the policy games team has established and I
believe that their actions do not serve the best interest of Gentoo.

I am therefore going to propose this request to the next Council. Since
this will likely require a fair amount of prior discussion, I would
like to start it already, hopefully reaching at least some point before
the appropriate Council meeting.


I would like to ask the Council to abolish the following policies that
have been established by the games team:

1. that the games team has authority over the actual maintainers
on every game ebuild,

2. that every ebuild has to inherit games.eclass as the last eclass
inherited [1], even if it actually increases the ebuild size rather
than helping,

3. that games must adhere to games team-specific install locations
and ownership rules, shortly listed in [2].

More specifically, I would like the games to be 'freed' from the games
team monopoly and treated like every other package. More specifically,
I believe that:

i. games should be maintained by their respective maintainers,
and games team (if any) should help rather than overriding their
decisions,

ii. that the games.eclass should be deprecated and likely disabled
in the next EAPI since wrapping phases and helper functions makes it
close to base.eclass in design,

iii. that the games group along with the game-specific install tree
should be deprecated and phased out. Games should be installed alike
any other applications.


I feel like the games team is more focused on keeping the 'status
quo' than working on improving the experience of Gentoo users.
The problems with current game install design have been pointed out
multiple times, and the suggestions were either ignored by the team or
refused, sometimes with strong words. In fact, the team's own decisions
are creating further issues that they afterwards need to work around.

The most notable issues with the specific use of games group include:

a. nethack security issue [3] that is purely Gentoo-specific, and is
open with no action from games since 2006,

b. multiple game ebuilds being unable to access files installed by
other game ebuilds that are worked around with dangerous
RESTRICT=userpriv [4,5,6].

Moreover, the eclass is purely suited for autotools-based ebuilds.
The policy enforced by the team makes it very hard to create proper
ebuilds for other build systems, often requiring redeclaration of all
phase functions (to restore the proper eclass) and heavy patching of
install locations.


The number of inconveniences, lack of replies (lack of time?) has
resulted in multiple games being spread throughout various overlays.
I think the gamerlay project [7] is most notable. Sadly, this results
in even worse quality of games in Gentoo.

I believe that the policy needs to change. While I respect the members
of games team, I don't think they should be allowed to prevent other
developers from committing game ebuilds, and I don't agree with keeping
the 'status quo' of games.eclass for the sake of keeping it while
the issues outweigh the benefit (it is actually negotiable whether
there's any).

I would like to ask the Community for their opinion on this issue.
When the new Council term starts, I will add the issue to the agenda.
Unless the games team decides to give up their policies and allow
developers to work on cleaning up games before that.


[1]:http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap3
[2]:http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap4
[3]:https://bugs.gentoo.org/show_bug.cgi?id=125902
[4]:https://bugs.gentoo.org/show_bug.cgi?id=112898
[5]:https://bugs.gentoo.org/show_bug.cgi?id=419331
[6]:https://bugs.gentoo.org/show_bug.cgi?id=516576
[7]:https://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=summary

-- 
Best regards,
Michał Górny