1 |
On Thu, Aug 20, 2015 at 6:18 PM, hasufell <hasufell@g.o> wrote: |
2 |
> On 08/21/2015 12:06 AM, Jason A. Donenfeld wrote: |
3 |
>> This seems quite reasonable, and I welcome QA's efforts at maintaining |
4 |
>> uniformity and cleanliness. |
5 |
>> |
6 |
|
7 |
++ |
8 |
|
9 |
I'd rather see groups like QA making proposals to improve cross-Gentoo |
10 |
consistency than see stagnation. It was an RFC, and people can post |
11 |
issues with it, or escalate to Council if they're concerned. If |
12 |
taking it to Council I'd suggest you might want to come up with a |
13 |
better argument than "who cares about consistency?" |
14 |
|
15 |
As far as effort to remediate goes - there is no reason something like |
16 |
this couldn't be incorporated in future bumps/changes/etc. |
17 |
|
18 |
> |
19 |
> Like allowing that devs may or may not use games.eclass, so that users |
20 |
> cannot expect consistent behavior for games anymore? |
21 |
|
22 |
That wasn't a QA decision, it was a Council decision. We didn't |
23 |
outright ban the eclass because we were hoping somebody would step up |
24 |
to lead the games team and clean things up. |
25 |
|
26 |
If you're proposing an outright ban on games.eclass and a move towards |
27 |
treating games like other packages you can petition the Council like |
28 |
anybody else. |
29 |
|
30 |
> Instead of ignoring the games project _again_ and making decisions above |
31 |
> their heads... try to fix the project maybe? |
32 |
|
33 |
Are you offering to do that? |
34 |
|
35 |
The issue is that nobody seems to want to take over the games project. |
36 |
You can't force people to join a dead team. It doesn't make sense to |
37 |
prevent progress either just to call attention to a dead team. |
38 |
|
39 |
> |
40 |
> Is this becoming a habit now? People who are rarely involved in any |
41 |
> games ebuild development suddenly know how games ebuild consistency |
42 |
> should look like. |
43 |
> |
44 |
|
45 |
This isn't about games consistency. This is about tree consistency. |
46 |
The games were already consistent with the dedicated USE flag. The |
47 |
problem is that they're doing it differently than virtually everything |
48 |
else, in a way that doesn't make as much sense. |
49 |
|
50 |
-- |
51 |
Rich |