This is the mail archive of the libc-alpha@sourceware.org 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: [PATCH] Revert Abortion joke removal.


On May  8, 2018, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> On 05/08/2018 06:38 AM, Alexandre Oliva wrote:
>> I guess we've somehow miscommunicated, because I'm actually pointing out
>> a weakness in the current rules, that was proponents of the removal of
>> the snippet under dispute were taking advantage of.
>> 
>> The argument brought forth by some of them was precisely that, because
>> Richard did not speak up quickly enough, he would then have to overcome
>> objections, because he'd have been turned into a proponent of a change
>> to revert what had been sneaked past him, whereas had he spoken up very
>> very quickly, those having to overcome objections would be those seeking
>> to make the change.
>> 
>> At the same time, it was argued that the rules were made so that those
>> proposing a change were the ones who had to overcome objections.
>> 
>> See, the *current* rules, per their argument, only serve their stated
>> goals for those who reply very very quickly.  That's a bug.

> Not really, because commits are not necessarily final.

That doesn't mean there isn't a reversal of the burden of overcoming
objections, as someone (I forget who, sorry) pointed out very early in
this debate.  That's what makes a very very quick objection tactically
more powerful to a slightly late one: the latter faces a much heavier
burden to preserve the initial status quo, because they table is turned
as the sneaked-in change is taken as a given and what would have been a
status-preserving objection is now mistaken as a proposed change that
must overcome objections to the reversal.


> They can be reverted (as you have demonstrated), just that there needs
> to be a proper discussion if the opposition comes up after the commit
> has already happened.  It seems that you see the commit as being some
> sort of strategic advantage, which it isn't.

Do you really not see the contradiction between your two sentences?

Is it really just as hard to object to a change, and to have to convince
others who object to backing it out?

If it was so, why was it important for you to highlight the "there needs
to be a proper discussion", if it's just the same, and someone else
wrote something to the effect that now he has to convince others to back
it out?  (feel free to speculate about the latter ;-)


That said, you're right that it's not the installation of the patch
that's the key point.  If objections were taken as such for a bit, even
after the patch was installed, then it wouldn't matter.


> The patch in question is clearly not an ABI change.

Fully agreed.


>> And yet, I do not take advantage of the hole to denounce it.  I waited
>> more than twice as long as the sneaked-in patch for objections.

> The opposition

to what?

> You specifically mentioned RMS' super powers in the project as one of
> the driving reasons for the change,

There was no change.  It's just what it was before the discussion
started, just as it should be until the discussion is over.

It was the removal that had stepped over RMS's objection.  It couldn't
have gone in like that.

> at which point there is no real discussion or dissent, just annoyance.

I totally understand that.  I can't say that RMS dealt with it well.  It
doesn't change the fact that he should have been contacted, that his
objection (in the comments) was ignored, and the patch was put in
despite the lack of consensus.

> If you do the commit as you just did, you do it on the
> basis of those super powers, not on the basis of consensus.

I took his sustained objection, and his decision, as another reason to
proceed to reverse the incorrect status of the tree, indeed, but it's
not correct to say that restoring the initial state was not object of
consensus.

>> The current rules adopted by the community, however, speak of consensus
>> in terms that can be exploited by sufficiently stubborn people (say,
>> like DJ, RMS and myself :-) as DJ has just demonstrated by his blanket
>> objection to any of my future proposals.

> I read DJ's comment as being a reaction to your comment about assumed
> consensus.

I've known DJ long enough, and we've been at opposite sides of debates
long enough, and trolled each other in friendly ways (and, occasionally,
not so friendly ones) enough times that I know he was just pushing it
past the limit to make a point.  Even if it was a bad point ;-)

> In the normal case (i.e. the last 7-8 years!) we have
> successfully put trust in each other to act in good faith.

Looks like we'd never hit such a heated situation in which both sides
accuse each other of cheating the consensus rules, while insisting on
having complied with them.

> We are not a hostile community, as we demonstrated over the past
> years.

I'm sorry to say, but this whole debate seemed very very hostile to me.
I don't exclude myself from that, but I'm not alone in that either.

> The only reason this discussion is turning hostile is because
> (1) commits are being seen as some sort of strategic advantage

But they are, until the rules are changed so that they aren't.

> and (2) there are repeated calls to authority in the absence of actual
> merit in the opposition.

On both sides, I must say.

>> - relax the consensus requirements such that even a sustained objection
>> by a (stubborn) concerned interest won't block changes indefinitely,
>> with fallback decision-making procedures such as collective decisions
>> by maintainers, escalating to GNU or somesuch
>> 
>> BUT
>> 
>> documenting that, being part of GNU, the first and only operating
>> system developed for ethical reasons, GNU libc may be asked to install
>> or to back out changes that might not seem relevant under the
>> technical light of the developer community, but that are deemed
>> important by the GNU project.

> That's not the consensus part, that's the 'dear leader does not like
> it' part.

Yeah, both parts should be there.  We don't want to grant veto powers to
any sufficiently stubborn interest, but we (GNU maintainers) must ensure
GNU can occasionally put in or take out changes decided by the project
as a whole, even if overriding decisions of the specific subproject.
There shouldn't be any surprise or news about that, as much as any of us
might disapprove of the way RMS conveyed his position.  Of course he had
every right to feel extremely insulted for having had his explicit
request (early objection) completely ignored, regardless of his position
in the GNU project.  If he behaved badly, consider he was reacting to
incredible insult.  What excuse did the community have for its
incredibly insulting behavior?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


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