Gentoo Archives: gentoo-dev

From: James Potts <arek75@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] The request to abolish games team policy
Date: Tue, 08 Jul 2014 05:33:30
Message-Id: CAO2dY5EaEYsMGnEpdYdah7NstNfMDn7HNaTv7XtVjb6AuF6+=Q@mail.gmail.com
In Reply to: [gentoo-dev] The request to abolish games team policy by "Michał Górny"
1 On Mon, Jul 7, 2014 at 4:45 PM, Michał Górny <mgorny@g.o> wrote:
2 > Dear Community,
3 >
4 > First of all, please do not take this personally. I don't want to
5 > attack any member of the games team or the team in general. I respect
6 > their experience and long-term contribution to Gentoo. However,
7 > I strongly disagree with the policy games team has established and I
8 > believe that their actions do not serve the best interest of Gentoo.
9 >
10 > I am therefore going to propose this request to the next Council. Since
11 > this will likely require a fair amount of prior discussion, I would
12 > like to start it already, hopefully reaching at least some point before
13 > the appropriate Council meeting.
14 >
15 >
16 > I would like to ask the Council to abolish the following policies that
17 > have been established by the games team:
18 >
19 > 1. that the games team has authority over the actual maintainers
20 > on every game ebuild,
21 >
22 > 2. that every ebuild has to inherit games.eclass as the last eclass
23 > inherited [1], even if it actually increases the ebuild size rather
24 > than helping,
25 >
26 > 3. that games must adhere to games team-specific install locations
27 > and ownership rules, shortly listed in [2].
28 >
29 > More specifically, I would like the games to be 'freed' from the games
30 > team monopoly and treated like every other package. More specifically,
31 > I believe that:
32 >
33 > i. games should be maintained by their respective maintainers,
34 > and games team (if any) should help rather than overriding their
35 > decisions,
36 >
37 > ii. that the games.eclass should be deprecated and likely disabled
38 > in the next EAPI since wrapping phases and helper functions makes it
39 > close to base.eclass in design,
40 >
41 > iii. that the games group along with the game-specific install tree
42 > should be deprecated and phased out. Games should be installed alike
43 > any other applications.
44 >
45 >
46 > I feel like the games team is more focused on keeping the 'status
47 > quo' than working on improving the experience of Gentoo users.
48 > The problems with current game install design have been pointed out
49 > multiple times, and the suggestions were either ignored by the team or
50 > refused, sometimes with strong words. In fact, the team's own decisions
51 > are creating further issues that they afterwards need to work around.
52 >
53 > The most notable issues with the specific use of games group include:
54 >
55 > a. nethack security issue [3] that is purely Gentoo-specific, and is
56 > open with no action from games since 2006,
57 >
58 > b. multiple game ebuilds being unable to access files installed by
59 > other game ebuilds that are worked around with dangerous
60 > RESTRICT=userpriv [4,5,6].
61 >
62 > Moreover, the eclass is purely suited for autotools-based ebuilds.
63 > The policy enforced by the team makes it very hard to create proper
64 > ebuilds for other build systems, often requiring redeclaration of all
65 > phase functions (to restore the proper eclass) and heavy patching of
66 > install locations.
67 >
68 >
69 > The number of inconveniences, lack of replies (lack of time?) has
70 > resulted in multiple games being spread throughout various overlays.
71 > I think the gamerlay project [7] is most notable. Sadly, this results
72 > in even worse quality of games in Gentoo.
73 >
74 > I believe that the policy needs to change. While I respect the members
75 > of games team, I don't think they should be allowed to prevent other
76 > developers from committing game ebuilds, and I don't agree with keeping
77 > the 'status quo' of games.eclass for the sake of keeping it while
78 > the issues outweigh the benefit (it is actually negotiable whether
79 > there's any).
80 >
81 > I would like to ask the Community for their opinion on this issue.
82 > When the new Council term starts, I will add the issue to the agenda.
83 > Unless the games team decides to give up their policies and allow
84 > developers to work on cleaning up games before that.
85 >
86 >
87 > [1]:http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap3
88 > [2]:http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap4
89 > [3]:https://bugs.gentoo.org/show_bug.cgi?id=125902
90 > [4]:https://bugs.gentoo.org/show_bug.cgi?id=112898
91 > [5]:https://bugs.gentoo.org/show_bug.cgi?id=419331
92 > [6]:https://bugs.gentoo.org/show_bug.cgi?id=516576
93 > [7]:https://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=summary
94 >
95 > --
96 > Best regards,
97 > Michał Górny
98
99 Here's my non-developer point-of-view:
100
101 I agree with this - games are lagging way behind in gentoo compared to
102 other distributions, and this heavy-handed super-maintainership by the
103 games herd explains why. If a person wants his game to be
104 co-maintained by the games herd, fine, they have to follow the rules
105 of the games herd, but being in the games herd should be an option,
106 not a requirement for a game to be in the tree. Lets let the people
107 who want to maintain game ebuilds maintain them, governed by the same
108 rules as all other ebuilds, regardless of herd status.
109
110 I also agree that the games group needs to go, for the most part -
111 users shouldn't have to be in it to play games (they shouldn't be in
112 it at all, but that's a different story) - that's a dated policy that
113 likely comes from mainframe unix environments and really doesn't
114 belong on a modern linux desktop or server, so it just winds up
115 confusing and/or annoying people.
116
117 --James