Re: removing toxic emailers

[Christopher Dimech <dimech@gmx.com>]

> Sent: Thursday, April 15, 2021 at 6:27 AM
> From: "Joseph Myers" <joseph@codesourcery.com>
> To: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: gcc@gcc.gnu.org, "Nathan Sidwell" <nathan@acm.org>
> Subject: Re: removing toxic emailers
>
> On Wed, 14 Apr 2021, Eric S. Raymond wrote:
>
> > I'm not judging RMS's behavior (or anyone else's) one way or
> > another. I am simply pointing out that there is a Schelling point in
> > possible community norms that is well expressed as "you shall judge by
> > the code alone".  This list is not full of contention from affirming
> > that norm, but from some peoples' attempt to repudiate it.
>
> Since RMS, FSF and GNU are not contributing code to the toolchain and
> haven't been for a very long time, the most similar basis to judge them
> would seem to be based on their interactions with toolchain development.
> I think those interactions generally show that FSF and GNU have been bad
> umbrella organizations for the toolchain since at least when the GCC 4.4
> release was delayed waiting for a slow process of developing the GCC
> Runtime Library Exception.
>
> Things have gone most smoothly when no actions or decisions from FSF or
> GNU have been required and when RMS has not attempted to make any
> decisions related to the toolchain.  When RMS has attempted to make any
> decisions, or suggest features, etc., that's generally served to waste a
> lot of time explaining to him why his ideas are irrelevant or based on a
> fundamental lack of understanding of the issues involved.  Even when he's
> made suggestions that are reasonable, he's still wasted a lot of people's
> time arguing about points that should not be controversial.
>
> (By way of example, on 20 Sep 2017 he suggested to the SC that GCC should
> support direct use of non-ASCII characters in identifiers.  I replied
> pointing him to the guidance I'd given in bug 67224 comments 11, 19 and
> 21.  So far, that's reasonable, but he then entered into prolonged
> discussion of the details of what particular patches did or didn't do,
> exactly what characters should or should not be allowed in identifiers,
> how GNU relates to standards, to what extent we need to design a feature
> properly before including it in GCC, and so on.  None of his comments
> there were at all useful, since he's far too far removed from current GCC
> development to comment usefully on such matters, and any useful comments
> in that area would have been better somewhere public anyway.  And in due
> course we did get a new GCC contributor who successfully implemented the
> feature in GCC following the guidance I'd given, despite RMS's notions
> that that would be too hard.)
>
> In things where the FSF and GNU have been supposed to be acting as
> umbrella organizations, that has generally been done badly (e.g. there
> have been problems with long delays in processing copyright assignments
> many times over the years; they never managed to come up with a simple
> GPL/GFDL dual-licensing notice so requiring instead the cumbersome system
> of having both GPL and GFDL copies of certain text in target.def and
> tm.texi).

Have suggested the need to work on the GFDL to make it compatible with
GPL-like licenses.

> For fairness, I should note the *unique case I know of in the past decade*
> where RMS was involved in a positive toolchain contribution.  On 11 Nov
> 2011 he started a discussion with me regarding the problems with glibc
> maintenance, and that ultimately started the transition to more
> community-oriented glibc development.  But ultimately the key parts of
> that transition were not the parts that actually involved RMS - it was
> discussions with Roland McGrath, not with RMS, that were key to achieving
> the transition successfully.
>
> New GNU maintainers of glibc, as recommended by me, were added on RMS's
> direction (maintainers revision 1.1352 on fencepost, 10 Feb 2012).  But
> the actual problems before then with glibc development weren't with the
> GNU maintainers (steering committee), beyond that they didn't do anything
> much to address the dysfunction in glibc development - it wasn't the GNU
> maintainers who were pushing away contributions.  And it was the
> deliberate work on building a community, getting people contributing,
> getting contributions committed (bootstrapping off Roland's authority to
> approve changes regardless of whether the then lead developer cared for
> them) that was actually the key part.  The announcements relating to
> changes
> <https://sourceware.org/pipermail/libc-alpha/2012-March/028224.html>
> <https://sourceware.org/pipermail/libc-alpha/2012-March/028226.html> were
> primarily concerned with a situation that already existed at that time,
> and that had been achieved by following a process that Roland had
> convinced me would be the right way to achieve changes, not with
> announcing anything done on the authority of RMS (which had happened over
> a month earlier without any public announcement).
>
> So in that case, while RMS started the discussion (or at least the part of
> the discussion I saw, I don't know what might have happened before 11 Nov
> 2011 involving other people), the useful changes could have been achieved
> by following the same plan with Roland but without RMS involved at all,
> whereas if only RMS's part had happened and there had been an attempt to
> change things only on the authority of RMS without actively building the
> community first, it would have been much less likely to succeed.  No GNU
> authority was ever needed to achieve the changes and the exercise of GNU
> authority that happened through appointing new maintainers was only
> legitimate because it was part of recognizing community changes that were
> in the process of occurring.

It looks like the debate revolves on the dislike of RMS, making any claims
about toxicity on the community null.

It all started with a tirade about commits and implementations to validate
worthiness, which was then used to forcefully advance the senseless assumption
of white male privilege.  There are few things more dishonorable than misleading
the young in the community.

> --
> Joseph S. Myers
> joseph@codesourcery.com
>