Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

On Sun, Jun 30, 2013 at 01:56:05PM -0700, Brian Dolbec wrote:
> Overall, I agree with both sides
> 
> 1) What Chí-Thanh said is true:
> 
> Yes, cooperation is better. But the method how to achieve cooperation is
> convincing through arguments,...
> 
> 2) What Rich said is also true:
> 
> Maintaining a package is a privilege conditioned
> on using that power in alignment with our philosophies, not a right.
> 
> 
> The main problem here is finding the right balance between convincing
> (first choice) and mandating (if convincing fails).  Unfortunately, like
> anywhere else in this world, not everyone will agree on where that
> balance point should be.  There will always be extremists on both ends
> of the debate.  It is the developers votes that will determine which end
> of the spectrum the balance point will be.  It is also prudent for them
> to vote in someone that can see both ends of the spectrum ;)

Nothing is an absolute. I'm not saying that anyone who doesn't like
something a maintainer does should be able to force the maintainer to do
what they want.

Chithanh, please stop me and correct me if I am wrong.

The way I understand what you are saying is that you believe the
maintainers have absolute authority over what happens with their
packages. So if I file a bug against a package requesting a change that
I think would bring the package more in line with the gentoo philosophy for
example and explain to the maintainer why I think that is the case and
He closes my bug invalid or wontfix, you feel that I should not take my
concerns to qa or the council. correct?

What happens if I am actually a co-maintainer but another co-maintainer
blocks my changes?

imo there should be, and is, an arbitration path for this sort of thing.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]