Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Rich Freeman]

On Fri, Aug 12, 2016 at 1:48 PM, M. J. Everitt <m.j.everitt@×××.org> wrote:
>
> I regret to say, although it's a well-known problem .. that the Gentoo
> bike-shed is never ever going to fall down - as the layers of paint
> applied will grossly outlive the materials it might once have been built
> from ... Perhaps someone might like to address the problem of the
> nuclear reactor which will otherwise never ever be functional ... ;)
>

Bikeshedding is only a problem if you let it be one.

Gentoo does not require unanimous consensus to get things done.  If
you choose to wait for it, and then complain about bikeshedding, then
YOU are the problem.

If I were James I would:

1.  Consider the advice given and propose the best way forward.
Indicate that I intend to commit the changes to the Gentoo repo in 48h
if there are no objections raised by QA or to Council.
2.  If there are no objections raised to Council or by QA then go
ahead with the commits, unless personally convinced by any further
arguments.
3.  If an objection was raised to QA, then comply with it for now, and
if in disagreement first work with QA, and appeal to Council if
necessary.
4.  If somebody appeals to Council, then let them make their case, and
offer my own, and await a decision.

If you do the above you'll never get in trouble, and you've basically
put the ball in somebody else's court if they want to hold you up.
Usually you won't delay your change by more than 48h, and if you do it
won't be by more than a month, unless the Council overrides you (in
which case you're "stuck" though presumably they would have good
reasons for doing so).

Some mistakes I see people make all the time:
1.  Give up as soon as a few devs make vocal complaints.  This is not
a shouting match.  The person with the most thread posts doesn't
automatically win the argument.
2.  Wait until everybody agrees.  While there are things everybody
agrees on, there aren't many of them.  I'm not sure the last sentence
even falls into that list of things everybody agrees on.  :)
3.  Plow forward without giving some time for appeals.  This can lead
to revert wars and such.
4.  Ignore official QA notices.  If a member of QA notifies you that
QA is taking action, you must comply until you resolve the issue with
QA or by appeal.
5.  Fail to work with QA.  The fact that a random QA member takes an
action doesn't mean that all of QA is necessarily behind it.  You may
find the issue resolved by spending 30 seconds on IRC.  The QA lead is
responsible to deal with these kinds of issues.
6.  Fail to let the Council clear roadblocks.  If you're trying to do
something, and you feel that something is blocking you, the Council
can help resolve that.

Devs get frustrated by bikeshedding because they're imposing rules and
limitations upon themselves that aren't actually community rules.  You
don't have to give up just because a few devs complain.  You ought to
listen, and if it is really controversial push for a decision.
However, strictly speaking if you have commit rights to the tree and
aren't violating a documented policy, then the onus is on others to
stop you, not for you to obtain permission to do something.  You
shouldn't abuse that, and hence I suggest giving people time to lodge
formal objections.  However, if you care about getting something done
it is completely fair to force those who wish to impede you to step up
and do the work to actively block you.  Devs don't have to prove the
"innocence" of each commit.

-- 
Rich