Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sat, Mar 29, 2014 at 10:36 AM, William Hubbs <williamh@g.o> wrote:
>
> We are supposed to be a team, and if a few people aren't team players,
> I would rather see energy spent on fixing that issue instead of trying
> to legislate every possible corner case.

So, a few thoughts on the whole issue in general.

1.  When somebody wants to do something in a way completely different
from how things have been done before or in a way that impacts how
many packages will be maintained, it is best to discuss it on the
lists first.  That doesn't mean that you can't proceed without
unanimous consent, but rather that even good ideas can become better
ideas with more input.  That said, when an issue comes up those who
object need to at least speak up ahead of time, because after-the-fact
isn't the time for I-told-you-so.  That has come up a few times lately
- you don't need to have the last reply on the thread to win the
argument, but that doesn't mean that you shouldn't speak up at all.

2.  When there is a change in the tree that threatens to be disruptive
to users/dev/etc QA has the right to step in.  The necessity of doing
this should really be considered first - if simply saying "hold on,
don't do any more of this for a few days" is sufficient to get by,
that should be preferred over masks/bans/etc.  On the other hand, if
users are being adversely affected by something and this will get
worse with time, it is better to stop the bleeding.  Think of it like
asking a court for an emergency stay/injunction/etc - courts generally
prefer to hear the whole case before taking action, but if there is
some kind of irreversible harm at stake, they'll act first and sort it
out later.  Obviously QA should manage its own guidelines as to when
individuals should act in the name of QA.

3.  In general the absence of an explicit policy should never be
considered grounds for ignoring #1 or preventing #2.  The real
principle is cooperation and managing disruptive change.  QA can step
in even if you can't quote a specific rule that was broken (though
they should be careful before doing so), and I really don't want to
hear excuses like "well, there was no rule saying I had to play nicely
with the other kids."  We really don't want to have to maintain the
Code of Gentoo Regulations.

So, I'd certainly endorse that things like profile changes, eclass
changes, and changes that impact many reverse-deps should be announced
on the list and coordinated in general if they aren't routine.  That
said, I don't see the need to codify this in some kind of explicit
policy - I'd argue that it already is policy.  I don't want to get
into back-and-forth on how to word a policy so that a dev masking
their own package is fine but a dev removing bash from the system set
isn't.  If somebody can't tell the difference between these, they
shouldn't have commit access.

Rich