This is the mail archive of the
mailing list for the glibc project.
Re: Machine maintainer veto.
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot comcom>
- To: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 06 Jul 2015 13:09:03 -0500
- 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>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Mon, 2015-07-06 at 17:08 +0100, 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.
> >>> 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
> 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.
It takes at least two to be constructive. Some like argue perfection or
require convincing everyone (not just GLIBC community members) to change
what they are already doing to a more "correct" way. Like saying users
are stupid and they doing it wrong is not constructive.
Straw-man, slipper slope, moral hazards argument should be excluded,
because there there no rational response to a an irrational argument.
If we don't restrain this behavior, we allow individuals to block
platform specific patches indefinitely.
> What I think would be very dangerous would be if consensus came to mean
> 'simple majority'.
> Just my 2 penn'orth.
> >> 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.