This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Machine maintainer veto.
- From: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 06 Jul 2015 17:08:37 +0100
- Subject: Re: Machine maintainer veto.
- Authentication-results: sourceware.org; auth=none
- References: <559606DB dot 6070600 at redhat dot com> <CAAHN_R2bjFU29Q7TTV2AHxEw-UN_RNHWrs3URKu+Ejq+=LUgLA at mail dot gmail dot com> <5596AED1 dot 8060203 at redhat dot com>
On 03/07/15 16:48, Carlos O'Donell wrote:
> On 07/03/2015 11:44 AM, Siddhesh Poyarekar wrote:
>> On 3 July 2015 at 09:21, Carlos O'Donell <carlos@redhat.com> wrote:
>>> The key issue is to balance the project goals and the needs of
>>> the users of the particular machine. To do that effectively the
>>> machine maintainers have to have some level of veto to add or
>>> remove things to the machine they know and understand best.
>>>
>>> https://sourceware.org/glibc/wiki/MAINTAINERS#Machine_maintainers
>>
>> I don't quite agree with this:
>>
>> "... This veto can be used to prevent changes that break ABI or
>> API, or it can be used to include new ABI support for the machine even
>> if there is no consensus on how best to proceed"
>>
>> While I acknowledge that arch maintainers have a better understanding
>> of their architecture, it doesn't automatically translate to a deep
>> enough understanding of glibc in general and that can break things in
>> irreversible ways. Also, arch maintainers are as accountable to the
>> glibc community as they are to their customers or their organization,
>> so ignoring consensus goes against that principle.
>
> That is a very good point.
>
>> There is a middle ground though, where arch maintainers have enough
>> freedom to decide what goes into their port as long as it doesn't
>> conflict with the goals of the community. So it should be OK if a
>> maintainer chooses to ignore objection for a patch from a community
>> member on minor differences. However, if there is sustained
>> opposition from the community in general, it would be inappropriate
>> for the maintainer to ignore that feedback.
>
> This calls for consensus.
To me, consensus means 'a lack of objection'. So if anyone is objecting
then you do not have consensus. That means, in effect, that everyone
has a veto!
The problem then is that this could lead to deadlock and we'd need a way
to resolve that. I'd hope that in general we'd want to either ensure
that the expressed concerns were not relevant (a misunderstanding) or
that an appropriate alternative that was generally acceptable could be
found.
I think also, the right to exercise (and maintain) a veto should come
with the responsibility to work *constructively* with the proposer to
find an acceptable resolution: it can't be a simple stone-wall.
What I think would be very dangerous would be if consensus came to mean
'simple majority'.
Just my 2 penn'orth.
R.
>
>> I admit this is still vague, but ISTM to be a better place to be than
>> a full veto described in the wiki page.
>
> Agreed. I'll let others comment a bit further before I summarize the
> positions with a new block of text to describe the machine maintainers
> responsibilities.
>
> Cheers,
> Carlos.
>