[PATCH] Revert Abortion joke removal.

[Siddhesh Poyarekar]

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

It becomes an irreversible issue if the commit in question has an ABI 
change and we are near a release (in which case our 1 month freeze 
protects us) but in those cases we as a community stick to the more 
conservative stand of backing out the change.

The patch in question is clearly not an ABI change.

> 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 was apparent in every email everyone sent, so it is 
clearly not a consensus decision.  You specifically mentioned RMS' super 
powers in the project as one of the driving reasons for the change, at 
which point there is no real discussion or dissent, just annoyance.  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.

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

>> and don't encourage people to quickly pile on to every patch they
>> dislike for fear that consensus will be misjudged.
> 
> *nod*
> 
> 
> I will take this opportunity to suggest two improvements for the
> consensus rules:
> 
> - establish reasonable time limits for objections to be raised before
>    one can conclude that consensus was reached, or, for expediency,
>    explicitly allow for (not too) late objections to be raised, in such a
>    way that the burden of overcoming objections is not reversed just
>    because there *appeared* to be consensus

This assumes commits to be some sort of strategic advantage, it is not. 
We are not a hostile community, as we demonstrated over the past years. 
The only reason this discussion is turning hostile is because (1) 
commits are being seen as some sort of strategic advantage and (2) there 
are repeated calls to authority in the absence of actual merit in the 
opposition.

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

Siddhesh