This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Machine maintainer veto.
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot comcom>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: munroesj at linux dot vnet dot ibm dot com, Rich Felker <dalias at libc dot org>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 06 Jul 2015 18:02:26 -0500
- 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> <1436189186 dot 9162 dot 20 dot camel at oc7878010663> <1436220635 dot 22407 dot 14 dot camel at localhost dot localdomain>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Tue, 2015-07-07 at 00:10 +0200, Torvald Riegel wrote:
> On Mon, 2015-07-06 at 08:26 -0500, Steven Munroe wrote:
> > There has to be a balance between the consensus of the community and the
> > requirements of the platform (as represented by the maintainer).
>
> Note that the consensus of the community may be a requirement for the
> community too (ie, there may be conflicting requirements).
>
> > 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.
>
> What would you suggest as mechanism to "protect" the community from
> machine maintainers making decisions that conflict with the community's
> interests?
>
> For example, would it be okay for you if machine maintainers would have
> to be responsible for their changes on their won if they exercised their
> "veto rights"? (That is, if they go their own machine-specific way
> against a different community consensus, they can't necessarily expect
> generic code to be compatible with their own way, nor authors of generic
> code to put a lot of effort into making it compatible.)
>
Yes I agree that I would not expect the community to support my platform
specific tricks that are not part of the GLIBC API. We (the community)
agreed to carved out the ./sys/platform/ extension for exactly this
purpose. So ./sys/platform/ppc.h is left for the PPC maintainers
But at the same time I would not expect the community (really just a few
individuals with strong opinions on the topic) to force a platform
maintainer to implement a GLIBC feature exactly like another platform.
Especially if the suggested design is impractical or highly inefficient
for that platform.
Over the years GLIBC has developed and supported mechanisms for platform
specific extension to allow all platforms to contribute to the common
implementation. I assume this will continue.
I would not expect and would actively oppose assertions that specific
feature like IFUNC and TLS storage are the only solution to specific
design problem. Because each platform has a different set of hardware
software trade-offs.