This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Machine maintainer veto.
- From: Rich Felker <dalias at libc dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 3 Jul 2015 12:54:38 -0400
- Subject: Re: Machine maintainer veto.
- Authentication-results: sourceware.org; auth=none
- References: <559606DB dot 6070600 at redhat dot com> <20150703062020 dot GN1173 at brightrain dot aerifal dot cx> <55968712 dot 2020604 at redhat dot com> <20150703153427 dot GP1173 at brightrain dot aerifal dot cx> <5596AE46 dot 7030507 at redhat dot com> <20150703163836 dot GQ1173 at brightrain dot aerifal dot cx>
On Fri, Jul 03, 2015 at 12:38:36PM -0400, Rich Felker wrote:
> On Fri, Jul 03, 2015 at 11:46:14AM -0400, Carlos O'Donell wrote:
> > Thank you for that writeup. My initial text in the wiki is certainly a
> > starting point, and I think we need to refine it. The community does need
> > to decide how much power a machine maintainer should be given. Your comments
> > go a long way to adding to and broadening this discussion.
> >
> > Would it be sufficient to soften the language to say that the machine
> > maintainer has blanket commit privileges for their machine, but that they
> > remain responsible to the distributions, users, the project as a whole and
> > that such blanket commit privileges should be used responsibly?
> >
> > Therefore we couch the language in terms of responsibility to the community?
>
> Yes, I think that's a good approach. I would also suggest something
> along the lines of what I said about sticking to their areas of
> expertise, but perhaps written in a way that's less accusatory. The
> idea is that maintainers should have some authority over (but still be
> responsible to distros/users/project/etc.) things that are genuinely
> machine issues, but that authority does not/should not extend to
> things that affect API, especially API correctness. (Note that most of
> the 'ABI' issues I cited are actually API issues.)
BTW, another specific issue I expect to come up again and again is
performance, particularly situations where a machine maintainer wants
a "fast" implementation of some function that's fast in the cases they
care about but O(nÂ) whereas the generic implementation is O(n) or
O(n*log(n)). I would say this is a situation where allowing the
bad-big-O implementation should require consensus at the project level
rather than machine maintainer veto discretion. The right solution in
general is almost sure to be something like the introsort solution
(self-measurement to fall back to generic code for cases where
worst-case performance is imminent) which is more work for the
machine-specific code contributor or machine maintainer but better for
the project.
Rich