1 |
On 06/30/2016 06:17 AM, Michał Górny wrote: |
2 |
> On Wed, 29 Jun 2016 21:54:44 -0700 |
3 |
> Daniel Campbell <zlg@g.o> wrote: |
4 |
> |
5 |
>> That's what I think this drama is about; changes being pushed from |
6 |
>> people who don't work on games, then leaving these game maintainers (and |
7 |
>> users) in the dark without a "correct" way to achieve what they're |
8 |
>> after. We can do better than that, and it's solvable in a technical |
9 |
>> manner, which is why I'm focused on it. |
10 |
> |
11 |
> I'd really appreciate if you did some research before accusing people. |
12 |
|
13 |
I've read the council meetings that I was able to find on it and have |
14 |
explored the perspectives of both sides of the subject. What research |
15 |
are you asking for? I've not attacked anyone. |
16 |
> |
17 |
>> On the political side... |
18 |
>> |
19 |
>> Do teams hold any authority (or veto power, whatever you want to call |
20 |
>> it) over their own ebuilds? Is it reasonable to rip functionality out |
21 |
>> from under a group of developers and tell them to deal with it? |
22 |
>> |
23 |
>> I think teams deserve autonomy over their own ebuilds, [...] |
24 |
> |
25 |
> No, they do not and I will not allow that to happen ever again. And I'm |
26 |
> pretty sure I'm not the only one here that was unhappy with the way |
27 |
> Games team pushed everyone around over the years. |
28 |
> |
29 |
> If you want autonomy, fork Gentoo or use your own repository. The core |
30 |
> Gentoo repository is community-maintained -- either live with it, or |
31 |
> leave. We do not need more people causing massive community damage for |
32 |
> years with nobody being bold enough to stop them. |
33 |
Our ebuilds are maintained by developers, with the occasional |
34 |
proxy-maintainer or contributor. Your previous statement combined with |
35 |
this amounts to "QA owns and manages the Gentoo repository." You just |
36 |
said teams have no autonomy over their own ebuilds, which naturally |
37 |
extends to individual developers lacking autonomy for their ebuilds, as |
38 |
well. |
39 |
|
40 |
This has little to do with what I want. I don't seek any of the use |
41 |
cases that games.eclass made possible, but that doesn't mean my use |
42 |
cases won't be axed in the future with the same lack of care and for |
43 |
similarly petty reasons. |
44 |
|
45 |
> |
46 |
> People and teams have reasonable right to develop policies and maintain |
47 |
> their own packages. However, they have no right to assume sole |
48 |
> ownership of all packages with generic characteristic, and hold it |
49 |
> for years while preventing anyone from having any saying on anything. |
50 |
> |
51 |
> Rephrasing Rich's words, how would you feel if I established 'Text |
52 |
> editors' project and claimed final saying on every single text editor |
53 |
> in Gentoo? Then I would develop policies I find useful, ignore any |
54 |
> input, ignore join requests and discourage anyone from contributing. |
55 |
> Is that the Gentoo you desire? |
56 |
No, it's not the Gentoo I desire. I've seen that claim thrown around and |
57 |
I've not seen any evidence of it happening follow it. I get it if you or |
58 |
others have a vendetta against the games team -- I don't know any of |
59 |
them really -- sometimes people don't get along. But ripping out the |
60 |
eclass is a "solution" that creates more problems than it solves. |
61 |
Changing its default prefix values to follow Gentoo's standard and |
62 |
allowing users to change it meets the needs of both parties, and yet it |
63 |
seems nobody considered that option. Rich suggested maybe its |
64 |
functionality could be put into a later EAPI, but as he noted there are |
65 |
hurdles in generalizing that behavior. If its values default to match |
66 |
Gentoo's, then only the people who need the path flexibility will need |
67 |
to change it. That's one of the recent trends for us lately, isn't it? |
68 |
Leave sane defaults, but if people want to change them and/or break |
69 |
things, they're free to. |
70 |
|
71 |
I expect to be told that use case is poor or irrelevant. Who decides |
72 |
which use cases are valid and what qualifies them to make those claims? |
73 |
> |
74 |
>> and should |
75 |
>> ideally follow QA guidelines *where reasonable*. Any good QA team should |
76 |
>> have iron-clad reasons behind their decisions, and answers for |
77 |
>> 'what-ifs' that exist outside of the ideal perfection that QA tends to |
78 |
>> operate in. |
79 |
> |
80 |
> The whole point of QA is to provide good quality *everywhere*, and it |
81 |
> is *unacceptable* to have developers decide if they want to follow |
82 |
> policies or not. It is reasonable to adjust the policies as necessary, |
83 |
> or allow grace periods. But there is no point in having policies that |
84 |
> are fully optional depending on the mood of the developer. |
85 |
And how is a QA group taken seriously if they don't address breakage |
86 |
that they introduce? Is QA not held to a standard at all? Is it a set of |
87 |
arbitrary rules laid down from this separate project that nobody else |
88 |
can examine or call for re-examination? |
89 |
|
90 |
A key ingredient to QA is knowing quality code when one sees it, and |
91 |
fully understanding the use cases that a given set of code makes |
92 |
possible. Ideally, they also understand and suggest best practices so |
93 |
people are aware of how to 'color inside the lines'. |
94 |
|
95 |
This games.eclass decision breaks use cases, supplies no replacement or |
96 |
forward-facing route for users, and is being swept under the rug as |
97 |
quickly as possible. |
98 |
> |
99 |
> That said, this is completely irrelevant to the topic at hand. This |
100 |
> isn't QA's decision. It's a long process started by individual |
101 |
> developers *interested in helping out with games* years ago, which |
102 |
> ended up with Council appeal. The source of the policy is the Council, |
103 |
> not QA. |
104 |
Those are weasel words. It was QA's decision to bring the topic to the |
105 |
Council, was it not? And it had a vested interest in a favorable ruling |
106 |
by the Council, no? If the answer to both is "yes", then QA was just as |
107 |
responsible bringing the decision to fruition as the council itself. The |
108 |
council doesn't make decisions on its own based on what I've read; they |
109 |
make decisions when options or challenges are brought to them. |
110 |
Therefore, people who make the most noise get heard and from the looks |
111 |
of it, their way as well. |
112 |
> |
113 |
> QA is merely concerned with the fact that Games team ignores |
114 |
> the policies established by the Council. This results in two different |
115 |
> layouts being deployed over the repository which results in increased |
116 |
> confusion (which you are victim of), and decreased quality. QA offers |
117 |
> to help in solving that. |
118 |
> |
119 |
>> Removing eclasses without really good reason and without replacements |
120 |
>> for missing use cases simply shouldn't happen. I wouldn't want that done |
121 |
>> to me, and I'd definitely not (knowingly) help someone else do it. |
122 |
> |
123 |
> Your disagreement with the rationale does not make it bad. |
124 |
> |
125 |
The rationale goes against what QA supposedly stands for (Quality |
126 |
Assurance). It breaks use cases and breaks ebuilds that use the eclass. |
127 |
In what way does the quality improve that changing games.eclass's |
128 |
default prefixes to match the rest of the tree doesn't also solve? |
129 |
|
130 |
Have you read the eclass? All the variables are at the top and we can |
131 |
change the defaults with no issue, while people who depend on that |
132 |
eclass can set the variables in make.conf or some other place. For |
133 |
those, there are news items. |
134 |
|
135 |
Instead, with things as they are now, ebuilds get broken and user |
136 |
expectations get turned on their head, upstream (us) doesn't give them |
137 |
any hints on how to go forward, and until every games.eclass-depending |
138 |
ebuild gets fixed, it'll have warnings and/or die() calls. The *only* |
139 |
benefit gained from this is the unicorn "every package is treated the |
140 |
same", except when they're not (@system target, coreutils and friends |
141 |
ring a bell?). |
142 |
|
143 |
In short, QA pushed the decision onto the council, the council ruled in |
144 |
favor of QA, so now QA gets to deal with the fallout of their decision. |
145 |
If the QA team doesn't want that, perhaps they should handle breaking |
146 |
changes better. Or elect better leadership. |
147 |
-- |
148 |
Daniel Campbell - Gentoo Developer |
149 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
150 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |