This is the mail archive of the
mailing list for the glibc project.
Re: Machine maintainer veto.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Richard Earnshaw <Richard dot Earnshaw at foss dot arm 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 12:47:05 -0400
- 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> <559AA805 dot 3020904 at foss dot arm dot com>
On 07/06/2015 12:08 PM, Richard Earnshaw wrote:
> 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 <email@example.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.
>>> 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!
Yes, and no.
Sustained opposition is different from a technical objection. You may
object, but realize that your objection is technically infeasible until
say a newer technology is available. However, your objection is recorded
for all to read at a future date when someone is reading the mailing
list with respect to the given change (and perhaps the newer technology
is now available).
You could argue that an important part of the concerned interests have
been met if the distribution maintainers agree with your change, at which
point the machine maintainer might argue to checkin the patch given the
Your response would have to make this crystal clear.
> 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
> 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.
Agreed, which is why I think veto is perhaps the wrong word to use in
the maintainer description.
> What I think would be very dangerous would be if consensus came to mean
> 'simple majority'.