1 |
On Thursday, June 28, 2018 1:24:27 PM EDT Rich Freeman wrote: |
2 |
> On Thu, Jun 28, 2018 at 12:14 PM Michał Górny <mgorny@g.o> wrote: |
3 |
> > a. the Council decision in question is final (i.e. a general |
4 |
> > |
5 |
> > resolution can not be used to bypass the Council), |
6 |
> |
7 |
> One question that this brings up in my mind is the duration of these |
8 |
> decisions, because Council decisions are never really final. The |
9 |
> Council can override its own decisions, or the decision of a prior |
10 |
> Council. |
11 |
> |
12 |
|
13 |
By this logic then nothing is final. We might as well throw it all away. |
14 |
|
15 |
> Presumably you wouldn't want the current Council to be able to |
16 |
> override a GR, but how about a subsequent one? A lot of decisions are |
17 |
> made on the basis of some context that could change. |
18 |
> |
19 |
|
20 |
A subsequent one? Like a subequent council being allowed to override a GR? |
21 |
It is my impression that the GR is not "overridable" because it is a developer |
22 |
wide vote. The important people are the developers... |
23 |
|
24 |
> To use your example, suppose there is a GR to make OpenRC the default |
25 |
> service manager. Great. What happens in 10 years when it makes sense |
26 |
> to make some new service manager the default? Normally such a |
27 |
> decision wouldn't even require a Council vote, but if the previous GR |
28 |
> has no expiration, then does that mean that another GR is required to |
29 |
> make a decision that may not be as controversial in the future? |
30 |
> |
31 |
|
32 |
A council vote should *absolutely* be required to change the default service |
33 |
manager. Of course, we know in practice this has been addressed by having |
34 |
different flavors of stage3 tarballs for the user. Continuing on though, this |
35 |
is a part of the *technical* direction that the council should provide. |
36 |
|
37 |
Also, it has far-reaching impacts by doing something like this. We have seen |
38 |
individuals transition to Gentoo because we gave them a choice of service |
39 |
manager! (It would not be a bad idea to consider a poll across the developer |
40 |
community for a situation like this as well). |
41 |
|
42 |
The GR GLEP, as Michał has written it, does indeed not have an expiration |
43 |
date. The assumption you have made here worries me though. We *cannot* |
44 |
legislate common sense. By the developer community enacting the general |
45 |
resolution it is nullifying that particular decision. The controls of which |
46 |
are clearly outlined. |
47 |
|
48 |
A subsequent council would simply propose another vote to change the default |
49 |
service manager when the time is appropriate. It should be clear as to why |
50 |
the GR was enacted (which is detailed in the GLEP) and it should be clear to |
51 |
any subsequent voting members what issues the *developers* had with it. An |
52 |
attempt to try and pass it again with all circumstances the same would be |
53 |
ignorant. Civil discourse is important. |
54 |
|
55 |
> To use a different example, consider GLEP 39. Many consider GLEP 39 |
56 |
> to be special and one that the Council cannot modify, but on the flip |
57 |
> side there is currently no real defined process for changing it. |
58 |
> (Perhaps GRs will become such a mechanism.) The result is that |
59 |
> sometimes changes that might make sense don't really get considered |
60 |
> because nobody feels empowered to make it happen. |
61 |
> |
62 |
|
63 |
I don't see why the developer community cannot change GLEP 39 if they so chose |
64 |
too. Just no one has wanted to do it. |
65 |
|
66 |
> In any case, my point is mainly that the GR GLEP ought to indicate one |
67 |
> way or another how a GR can be modified. Presumably a GR can always |
68 |
> be used to modify a previous GR. However, do we want to relax things |
69 |
> further, such as by allowing GRs to be overriden by Council if there |
70 |
> has been a Council election in the interim? |
71 |
> |
72 |
|
73 |
No. The point of the GR is to override council. Not the opposite. So, |
74 |
please see the previous paragraphs I wrote above. It nullifies a particular |
75 |
decision. The new council will simply try to pass something new or modified to |
76 |
fit the needs of the community. |
77 |
|
78 |
> My last comment is more philosophical. I do support the concept |
79 |
> behind this, but I do want to note that it is a lot easier to vote for |
80 |
> something to happen than to actually make it happen. If devs |
81 |
> consistently vote for Council members who support position A, but then |
82 |
> vote via GR to impose position NOT A, it creates a bit of |
83 |
> organizational schizophrenia as there really is no executive process |
84 |
> to appeal council decisions and thus you end up tasking people to |
85 |
> execute a policy they don't actually agree with, as volunteers. The |
86 |
> likely result will be half-hearted at best, even if no outright |
87 |
> defiance takes place. So, this is a mechanism that will need to be |
88 |
> used carefully, but I think having it available as a recourse is |
89 |
> better than not having it available. |
90 |
|
91 |
We cannot possibly know what every person will do when they are elected to the |
92 |
council. Furthermore, we cannot possibly know what issues may arise. This is |
93 |
one of the reasons I have decided to *not* write a manifesto. Let my fellow |
94 |
developers ask me questions important to *them*. This provides a better |
95 |
measurement of how I may or may not vote. |
96 |
|
97 |
To enact a GR requires a significant amount of developers to agree on a matter. |
98 |
This is the litmus test to address any potential "schizophrenic" like |
99 |
scenarios from happening. Once again, you cannot legislate common sense and I |
100 |
would venture to say that this is often why a majority or similair approach is |
101 |
done. If I can get a group of people to agree upon something then I can be |
102 |
*somewhat* sure it is a sane thing. |
103 |
|
104 |
You mean like a policy to enable whitelisting on the gentoo-dev mailing list? |
105 |
I am quite sure Antarus was not happy to do that as he publicly stated in many |
106 |
forums. While we may be volunteers we still must honor the roles individuals |
107 |
hold within the ecosystem. |
108 |
|
109 |
Please *stop* using the volunteer thing as a crutch. |
110 |
|
111 |
-Aaron |