Re: Machine maintainer veto.

[Steven Munroe <munroesj at linux dot vnet dot ibm dot comcom>]

On Fri, 2015-07-03 at 11:34 -0400, Rich Felker wrote:
> 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.
> 
There has to be a balance between the consensus of the community and the
requirements of the platform (as represented by the maintainer).

Democratic consensus can quickly turn into the mob rule, where ignorance
or malice of community members with strong but unfounded opinions can
also do great harm. Read up on the Death of Socrates or later stages of
the French revolution.

I think we need a balance of Powers definition that protects both
interests.

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