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? |
13 |
|
14 |
++ |
15 |
|
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. |
26 |
|
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. |
31 |
|
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. |
43 |
|
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. |
50 |
|
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. |
55 |
|
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. |
63 |
|
64 |
Rich |