Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Aaron Bauman <bman@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 6927 bytes --]

On Thursday, June 28, 2018 3:33:24 PM EDT Rich Freeman wrote:
> On Thu, Jun 28, 2018 at 3:03 PM Aaron Bauman <bman@gentoo.org> 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 <mgorny@gentoo.org> 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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]