On Thursday, June 28, 2018 3:33:24 PM EDT Rich Freeman wrote: > On Thu, Jun 28, 2018 at 3:03 PM Aaron Bauman wrote: > > On Thursday, June 28, 2018 1:24:27 PM EDT Rich Freeman wrote: > > > On Thu, Jun 28, 2018 at 12:14 PM Michał Górny wrote: > > > > a. the Council decision in question is final (i.e. a general > > > > > > > > resolution can not be used to bypass the Council), > > > > > > One question that this brings up in my mind is the duration of these > > > decisions, because Council decisions are never really final. The > > > Council can override its own decisions, or the decision of a prior > > > Council. > > > > By this logic then nothing is final. We might as well throw it all away. > > Finality has nothing to do with throwing stuff away. Decisions are > made at a point in time. They aren't generally discarded lightly, but > they also aren't clung to when they no longer make sense. That is all > I'm getting at. > > > It is my impression that the GR is not "overridable" because it is a > > developer wide vote. The important people are the developers... > > Great. Then write that into the GLEP so that is clear. My whole > point is that we shouldn't have to rely on your "impression." > It is clear. It is understood. If you have an issue with it then send mgorny a patch. As stated, it nullifies a particular decision. Plain and simple. > > A council vote should *absolutely* be required to change the default > > service manager. > > Sounds like you'll be needing another GLEP then. What other decisions > should explicitly require Council votes? > "Global issues". Again, we can't legislate common sense. > GLEP 39 only requires them when there are disagreements between > projects. In the absence of disagreement between projects, no Council > votes are required. > Looks like you need to read GLEP39 again. The word agreement isn't even found in it. (Hint: "Global issues will be decided by an elected Gentoo council.") > > The GR GLEP, as Michał has written it, does indeed not have an expiration > > date. The assumption you have made here worries me though. We *cannot* > > legislate common sense. By the developer community enacting the general > > resolution it is nullifying that particular decision. The controls of > > which are clearly outlined. > > I'm not sure what "assumption" I've made here. I've simply pointed > out that nothing in the policy states how a GR is to be reversed. I > then proposed scenarios for how that could cause questions to come up. > My goal is to make the policy less ambiguous. > It doesn't *need* to be reversed. It is a nullification of a decision because of disagreement by the developer community. So, the council should react by trying something that is "in line" with the issues that were brought up. Plain and simple. > > A subsequent council would simply propose another vote to change the > > default service manager when the time is appropriate. It should be clear > > as to why the GR was enacted (which is detailed in the GLEP) and it > > should be clear to any subsequent voting members what issues the > > *developers* had with it. > If there is no longer any controversy over the new decision (which > might be many years later), why require an all-dev vote? And of > course a GR can always be used to re-override the Council decision if > necessary. Obviously you'd want some controls on this so that we > don't end up with the same issues being re-voted upon repeatedly. > No, the council just proposes a new/modified proposal to vote on. This should have been a product of civil discourse. Understanding what the issues were and addressing them. e.g. "The developer community believes service manager X goes against Gentoo principals." Council: "Ok, here is a modified proposal addressing this concern" > > > To use a different example, consider GLEP 39. Many consider GLEP 39 > > > to be special and one that the Council cannot modify, but on the flip > > > side there is currently no real defined process for changing it. > > > (Perhaps GRs will become such a mechanism.) The result is that > > > sometimes changes that might make sense don't really get considered > > > because nobody feels empowered to make it happen. > > > > I don't see why the developer community cannot change GLEP 39 if they so > > chose too. Just no one has wanted to do it. > > Probably because it is a hassle with no defined process. I'm pointing > out that a GR could turn into a similar hassle. Ok, a decision no > longer makes sense, but it is so painful to change that we just live > with it. After all, a new GR requires collecting a bunch of GPG > signatures/etc, even if all the devs and the Council agree with it. > Or should the GR GLEP include a way for the Council to kick off a GR > without the need for the requisite number of individual votes? Maybe > offer that as another option - the Council can initiate a GR with a > majority vote? > What? The council can initiate GR to overrule itself? > Again, my goal here is to improve the GLEP. It isn't some kind of > objection to the concept. > > > > In any case, my point is mainly that the GR GLEP ought to indicate one > > > way or another how a GR can be modified. Presumably a GR can always > > > be used to modify a previous GR. However, do we want to relax things > > > further, such as by allowing GRs to be overriden by Council if there > > > has been a Council election in the interim? > > > > No. The point of the GR is to override council. Not the opposite. So, > > please see the previous paragraphs I wrote above. It nullifies a > > particular decision. The new council will simply try to pass something > > new or modified to fit the needs of the community. > > Presumably they can't pass something new or modified if it is related > to an existing GR, because that would be overriding a GR, which you > don't think ought to be allowed, even if it does better fit the needs > of the community. > You didn't read what I wrote. > If the Council wanted to pass something new or modified they'd need to > propose it as a new GR. As such, the GRs really should be able to > stand on their own without tweaking, because they're going to be hard > to tweak. > > > Please *stop* using the volunteer thing as a crutch. > > Not sure where I ever suggested that being a volunteer excused > non-compliance with policy. I simply pointed out that volunteers may > not be enthusiastic about doing things they disagree with. That is > just reality. It certainly shapes Council decisions, as it ought to. > And again it was more of a philosophical point than a defect that > needed to be addressed. You do often.