1 |
On Thursday, June 28, 2018 3:33:24 PM EDT Rich Freeman wrote: |
2 |
> On Thu, Jun 28, 2018 at 3:03 PM Aaron Bauman <bman@g.o> wrote: |
3 |
> > On Thursday, June 28, 2018 1:24:27 PM EDT Rich Freeman wrote: |
4 |
> > > On Thu, Jun 28, 2018 at 12:14 PM Michał Górny <mgorny@g.o> wrote: |
5 |
> > > > a. the Council decision in question is final (i.e. a general |
6 |
> > > > |
7 |
> > > > resolution can not be used to bypass the Council), |
8 |
> > > |
9 |
> > > One question that this brings up in my mind is the duration of these |
10 |
> > > decisions, because Council decisions are never really final. The |
11 |
> > > Council can override its own decisions, or the decision of a prior |
12 |
> > > Council. |
13 |
> > |
14 |
> > By this logic then nothing is final. We might as well throw it all away. |
15 |
> |
16 |
> Finality has nothing to do with throwing stuff away. Decisions are |
17 |
> made at a point in time. They aren't generally discarded lightly, but |
18 |
> they also aren't clung to when they no longer make sense. That is all |
19 |
> I'm getting at. |
20 |
> |
21 |
> > It is my impression that the GR is not "overridable" because it is a |
22 |
> > developer wide vote. The important people are the developers... |
23 |
> |
24 |
> Great. Then write that into the GLEP so that is clear. My whole |
25 |
> point is that we shouldn't have to rely on your "impression." |
26 |
> |
27 |
|
28 |
It is clear. It is understood. If you have an issue with it then send mgorny |
29 |
a patch. As stated, it nullifies a particular decision. Plain and simple. |
30 |
|
31 |
> > A council vote should *absolutely* be required to change the default |
32 |
> > service manager. |
33 |
> |
34 |
> Sounds like you'll be needing another GLEP then. What other decisions |
35 |
> should explicitly require Council votes? |
36 |
> |
37 |
|
38 |
"Global issues". Again, we can't legislate common sense. |
39 |
|
40 |
> GLEP 39 only requires them when there are disagreements between |
41 |
> projects. In the absence of disagreement between projects, no Council |
42 |
> votes are required. |
43 |
> |
44 |
|
45 |
Looks like you need to read GLEP39 again. The word agreement isn't even found |
46 |
in it. (Hint: "Global issues will be decided by an elected Gentoo council.") |
47 |
|
48 |
> > The GR GLEP, as Michał has written it, does indeed not have an expiration |
49 |
> > date. The assumption you have made here worries me though. We *cannot* |
50 |
> > legislate common sense. By the developer community enacting the general |
51 |
> > resolution it is nullifying that particular decision. The controls of |
52 |
> > which are clearly outlined. |
53 |
> |
54 |
> I'm not sure what "assumption" I've made here. I've simply pointed |
55 |
> out that nothing in the policy states how a GR is to be reversed. I |
56 |
> then proposed scenarios for how that could cause questions to come up. |
57 |
> My goal is to make the policy less ambiguous. |
58 |
> |
59 |
|
60 |
It doesn't *need* to be reversed. It is a nullification of a decision because |
61 |
of disagreement by the developer community. So, the council should react by |
62 |
trying something that is "in line" with the issues that were brought up. |
63 |
Plain and simple. |
64 |
|
65 |
> > A subsequent council would simply propose another vote to change the |
66 |
> > default service manager when the time is appropriate. It should be clear |
67 |
> > as to why the GR was enacted (which is detailed in the GLEP) and it |
68 |
> > should be clear to any subsequent voting members what issues the |
69 |
> > *developers* had with it. |
70 |
> If there is no longer any controversy over the new decision (which |
71 |
> might be many years later), why require an all-dev vote? And of |
72 |
> course a GR can always be used to re-override the Council decision if |
73 |
> necessary. Obviously you'd want some controls on this so that we |
74 |
> don't end up with the same issues being re-voted upon repeatedly. |
75 |
> |
76 |
|
77 |
No, the council just proposes a new/modified proposal to vote on. This should |
78 |
have been a product of civil discourse. Understanding what the issues were |
79 |
and addressing them. |
80 |
|
81 |
e.g. "The developer community believes service manager X goes against Gentoo |
82 |
principals." |
83 |
|
84 |
Council: "Ok, here is a modified proposal addressing this concern" |
85 |
|
86 |
> > > To use a different example, consider GLEP 39. Many consider GLEP 39 |
87 |
> > > to be special and one that the Council cannot modify, but on the flip |
88 |
> > > side there is currently no real defined process for changing it. |
89 |
> > > (Perhaps GRs will become such a mechanism.) The result is that |
90 |
> > > sometimes changes that might make sense don't really get considered |
91 |
> > > because nobody feels empowered to make it happen. |
92 |
> > |
93 |
> > I don't see why the developer community cannot change GLEP 39 if they so |
94 |
> > chose too. Just no one has wanted to do it. |
95 |
> |
96 |
> Probably because it is a hassle with no defined process. I'm pointing |
97 |
> out that a GR could turn into a similar hassle. Ok, a decision no |
98 |
> longer makes sense, but it is so painful to change that we just live |
99 |
> with it. After all, a new GR requires collecting a bunch of GPG |
100 |
> signatures/etc, even if all the devs and the Council agree with it. |
101 |
> Or should the GR GLEP include a way for the Council to kick off a GR |
102 |
> without the need for the requisite number of individual votes? Maybe |
103 |
> offer that as another option - the Council can initiate a GR with a |
104 |
> majority vote? |
105 |
> |
106 |
|
107 |
What? The council can initiate GR to overrule itself? |
108 |
|
109 |
> Again, my goal here is to improve the GLEP. It isn't some kind of |
110 |
> objection to the concept. |
111 |
> |
112 |
> > > In any case, my point is mainly that the GR GLEP ought to indicate one |
113 |
> > > way or another how a GR can be modified. Presumably a GR can always |
114 |
> > > be used to modify a previous GR. However, do we want to relax things |
115 |
> > > further, such as by allowing GRs to be overriden by Council if there |
116 |
> > > has been a Council election in the interim? |
117 |
> > |
118 |
> > No. The point of the GR is to override council. Not the opposite. So, |
119 |
> > please see the previous paragraphs I wrote above. It nullifies a |
120 |
> > particular decision. The new council will simply try to pass something |
121 |
> > new or modified to fit the needs of the community. |
122 |
> |
123 |
> Presumably they can't pass something new or modified if it is related |
124 |
> to an existing GR, because that would be overriding a GR, which you |
125 |
> don't think ought to be allowed, even if it does better fit the needs |
126 |
> of the community. |
127 |
> |
128 |
|
129 |
You didn't read what I wrote. |
130 |
|
131 |
> If the Council wanted to pass something new or modified they'd need to |
132 |
> propose it as a new GR. As such, the GRs really should be able to |
133 |
> stand on their own without tweaking, because they're going to be hard |
134 |
> to tweak. |
135 |
> |
136 |
> > Please *stop* using the volunteer thing as a crutch. |
137 |
> |
138 |
> Not sure where I ever suggested that being a volunteer excused |
139 |
> non-compliance with policy. I simply pointed out that volunteers may |
140 |
> not be enthusiastic about doing things they disagree with. That is |
141 |
> just reality. It certainly shapes Council decisions, as it ought to. |
142 |
> And again it was more of a philosophical point than a defect that |
143 |
> needed to be addressed. |
144 |
|
145 |
You do often. |