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:38:36 -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>
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.)
Rich