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: munroesj at linux dot vnet dot ibm dot com
- Cc: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 08 Jul 2015 18:30:49 +0200
- Subject: Re: Machine maintainer veto.
- Authentication-results: sourceware.org; auth=none
- References: <559606DB dot 6070600 at redhat dot com> <CAAHN_R2bjFU29Q7TTV2AHxEw-UN_RNHWrs3URKu+Ejq+=LUgLA at mail dot gmail dot com> <5596AED1 dot 8060203 at redhat dot com> <559AA805 dot 3020904 at foss dot arm dot com> <1436206143 dot 19117 dot 14 dot camel at oc7878010663> <1436220236 dot 22407 dot 8 dot camel at localhost dot localdomain> <1436366905 dot 6487 dot 16 dot camel at oc7878010663>
On Wed, 2015-07-08 at 09:48 -0500, Steven Munroe wrote:
> On Tue, 2015-07-07 at 00:03 +0200, Torvald Riegel wrote:
> > > Like saying users
> > > are stupid and they doing it wrong is not constructive.
> >
> > Agreed on the "are stupid", but saying that they are doing something
> > that is not something glibc wants to support is not something that's
> > necessarily bad.
> >
> But they you should be talking to them, explaining to them, convincing
> them.
>
> Holding a platform maintainer hostage does not help you.
I don't think that the goal is to hold the platform maintainer hostage.
If the project, as a whole, should decide to not support something, then
it can do that. Making sure that users at least understand the
background of the decision is worthwile, of course; likewise, serving
users makes sense too :) However, the project must be able to make
decisions even if not all users agree with that decision.
One could also argue that users should not blame a platform maintainer
for a decision of the project as a whole -- IOW, the hostage situation
is not just due to the project's decisions.
As another example (with a somewhat GCC-ish background), consider that
likely lots of code out there assumes a memory model like x86' TSO
(e.g., some glibc code did). It would probably be useful to many users
if we'd just promise those guarantees. If such users would approach you
as platform maintainer and request you to give you those guarantees, I
guess you would decline this request :) It would be even harder for
them to adapt their code for a weak memory model than in the specific
case that you want to see support for.