Machine maintainer veto.

[Carlos O'Donell]

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.