Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Cc: Michael Sterrett <michael@×××××××××.net>, games@g.o
Subject: Re: Re: Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12
Date: Thu, 31 Jul 2014 10:53:54
In Reply to: Re: Re: Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12 by "Andreas K. Huettel"
1 On Wed, Jul 30, 2014 at 2:15 PM, Andreas K. Huettel
2 <dilfridge@g.o> wrote:
3 >> I didn't bother replying before because I think my assumption was that
4 >> the council was clever enough to recognize silly when they saw it.
5 >> There never was a compelling argument for dispelling policy set by
6 >> groups in the general case and I'm not sure why the games group would
7 >> be considered to have lesser status in that regard.
8 >
9 > That actually doesn't address any of the issues brought up.
10 >
11 > The main question is, why should the games team have more status than other
12 > projects?
14 ++
16 Generally I am in favor of giving projects that adhere to GLEP39 more
17 of a say in things than individual maintainers, but setting aside
18 QA/Comrel/Infra there aren't really any projects out there which claim
19 the same kind of scope as games. Amd64 might have a say over your
20 KEYWORDS, or systemd might want to install a text file you don't have
21 to look at, but none of them are going to basically rewrite your
22 ebuild, rename it, or tell you to get it out of the tree. The
23 Gnome/KDE projects don't care if you install an application that uses
24 libkde/etc, though you'd do well to coordinate if you don't want
25 random breakage on the next big change.
27 If this were just an issue about games not accepting new members I
28 think that would be pretty trivial to fix, but I haven't gotten any
29 replies to my solicitation. So, this is more than whether the lead
30 responds to member requests.
32 Some options open to the council are:
33 1. Let the games project keep its policy, and anybody who wants to
34 change this has to join the project and call for elections (the
35 council can shoe-horn members onto the project if necessary).
36 2. Directly tweak games policy but preserve the project and its
37 scope. So, games would still have to adhere to games project policy,
38 but the Council might change specific policies (use of eclass, group,
39 etc).
40 3. Restrict the games project scope, such as giving it authority if
41 the package maintainer elects to put it in the games herd.
42 4. Do nothing.
44 I think #1 is the least intrusive (besides #4), but since nobody
45 responded to my call for new members I don't know that it will
46 accomplish anything. I don't really care for #2 - it seems the most
47 meddlesome and I'm not sure what would be left for the project to
48 actually do if we basically ripped out all their policies and told
49 them they can't change them.
51 Do we really have a sense for how much demand there is for change? #4
52 (or something equivalent like nicely asking games to deal with this)
53 might make sense if we think this is really just 2-3 devs with an
54 opinion, and that there isn't a larger demand out there.
56 However, right now #3 is where I'm somewhat leaning personally. I
57 think it would be helpful if more members of the community with a
58 strong opinion speak up. Apologies to the games project if it seems
59 like we're demanding a performance, but in the end the Council is as
60 much bottom-up as top-down and if all we hear is people demanding a
61 change, it is a bit hard to just ignore it, and really, listening to
62 the community is everybody's job anyway.
64 Rich