1 |
On 06/30/2016 05:24 PM, Rich Freeman wrote: |
2 |
> On Thu, Jun 30, 2016 at 7:19 PM, Daniel Campbell <zlg@g.o> wrote: |
3 |
>> Our ebuilds are maintained by developers, with the occasional |
4 |
>> proxy-maintainer or contributor. Your previous statement combined with |
5 |
>> this amounts to "QA owns and manages the Gentoo repository." You just |
6 |
>> said teams have no autonomy over their own ebuilds, which naturally |
7 |
>> extends to individual developers lacking autonomy for their ebuilds, as |
8 |
>> well. |
9 |
> |
10 |
> QA has authority over the Gentoo repository, but their scope for |
11 |
> exercising this authority is relatively narrow. Ultimately we expect |
12 |
> them to police themselves, but if they become a problem any developer |
13 |
> can appeal to the Council. For the most part the policies they |
14 |
> enforce have either been the sorts of things almost anybody would |
15 |
> agree with, or they're Council decisions. |
16 |
> |
17 |
> If the Council decides on a policy, then QA is completely within their |
18 |
> rights to take action to enforce that policy. If somebody wants to |
19 |
> appeal they can, but of course they're going to be appealing to the |
20 |
> Council that set the policy. That is by design. The whole point of |
21 |
> the Council is to have some way to reach a "final" decision when there |
22 |
> isn't consensus. Of course, Councils can change their mind, but in |
23 |
> practice this has been rare. |
24 |
> |
25 |
>> But ripping out the |
26 |
>> eclass is a "solution" that creates more problems than it solves. |
27 |
> |
28 |
> Trust me, this wasn't something the Council undertook lightly. |
29 |
> |
30 |
> |
31 |
>> |
32 |
>> I expect to be told that use case is poor or irrelevant. Who decides |
33 |
>> which use cases are valid and what qualifies them to make those claims? |
34 |
> |
35 |
> Ultimately the Council, by sole virtue of election. It isn't perfect, |
36 |
> but it is a process that has a form of accountability and it at least |
37 |
> is capable of yielding a final decision. On a lot of issues either A |
38 |
> or B is better than endlessly bickering between them. Of course, the |
39 |
> Gentoo way is to support choice and if somebody comes up with a good |
40 |
> way to push the decision into the hands of the end user then we can |
41 |
> just argue over the most sane default. No matter how you slice it, |
42 |
> there will always be decisions that people disagree over. |
43 |
> |
44 |
> Personally, I don't really buy into the SSD use case. It isn't that I |
45 |
> don't agree with the virtues of SSDs, but the most straightforward |
46 |
> solution to this is to stick / and /usr on the SSD so that all |
47 |
> applications benefit from this. An entire Gentoo install is only a |
48 |
> few GB worth of binaries/libraries/etc and it is probably a lot more |
49 |
> straightforward to indiscriminately put these on the SSD than to pick |
50 |
> and choose. Plus, your system will boot a LOT faster. This is what I |
51 |
> do - basically / is on an SSD and then I mount stuff on top from hard |
52 |
> drives when I need space. |
53 |
|
54 |
I'm not sure the SSD-for-games-only is the most effective solution |
55 |
either, but there are plenty of use cases that I disagree with that tend |
56 |
to get by without issue. Are / or /usr on SSD the proposed solution for |
57 |
someone who's aiming for the speed boost? |
58 |
|
59 |
> |
60 |
> In an earlier email you mentioned that this wasn't a big concern for |
61 |
> you personally but you were concerned for our end users. One bit of |
62 |
> advice that I'll offer is that if this is the case, let them speak for |
63 |
> themselves. Speaking personally, I'm interested in feedback from |
64 |
> anybody I get it from. However, when somebody comes to the Council |
65 |
> with an argument like "somebody, somewhere, might disagree" and nobody |
66 |
> is actually saying "this affects me" then it probably won't get a lot |
67 |
> of weight. |
68 |
> |
69 |
> Ultimately, though, you're going to have to trust the judgment of the |
70 |
> council. Or, whether you trust it or not, you will ultimately have to |
71 |
> abide by it for anything you do using your commit access. |
72 |
|
73 |
How are we certain that users will speak up for their cause when it's |
74 |
lacking support? Don't we risk alienating people without considering use |
75 |
cases? I understand where you're coming from wrt council decisions. I've |
76 |
corrected that and started a thread on gentoo-user that will give us |
77 |
some insight to how many users' use cases were affected by this decision |
78 |
and which use cases they were. Then we can either set a goal to make |
79 |
that use case possible, or give quality advice or write good |
80 |
documentation for that use case. |
81 |
|
82 |
>> And how is a QA group taken seriously if they don't address breakage |
83 |
>> that they introduce? Is QA not held to a standard at all? Is it a set of |
84 |
>> arbitrary rules laid down from this separate project that nobody else |
85 |
>> can examine or call for re-examination? |
86 |
> |
87 |
> QA is enforcing a Council policy. Whether something is considered |
88 |
> breakage ultimately is up to the Council. Who is on the Council is of |
89 |
> course up to all of us. While I don't advise turning an election into |
90 |
> a referendum on one particular decision I certainly encourage |
91 |
> developers to be selecting Council members based upon their ability to |
92 |
> strike an appropriate balance here. The Council's ability to dictate |
93 |
> tree-wide policies like these are probably the area where it has the |
94 |
> biggest impact on developers being able to scratch their itches. So, |
95 |
> this stuff is really important. |
96 |
> |
97 |
> The Council also confirms the lead of QA. And of course there is the |
98 |
> ability to appeal. There are of course issues with any human-run |
99 |
> organization but I struggle to think of conflicts the QA team has had |
100 |
> with developers which weren't addressed by the QA lead or the team. |
101 |
> Certainly I don't recall actually getting any actual appeals (for QA, |
102 |
> and in my time on the Council I've only seen one Comrel appeal). I |
103 |
> don't want to get into Comrel but the principle is the same with that |
104 |
> organization, just with a different scope of operations. |
105 |
> |
106 |
>> This games.eclass decision breaks use cases, supplies no replacement or |
107 |
>> forward-facing route for users, and is being swept under the rug as |
108 |
>> quickly as possible. |
109 |
> |
110 |
> There is no intent to stifle discussion. You're welcome to state your |
111 |
> opinion. The Council can always reverse the decision, or the next |
112 |
> Council can do so. I personally consider either unlikely, but Gentoo |
113 |
> is never compelled to jump off a cliff because of a past mistake. |
114 |
> However, at this point this is a fairly established decision, so while |
115 |
> you can discuss, this isn't considered something on-hold for debate. |
116 |
> That could change if a majority of the Council decides to issue a |
117 |
> stay/etc, but certainly I'm not calling for one based on what I've |
118 |
> heard so far. |
119 |
> |
120 |
> Ultimately I feel one of the key purposes of the Council is to remove |
121 |
> obstacles to progress by making calls when they need to be made. A |
122 |
> call has been made, and there cannot be obstacles for those |
123 |
> implementing the decision. |
124 |
> |
125 |
>> Those are weasel words. It was QA's decision to bring the topic to the |
126 |
>> Council, was it not? And it had a vested interest in a favorable ruling |
127 |
>> by the Council, no? If the answer to both is "yes", then QA was just as |
128 |
>> responsible bringing the decision to fruition as the council itself. The |
129 |
>> council doesn't make decisions on its own based on what I've read; they |
130 |
>> make decisions when options or challenges are brought to them. |
131 |
>> Therefore, people who make the most noise get heard and from the looks |
132 |
>> of it, their way as well. |
133 |
> |
134 |
> The Council is not bound to the options presented to it, and Council |
135 |
> members can propose Council agenda items the same as anybody else |
136 |
> (we're developers too!). Speaking personally I certainly try to think |
137 |
> of our developers and users as a whole, and I'm confident my peers |
138 |
> tend to do so as well. We don't always agree, but I've never had |
139 |
> occasion to question anybody's motives. |
140 |
> |
141 |
> Sure, we're more likely to take up a topic that somebody is |
142 |
> complaining about than one that nobody is complaining about. And of |
143 |
> course we're going to tend to judge dissatisfaction by opposition. |
144 |
> However, we don't pull up the 100-email debate and count the number of |
145 |
> posts on each side. Ultimately we're going to tend to use our |
146 |
> judgment, which is what we're supposed to be selected for (and really, |
147 |
> what else can we do?). Persuasive arguments will of course tend to |
148 |
> persuade, but this shouldn't be viewed as a bug. |
149 |
> |
150 |
> In this case I can assure you that people were frustrated that it took |
151 |
> as long as it did to end up with a decision, and it largely was |
152 |
> because we recognized the controversy. There were multiple rounds of |
153 |
> meetings and numerous opportunities to provide feedback. Ultimately, |
154 |
> however, providing feedback does not guarantee any particular result. |
155 |
> |
156 |
>> In short, QA pushed the decision onto the council, the council ruled in |
157 |
>> favor of QA, so now QA gets to deal with the fallout of their decision. |
158 |
>> If the QA team doesn't want that, perhaps they should handle breaking |
159 |
>> changes better. Or elect better leadership. |
160 |
> |
161 |
> QA isn't forcing anybody to do anything. They put out a call for |
162 |
> help. People can choose to answer it or not at their discretion. The |
163 |
> Council didn't attempt to force anybody to do anything for precisely |
164 |
> the reasons you state. We made a decision to clear the way, but |
165 |
> ultimately the people that are most bothered by the eclass will |
166 |
> probably be the ones to implement the decisions. As long as nobody |
167 |
> interferes with them, it can take however long it needs to take. |
168 |
|
169 |
So, agenda gets pushed to council -> council votes in favor of motion -> |
170 |
QA acts on council decision -> decisions empower them to prohibit |
171 |
blocking them -> somehow this is not forcing. The last jump in logic is |
172 |
questionable to me. |
173 |
|
174 |
> FOSS ultimately comes down to "patches welcome." If it bothers you |
175 |
> that much, go fix it. The Council can get the roadblocks out of your |
176 |
> way, but the ultimate test of your resolve is whether you're willing |
177 |
> to put in the work. Anybody can put out an appeal for volunteers. I |
178 |
> know some have complained that removing the games eclass has taken as |
179 |
> long as it has, and ultimately it comes down to willingness to put in |
180 |
> the work. If the eclass doesn't bother you, then by all means sit |
181 |
> back and let others take care of it. |
182 |
> |
183 |
Patches *wouldn't* be welcome in this case, however. The patch in |
184 |
question would change default games.eclass variables to standard Gentoo |
185 |
paths. I know with certainty it wouldn't be accepted or welcomed. And |
186 |
with that knowledge, what would motivate me (or someone else, like |
187 |
someone with a relevant use case) to work toward getting that done? It |
188 |
would end up relegated to an overlay. |
189 |
|
190 |
There's nothing wrong with that, technically speaking, but it belies the |
191 |
story of "Patches welcome, everyone can contribute." |
192 |
|
193 |
Ignoring the use cases of others ensures that one day my use case will |
194 |
be on the stake. I wouldn't have worked toward becoming a developer if I |
195 |
was apathetic. |
196 |
|
197 |
--- |
198 |
|
199 |
To all other points, thanks for clarifying the operating structure of |
200 |
Gentoo. I'm going to wait on my gentoo-user survey to give us some |
201 |
concrete results to work with; be they in favor of games.eclass or |
202 |
apathetic. It will at least reflect reality. |
203 |
-- |
204 |
Daniel Campbell - Gentoo Developer |
205 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
206 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |