This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Machine maintainer veto.

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. 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]