Re: Machine maintainer veto.

[Rich Felker <dalias at libc dot org>]

On Fri, Jul 03, 2015 at 08:58:58AM -0400, Carlos O'Donell wrote:
> On 07/03/2015 02:20 AM, Rich Felker wrote:
> > On Thu, Jul 02, 2015 at 11:51:55PM -0400, Carlos O'Donell wrote:
> >> Community,
> >>
> >> I have attempted to clarify what has always been in effect.
> >> The machine maintainers have some level of veto for what goes
> >> into their machine port. This allows some amount of control over
> >> hardware support and ABI/API additions and removals.
> >>
> >> 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 know I don't have any standing to change it, but I just want to
> > express a sentiment that I think this is bad policy. I can go into the
> > details of why if anyone is interested.
> 
> I am absolutely interested in hearing the details.

On a level of principles, I think it violates the principle of
consensus and preserves part of the toxic dictatorship impression that
glibc used to have. The project has come a long way in shedding this
impression, and in my opinion has become _the_ most open and healthy
GNU project in terms of development process. I'd like to see this
progress continue.

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.

There's also the matter of bugs and conformance. Machine maintainers
are not necessarily experts in standards conformance, portability, and
related ABI issues, and unless they also happen to be experts in these
fields, they should not be treated as such. At least the following
bugs are results of machine-specific code/definitions being approved
for inclusion in glibc without regard for how they affect standards
conformance:

https://sourceware.org/bugzilla/show_bug.cgi?id=5945
https://sourceware.org/bugzilla/show_bug.cgi?id=16437
https://sourceware.org/bugzilla/show_bug.cgi?id=16919
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2f3a499e6b803802880aea1fb8d3b46f1959494f
(I don't think this one has a glibc bug tracker issue yet, but the
kernel-side "fix" was a regression and made the types wrong and
inconsistent -- st_mode is 32-bit but ipc_perm.mode is 16-bit -- and
it was made because the glibc userspace type was wrong.)

I don't know the history of how they were introduced, but the current
policy, at least as expressed by Carlos, seems to make it possible for
machine maintainers to dictate (by veto) the introduction of such bugs
even if they were detected and objected to by others. I think we
should be striving for the opposite: objective conformance checks that
machine-specific definitions for new targets have to pass before being
accepted into glibc.

Security also comes under the area of bugs. Being a machine maintainer
should not entitle someone to do things in a machine-specific way
that's less secure than the way the same thing is handled on other
machines. Even if it only affects users of their target, the resulting
CVE makes glibc look bad.

Rich