From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by sourceware.org (Postfix) with ESMTPS id 218EB3951C4F for ; Wed, 14 Apr 2021 20:02:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 218EB3951C4F X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [213.165.168.94] ([213.165.168.94]) by web-mail.gmx.net (3c-app-mailcom-bs03.server.lan [172.19.170.169]) (via HTTP); Wed, 14 Apr 2021 22:02:45 +0200 MIME-Version: 1.0 Message-ID: From: Christopher Dimech To: Joseph Myers Cc: "Eric S. Raymond" , gcc@gcc.gnu.org, Nathan Sidwell Subject: Re: removing toxic emailers Content-Type: text/plain; charset=UTF-8 Date: Wed, 14 Apr 2021 22:02:45 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: <20210414131843.GA4138043@thyrsus.com> <20210414142310.98E0833DD0@vlsi1.gnat.com> <20210414152112.GD4138043@thyrsus.com> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:1kOc9akEEIhTbFr9mLgmdwnVXu/2ST5f80PnuSTvHh+m3pcWZ49BBiBJZvrNFbOxPorIH Ke+fCQVmzRgpgJeWlIWfeL8Lsod6JFbYhQLjazzhi6+D6Q2bA/IxkIWvI7gkn27pmOAjnK+ZfZFC BoAP9kJinz+TrcTP3WC748qiM/0fep4FVeSBlbHMN7lRLg2EC22IRFTFy5XM1BE0vdYJ1pdhaaML //+oXxa3cmnFNk8+LETxNiTw2mX69Ixp2g7t80RRRSCuIygImVGPHxmU29E3+w3c40XQUW90nAnR jo= X-UI-Out-Filterresults: notjunk:1;V03:K0:EXw09yU9m98=:NtEoSzIiz0ULa/91rr7WxC 2bziq6uzi7huLMfmjRhY0FC7lSnlTa2IBzL+QeWm02PVyWx+6v4XfDl9TUcf6Wzf0l020MM3Q DzsNP3i+RPTT2dg+lEbrk/jSrS1bhUMAOkDWAFKjHBxWyXyXgM/Upx6EIN/fym8wjulBqNWrY MCVr6/nc6q2lkPQKX7hNSysfn7GjqZIDbZlj0lpgk25pmKzqCZWgo2uLzg8+EmqbHj0t7JzAm dk6HGM2HsP5YfGpxHMS631hPqwFJ6IgDZXQgYKZwJjAImSnOIYbfXPg8PiZ7jcTI2SRccKh1L YZdcXosj5Vs9DxAGxFDUg/844w8MdfseyPzpac4wF2gIvzQvBj29k/nOV4ikEFjFageb7vZKK jzi3fp51x2qTd4vFdFVzkQR/iFXt6WWjSiZZGhZeilpToS8lWxZXiD0DrsCTiMymTEeXsNhbH R6pC6UtIMO69CBG9lSTTWTVK5O5L30nL92PAtnZpMsn9BXbvUBZRoiZApfqTHcPfwnBzOWmAM 7LeiwAn7J0JJJtcmhNu3DkGNqj0+cJ2I5jy29OsFbT/aGs8QFRZqfrnWvqN2cSlxC9nNhqsKo 8oRzx5eqnt5VrMeKCNWaFrkTQU+WKlE1PIObK5TXoIq4gfE8UYqOCalW0dRE8OaPdk6RVUYVU 51Bffdd1zUEyYTCa7h5AKsPJYS/u+KXnJ0NSRPkxp+TtSpGeS/ZZprnECmq3Hy1lQotT27SsK T32kz61Y0nGNWSgeV5CIXsLj8t6XewM47wsi6LEAHlbC91yqNzTL3VZ8QS425h8dWQ89Tzrv1 Wh8dcIQ5iYyp1WEv4Xc/jDdWf2IjYKvhzUvhbmmD3dAk/IJymAj9AqwggBWKzZtDF5BxffeNM rNFQg+JuNp7akMoqL6QfLcv1B1JCQvUcxGKKEqxh3DtoCvGBGSlb09AVfbBD2Z Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3032.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 20:02:58 -0000 > Sent: Thursday, April 15, 2021 at 6:27 AM > From: "Joseph Myers" > To: "Eric S. Raymond" > Cc: gcc@gcc.gnu.org, "Nathan Sidwell" > 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 shoul= d > 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 GC= C > 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 syste= m > 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 decad= e* > 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 achievin= g > 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 anythin= g > 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 > > wer= e > 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 ove= r > 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 No= v > 2011 involving other people), the useful changes could have been achieve= d > 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 wer= e > 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 assump= tion of white male privilege. There are few things more dishonorable than misl= eading the young in the community. > -- > Joseph S. Myers > joseph@codesourcery.com >