This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Machine maintainer veto.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 03 Jul 2015 18:27:05 +0200
- 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>
On Fri, 2015-07-03 at 11:34 -0400, Rich Felker wrote:
> In terms of impact, I think there's a false notion that machine
> maintainers' decisions don't impact anyone but their machine's users,
> and therefore that as long as they act in the interest of their users,
> nobody is harmed by their decisions. This is wrong for multiple
> reasons. User-visible changes potentially affect anyone writing
> portable software -- when their software behaves unexpectedly on the
> machine maintainer's target, they (not the glibc machine maintainers)
> are the ones who generally take the blame and deal with the costs of
> working around whatever the issue is. And while non-user-visible
> changes shouldn't affect applications, they do constrain general glibc
> development. Every bit of machine-specific code/behavior increases the
> cost of making changes to glibc in the affected area, and in a worst
> case machine-specifics can even constrain the implementation in ways
> that preclude serious improvements.
Agreed. On example is that we seem to assume that if someone wants to
fix/change/... something that has both a generic implementation and an
arch-specific implementation, this person is responsible for both. This
makes sense I think -- however, if the arch maintainer used her/his veto
rights for this particular piece of code, it seems the arch maintainer
should then have to deal with the fallout from the deviation from the
community's direction. But enforcing that would mean that we track when
veto rights are exercised, in some way -- which I can't imagine being
fun for anyone.