This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Machine maintainer veto.


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 <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.
> 
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.
> 
> 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.
> > 
> 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]