This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Machine maintainer veto.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 03 Jul 2015 11:48:33 -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>
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.
> 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.