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

[Michał Górny]

W dniu czw, 28.06.2018 o godzinie 13∶24 -0400, użytkownik Rich Freeman
napisał:
> 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.

The meaning of this is explained in the parentheses, so please stop
trying to bend it.  The only thing it means is that you can't call a GR
to pass a motion that didn't go through the Council vote yet.

>
> Presumably you wouldn't want the current Council to be able to
> override a GR, but how about a subsequent one?  A lot of decisions are
> made on the basis of some context that could change.

There's no explicit necessity to impose additional restrictions
on further Council actions.  Trying to define them correctly would make
the GLEP unnecessarily complex, not to mention it'd probably end up
being imperfect.  Instead, think of GR as a penalty card.

When Council makes an apparently bad decision, the developers can give
it a yellow card.  The Council is still in the game and can technically
can do the same thing again -- however, it has been given an explicit
warning, so I don't think we really need to consider it carelessly
passing the same motion again.

What can happen (and shouldn't be blocked) is that the Council
reconsiders, gathers wider feedback and passes a different motion that's
more suitable to developers.  Or the same or future Council reconsiders
this at some point in the future.

Of course, this means that technically Council could ignore the GR
and pass the same motion again.  However, if that actually happens,
they can expect immediate GR on disbanding the Council.

>
> To use your example, suppose there is a GR to make OpenRC the default
> service manager.  Great.  What happens in 10 years when it makes sense
> to make some new service manager the default?  Normally such a
> decision wouldn't even require a Council vote, but if the previous GR
> has no expiration, then does that mean that another GR is required to
> make a decision that may not be as controversial in the future?

As said above, the same or future Council can pass the same or similar
motion at any point in the future.

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

No.  The GLEP repeats that multiple times: GR is not a generic voting
mechanism but a failsafe.  I'd say calling for a global developer vote
is within Council's regular powers, and it's entirely outside the scope
of this GLEP.

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

It really seems that you didn't understand the GLEP, and instead started
processing with your own vision of GR that's not related to my proposal.

-- 
Best regards,
Michał Górny