Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

[Rich Freeman]

I'm going to speak generally - this is a list and not really the best
way of dealing with individuals.  If you think the principles apply to
you, feel free to apply them.

On Fri, Oct 31, 2014 at 7:50 PM, Diego Elio Pettenò
<flameeyes@×××××××××.eu> wrote:
> I'm more convinced than ever that either someone else (Council? QA?
> the Pope?) fixes this, or I'll add myself to that list.

The fundamental problem here is that we're a volunteer organization,
which means we're limited to the resources people offer us.  Sometimes
these resources are offered conditionally, and our choice can end up
being "take it" or "leave it."

I do tend to agree that accepting the gift with strings can cost you
more in the long term than just doing without.

The problem comes when somebody in a critical position wants to take a
hard stand on something.  You either end up making an exception for
them, relaxing policy for everybody, or risk being left in a hard
place if they choose to stop contributing.

Now, something that we have been trying to do is remove artificial
roadblocks.  For example, if somebody is standing in the way of others
contributing the Council can step in and tell the others that they can
go ahead and prevent anybody from interfering from them.  Examples of
this are somebody wants to add support for some feature to a bunch
packages and assume responsibility any issues, and a maintainer wants
to block them.

What we can't do is force somebody to contribute.  If somebody says
that if we don't do multilib their way, they'll stop being the only
libreoffice maintainer, and nobody else wants to maintain libreoffice,
then we are left in a hard place (completely contrived scenario).

We can stop people from interfering, but we can't make them contribute.

So, in a case like this we certainly could prevent somebody from
closing a bug, but we certainly can't force them to fix a bug.  We
could also block somebody from submitting tinderbox bugs without
attached logs, but we can't force them to run a tinderbox.

So, if there is a better way, I'm all ears for constructive
suggestions.  By constructive I mean that somebody who comes up with a
script that automatically retrieves build logs and attaches them to
bugs is being more helpful than somebody who says that somebody else
should come up with such a script, and so on.  That doesn't mean that
we can't talk about solutions before we build them - only that it
isn't helpful when we basically demand that others build them for us.

--
Rich