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

[Rich Freeman]

On Thu, Jun 28, 2018 at 3:03 PM Aaron Bauman <bman@g.o> 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@g.o> 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."

> 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?

GLEP 39 only requires them when there are disagreements between
projects.  In the absence of disagreement between projects, no Council
votes are required.

> 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.

> 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.

> > 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?

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.

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.

-- 
Rich