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 |