Re: removing toxic emailers
On Thu, 15 Apr 2021 at 02:18, Christopher Dimech wrote: > What are we? Adults or Children? You know, as I know, that identities > can be made up. There are many computing specialists who can do that. > They can even be made so it looks as though they were sent by you, or > from your work and home address. They could even be made up to look as > though your children sent them. > > I remember a closing comment by Eben Moglen during a full-day program at > Columbia Law School in 2016. And I agree with him. > > So my point here — if it’s okay just to have a point when people should > already be drinking and dancing — my point is let’s not get confused. This is > not war time. This is diplomacy time. Skill counts. Agility counts. > Discretion counts. Long credibility counts. Ammunition? Ammunition is > worthless because wherever we fire it, we work everywhere and it’s only going > to hit us. - Eben Moglen Interesting choice of quote from the guy who made the very first reply to the whole thing with "What is this? The usual rant of freaked out madness!!!" https://gcc.gnu.org/pipermail/gcc/2021-March/235092.html and followed soon after with "More rats for the wood pile. " https://gcc.gnu.org/pipermail/gcc/2021-March/235109.html But now you're lecturing us about diplomacy. Fuck off, Christopher. Just fuck off. You've added nothing of value to this entire discussion, just riled people up and stirred up trouble. Fuck off.
Re: removing toxic emailers
> On Apr 14, 2021, at 5:10 PM, Christopher Dimech wrote: > What are we? Adults or Children? You know, as I know, that identities > can be made up. There are many computing specialists who can do that. > They can even be made so it looks as though they were sent by you, or > from your work and home address. They could even be made up to look as > though your children sent them. That’s far out man, like outer space far out. It’s fortunate, though, that despite this confusing world of tricksters you find yourself in, you have maintained the kind of confidence and composure required to put in thisn insincere kind of low-effort trolling to defend your principals, in a serious discussion that were it to go the wrong way, could well potentially also require you to take responsibility for your behavior in public. > So my point here — if it’s okay just to have a point when people should > already be drinking and dancing — my point is let’s not get confused. Do you imagine people may one day solemnly read through these archives here, shaking their heads at how Mr. Stallman was treated, how mean and irrational it all was, even as even you tried your best to outwit the members into doing the right thing… Just as people do when reading Socrates' Apology, or Tacitus talking about the suffering under emperors? That would be sad because the annals of the mailing list will be available verbatim, probably Literally forever, so obviously that can’t happen. Aaron
Re: removing toxic emailers
Joseph Myers : > 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. I do not have standing to argue this point. I will, however, point out that it is a very *different* point from "RMS has iupset some people and should therefore be canceled". -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: removing toxic emailers
Paul Koning via Gcc : > > On Apr 14, 2021, at 4:39 PM, Ian Lance Taylor via Gcc > > wrote: > > So we don't get the choice between "everyone is welcome" and "some > > people are kicked off the list." We get the choice between "some > > people decline to participate because it is unpleasant" and "some > > people are kicked off the list." > > > > Given the choice of which group of people are going to participate and > > which group are not, which group do we want? > > My answer is "it depends". More precisely, in the past I would have > favored those who decline because the environment is unpleasant -- > with the implied assumption being that their objections are > reasonable. Given the emergency of cancel culture, that assumption > is no longer automatically valid. I concur on both counts. You (the GCC project) are no longer in a situation where any random person saying "your environment is hostile" is a reliable signal of a real problem. Safetyism is being gamed by outsiders for purposes that are not yours and have nothing to do with shipping good code. Complaints need to be discounted accordingly, to a degree that would not have been required before the development of a self-reinforcing culture of complaint and rage-mobbing around 2014. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: removing toxic emailers
> Sent: Thursday, April 15, 2021 at 9:18 PM > From: "Jonathan Wakely" > To: "Christopher Dimech" > Cc: "Nathan Sidwell" , "gcc@gcc.gnu.org" > Subject: Re: removing toxic emailers > > On Thu, 15 Apr 2021 at 02:18, Christopher Dimech wrote: > > What are we? Adults or Children? You know, as I know, that identities > > can be made up. There are many computing specialists who can do that. > > They can even be made so it looks as though they were sent by you, or > > from your work and home address. They could even be made up to look as > > though your children sent them. > > > > I remember a closing comment by Eben Moglen during a full-day program at > > Columbia Law School in 2016. And I agree with him. > > > > So my point here — if it’s okay just to have a point when people should > > already be drinking and dancing — my point is let’s not get confused. This > > is not war time. This is diplomacy time. Skill counts. Agility counts. > > Discretion counts. Long credibility counts. Ammunition? Ammunition is > > worthless because wherever we fire it, we work everywhere and it’s only > > going to hit us. - Eben Moglen > > Interesting choice of quote from the guy who made the very first reply > to the whole thing with "What is this? The usual rant of freaked out > madness!!!" > https://gcc.gnu.org/pipermail/gcc/2021-March/235092.html Yes, I am that individual who was quoted saying that on the international press. Don't you have something bad to say about Eben Moglen too. He is proud of what anarchism achieved, a path that is certainly at odds with Nathan's arguments. > and followed soon after with "More rats for the wood pile. " > https://gcc.gnu.org/pipermail/gcc/2021-March/235109.html Correct. He brought it upon himself. > But now you're lecturing us about diplomacy. Something you and Nathan are incapable of. I'd just like to eject the jerks... And yes, I fully realize there are other ways I can choose to not associate with them here. - Nathan > Fuck off, Christopher. Just fuck off. You've added nothing of value to > this entire discussion, just riled people up and stirred up trouble. > Fuck off. That is a dream, because you have to be asleep to believe it.
Re: removing toxic emailers
> Sent: Thursday, April 15, 2021 at 10:20 PM > From: "Aaron Gyes" > To: gcc@gcc.gnu.org > Cc: dim...@gmx.com > Subject: Re: removing toxic emailers > > > On Apr 14, 2021, at 5:10 PM, Christopher Dimech wrote: > > > What are we? Adults or Children? You know, as I know, that identities > > can be made up. There are many computing specialists who can do that. > > They can even be made so it looks as though they were sent by you, or > > from your work and home address. They could even be made up to look as > > though your children sent them. > > That’s far out man, like outer space far out. It’s fortunate, though, that > despite this confusing world of tricksters you find yourself in, you have > maintained the kind of confidence and composure required to put in thisn > insincere > kind of low-effort trolling to defend your principals, in a serious discussion > that were it to go the wrong way, could well potentially also require you to > take > responsibility for your behavior in public. I can easily write articles in the international press and take interviews. > > So my point here — if it’s okay just to have a point when people should > > already be drinking and dancing — my point is let’s not get confused. > > > Do you imagine people may one day solemnly read through these archives here, > shaking > their heads at how Mr. Stallman was treated, how mean and irrational it all > was, even as > even you tried your best to outwit the members into doing the right thing… > Just as people do > when reading Socrates' Apology, or Tacitus talking about the suffering under > emperors? > > That would be sad because the annals of the mailing list will be available > verbatim, probably > Literally forever, so obviously that can’t happen. Do you plan to start quoting me? Thank you. > Aaron
Re: removing toxic emailers
Adrian via Gcc : > Eric S. Raymond : > > there is actually a value conflict between being "welcoming" in that > sense and the actual purpose of this list, which is to ship code. > > Speaking as a "high functioning autist", I'm aware of the difficulties that > some of us have with social interactions - and also that many of us > construct a persona or multiple personae to interact with others, a > phenomenon known as "masking". > > I understand why "Asshole" can function as a viable mask for many people, > because there are cultures where it's tolerated, particularly in > remote-working groups like mailing lists, where physical altercations are > unlikely and no-one has to confront the results of their interactions with > others if they don't want to. > > It doesn't necessarily follow that "smart" == "asshole" though. I did not intend that claim. I intended the weaker observation that driving away a large number of smart autistic assholes (and non-assholes with poor social skills) is not necessarily a good trade for the people the project might recruit by being "more welcoming". Possibly that *would* be a good trade. I have decades of experience that makes me doubt this. I think the claim needs to be examined skeptically, not just uncritically accepted because we value being "nice". In general, I think efforts to guilt-bomb hackers into being "more inclusive" should be resisted without a clear grasp on what we might be throwing away by accepting them. Just because you live inside a culture doesn't mean you can predict what mutating its assumptions will do to it, and we have work to do that should not be casually disrupted. Note: I am not an autist myself, so I'm not guarding my own flanks here. I'm sort of autist-sympathetic, in that I think it is a good thing autists can join the hacker culture and have a place where their quirks are useful and tolerated. I would be a little sad if that were lost. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: removing toxic emailers
Eric S. Raymond wrote: Paul Koning via Gcc : On Apr 14, 2021, at 4:39 PM, Ian Lance Taylor via Gcc wrote: So we don't get the choice between "everyone is welcome" and "some people are kicked off the list." We get the choice between "some people decline to participate because it is unpleasant" and "some people are kicked off the list." Given the choice of which group of people are going to participate and which group are not, which group do we want? My answer is "it depends". More precisely, in the past I would have favored those who decline because the environment is unpleasant -- with the implied assumption being that their objections are reasonable. Given the emergency of cancel culture, that assumption is no longer automatically valid. I concur on both counts. You (the GCC project) are no longer in a situation where any random person saying "your environment is hostile" is a reliable signal of a real problem. Safetyism is being gamed by outsiders for purposes that are not yours and have nothing to do with shipping good code. Complaints need to be discounted accordingly, to a degree that would not have been required before the development of a self-reinforcing culture of complaint and rage-mobbing around 2014. responding to Ian’s original statement: I am one of the people who would not be “here” if the environment was hostile. That is not a theoretical statement - I declined to contribute to one project already because of the hostility of the interactions. Although I love to be paid to work on GCC, the truth is that almost all my contributions are voluntary and I would not choose to spend my spare time in a conflicted environment, period. For those of us who are ‘freelance’ these lists and the IRC channel are pretty much our workplace, it needs to be civilised (for me anyway). responding in general to this part of the thread. * The GCC environment is not hostile, and has not been for the 15 or so years I’ve been part of the community. * We would notice if it became so, I’m not sure about the idea that the wool can be so easily pulled over our eyes. I confess to being concerned with the equation “code” > “conduct”; it is not so in my professional or personal experience. I have seen an engineering team suffer great losses of performance from the excesses of one (near genius, but very antisocial) member - the balance was not met. Likewise, it has been seen to be a poor balance when there are three gifted individuals in a household but one persecutes the other two (for diagnosed reaons).. again balance is not met One could see the equation becoming a self-fullfilling prophecy viz. * let us say compilers are complex, and any significant input over length of time will require a resonably competent engineer. * reasonably competent engineers with a good social habit are welcome everywhere * reasonably competent engineers with poor social habit are welcome in few places. - those few places will easily be able to demonstrate that their progress is made despite the poor atmosphere, with no way to know that something better was possible. responding to the thread in general.. * Please could we try to seek concensus? - it is disappointing to see people treating this as some kind of point-scoring game when to those working on the compiler day to day it is far from a game. Iain
Re: removing toxic emailers
> On Apr 15, 2021, at 11:17 AM, Iain Sandoe wrote: > > ... > responding in general to this part of the thread. > > * The GCC environment is not hostile, and has not been for the 15 or so > years I’ve been part of the community. Glad to see you feel that way; my view matches yours. > * We would notice if it became so, I’m not sure about the idea that the wool > can be so easily pulled over our eyes. > > I confess to being concerned with the equation “code” > “conduct”; it is not > so in my professional or personal experience. I have seen an engineering > team suffer great losses of performance from the excesses of one (near genius, > but very antisocial) member - the balance was not met. Likewise, it has been > seen to be a poor balance when there are three gifted individuals in a > household > but one persecutes the other two (for diagnosed reaons).. again balance is not > met > > One could see the equation becoming a self-fullfilling prophecy viz. > > * let us say compilers are complex, and any significant input over length > of time > will require a resonably competent engineer. > > * reasonably competent engineers with a good social habit are welcome > everywhere > > * reasonably competent engineers with poor social habit are welcome in few > places. All true. > - those few places will easily be able to demonstrate that their progress is > made > despite the poor atmosphere, with no way to know that something better was > possible. > > responding to the thread in general.. > > * Please could we try to seek concensus? > > - it is disappointing to see people treating this as some kind of > point-scoring game > when to those working on the compiler day to day it is far from a game. I'm not sure what the consensus is you're looking for. Consensus on the principle that people should behave in a civil fashion? Yes, I agree with that. The difficulty, as I mentioned, is in deciding in concrete situations whether that principle was violated and what should be done about it. So I think the easy part is the principle; the hard part is the process that will enforce the principle in those cases where it needs to be -- and ONLY in those cases. Again, if the question had come up 10 years ago I wouldn't be so worried; but in 2021 after years of watching people being blacklisted for daring to speak the wrong politics of the day, I can no longer do so. paul
Re: GCC association with the FSF
On Wed, Apr 14, 2021 at 8:08 AM Richard Biener via Gcc wrote: > On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc > wrote: > >N.B. Jeff is no longer @redhat.com so I've changed the CC > >On Wed, 14 Apr 2021 at 11:03, Thomas Koenig > >wrote: > >> - All gfortran developers move to the new branch. This will not > >>happen, I can guarantee you that. > > > >This is the part I'm curious about (the rest is obvious, it follows > >from there being finite resources and the nature of any fork). But I'm > >not going to press for reasons. > > Note the only viable fork will be on the current hosting (which isn't FSF > controlled) with the downside of eventually losing the gcc.gnu.org DNS and > thus a need to "switch" to a sourceware.org name. It seems wrong to call such a scenario a fork. If someone wanted to fork GCC they are free to do so, but changing the relationship with GNU/FSF is not a fork, as there would continue to be one primary source repository. Jason
Re: removing toxic emailers
On 4/15/21 8:00 AM, Thomas Koenig via Gcc wrote:
My 0.02 Euro-Cent:
There is a minor problem with contributors being overly harsh/
borderline abusive on the mailing list. In my > 15 years with
the project, I have only had that problem with one single
person, and I have resolved that by never again touching the
system that particular person is responsible for, also not
for testing.
The _real_ problem is in bugzilla, mostly with abusive users
complaining about the time it sometimes takes to fix bugs
("Why didn't you fix this? Are you stupid or what? That bug
has been open for _weeks_!") or who will not understand that
their program has an error, and insist on the compiler sanctioning
their particular non-standard usage.
As much as I hate to say it, this is a problem in the wider communities
around C and C++, too. My teacher will often insist that "GCC and Clang
make convenient assumptions at O2 and higher" without comprehending that
the assumptions are "your code conforms to what the C/C++ standard says"
and that this is the entire reason we have a standard, despite all my
efforts at explaining things to him.
On bugzilla, there is also a rather minor problem with contributors
being overly harsh/borderline abusive, but that is also quite
restrictive.
If we talk about gcc becoming a more welcoming place, bugzilla
is the place to start.
Re: GCC association with the FSF
On April 15, 2021 6:02:50 PM GMT+02:00, Jason Merrill wrote: >On Wed, Apr 14, 2021 at 8:08 AM Richard Biener via Gcc > wrote: >> On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc > wrote: >> >N.B. Jeff is no longer @redhat.com so I've changed the CC >> >On Wed, 14 Apr 2021 at 11:03, Thomas Koenig >> >wrote: >> >> - All gfortran developers move to the new branch. This will not >> >>happen, I can guarantee you that. >> > >> >This is the part I'm curious about (the rest is obvious, it follows >> >from there being finite resources and the nature of any fork). But >I'm >> >not going to press for reasons. >> >> Note the only viable fork will be on the current hosting (which isn't >FSF controlled) with the downside of eventually losing the gcc.gnu.org >DNS and thus a need to "switch" to a sourceware.org name. > >It seems wrong to call such a scenario a fork. If someone wanted to >fork GCC they are free to do so, but changing the relationship with >GNU/FSF is not a fork, as there would continue to be one primary >source repository. True. That's definitely better communication. Richard. >Jason
Re: removing toxic emailers
On Thu, 2021-04-15 at 09:49 -0400, Eric S. Raymond wrote: > Joseph Myers : > > 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. > > I do not have standing to argue this point. > > I will, however, point out that it is a very *different* point from > "RMS has iupset some people and should therefore be canceled". [I'm sorry to everyone who's sick of these threads, but I feel I have to respond to this one; sorry about writing another long email] Eric: I don't know if you're just being glib, or you're deliberately trying to caricature those of us who are upset by RMS's behavior. I think the words "canceled" and "cancel culture" have effectively become meaningless and should be avoided if we want to have a nuanced discussion - no-one seems to have a definition of what counts as "canceling" vs "consequences" vs "fair and measured responses". At one time, both you and RMS were heroes of mine, and I was a true believer (of what, I'm no longer sure); I own copies of both "The Cathedral and the Bazaar" and "Free Software - Free Society", though both are currently in my attic, gathering dust. I've long felt that there was a massive hole in the GNU project and FSF where effective technical leadership should have been - various maintainers on gcc, gdb, etc have been implementing things, and things were humming along, and those of us in Red Hat working on them tried to coordinate on features we felt were important - but where was the top- level response to, say, LLVM/clang? (to name just one of many changes in the industry) In many ways the last 8 years of my career have been an attempt to get gcc to respond to the appearance of LLVM/clang (I've added JIT-compilation, improved diagnostics, and I'm implementing a static analysis pass) - I'm lucky that my managers inside Red Hat are happy to pay me to hack on this stuff and make GCC better - it helps our customers, but it also helps GCC, and the broader FLOSS communities using both toolchains). Where has the technical leadership from RMS been? Instead the long- standing opposition by RMS to exposing the compiler's IR has hobbled GCC, and partly contributed to the pile of technical debt we have to dig our way out of. The only "leadership" coming out of GNU/FSF seem to me to be dictats from on high about ChangeLog formats and coding conventions. The GNU project seems to me to be stuck in the 1980s. Perhaps a pronouncement like: "try to make everything be consumable as libraries with APIs, as well as as standalone binaries" might have helped (and still could; can we do that please?) Similarly, I agree with Joseph's observations of the ways that the FSF and GNU have been bad umbrella organizations for the toolchain. But beyond the failure of technical leadership, and the organizational incompetence/incoherence, is RMS's behavior, and the extent to which it, as you put it "upset some people". RMS's defenders seem to have fixated on his 2019 comments on Marvin Minsky, the uproar over those, and his responses to them (then and recently), and seem keen to assure us that everything's OK now, or, at least on a road to improvement. But in the time since those 2019 comments, I've been reconsidering my views on RMS. In particular, I have read of many alleged incidents such as: - spontaneously licking a female conference member on the arm - appearing to hit on anyone female, even if they're underage - asking which female audience members at his talk were virgins At least one of the above was from a former colleage of mine, which when I read it was about the point that broke me. As part of my reconsidering my views on RMS, I recalled an event described in Sam Williams' biography of RMS in which Williams describes RMS's then girlfriend talking about how she "admired the way Richard built up an entire political movement to address an issue of profound personal concern", which she identified as "crushing loneliness". When I first read that, years ago, I felt sorry and pity for RMS, and a vague feeling that community is an important part of FLOSS, or somesuch sentiment (and a feeling of trying t
Re: GCC association with the FSF
> Sent: Friday, April 16, 2021 at 4:24 AM > From: "Richard Biener via Gcc" > To: "Jason Merrill" > Cc: "Thomas Koenig" , "gcc mailing list" > > Subject: Re: GCC association with the FSF > > On April 15, 2021 6:02:50 PM GMT+02:00, Jason Merrill > wrote: > >On Wed, Apr 14, 2021 at 8:08 AM Richard Biener via Gcc > > wrote: > >> On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc > > wrote: > >> >N.B. Jeff is no longer @redhat.com so I've changed the CC > >> >On Wed, 14 Apr 2021 at 11:03, Thomas Koenig > >> >wrote: > >> >> - All gfortran developers move to the new branch. This will not > >> >>happen, I can guarantee you that. > >> > > >> >This is the part I'm curious about (the rest is obvious, it follows > >> >from there being finite resources and the nature of any fork). But > >I'm > >> >not going to press for reasons. > >> > >> Note the only viable fork will be on the current hosting (which isn't > >FSF controlled) with the downside of eventually losing the gcc.gnu.org > >DNS and thus a need to "switch" to a sourceware.org name. > > > >It seems wrong to call such a scenario a fork. If someone wanted to > >fork GCC they are free to do so, but changing the relationship with > >GNU/FSF is not a fork, as there would continue to be one primary > >source repository. Correct, but whatever happens, the association with RMS will remain. Thusly the impasse is not going away. A fork would work, but then the secessionists' intention is to carry on with the Gcc tag, because of its respected position in the world of science and technology. > True. That's definitely better communication. > > Richard. > > >Jason > >
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 10:31 AM David Malcolm via Gcc wrote: > > I still admire much of what RMS has written, and have spent much of my > career trying to implement part of a vision inspired by him. I'm sad > about the way things have turned out. Twitter seems to turn everything > into a pitched battle between two camps. I hope there's room for a > nuanced view of him - the good and the less good. I don't know what > role he should have, but I think it should not be a leadership one, and > I think the FSF and GNU need to greatly change to stay relevant, > including on governance and on succession plans. None of us are > getting any younger, and the vision of the FSF and GNU seems to me to > be stuck in the 1990s (or earlier). Thanks, that is well put. That describes my own feelings as well. To be very blunt, I don't know how to read https://www.fsf.org/news/rms-addresses-the-free-software-community and think "the person who wrote this should be in a leadership role." I don't think RMS is a bad person. I think that RMS can still have a great deal to contribute to free software as a programmer and as a philosopher. But those are not the words of a leader. Leadership is about people: understanding what people need, understanding how to motivate them toward a shared goal. What I see in that essay is somebody who doesn't understand people very well, and is not all that interested in learning. Ian
Re: removing toxic emailers
Paul Koning wrote: On Apr 15, 2021, at 11:17 AM, Iain Sandoe wrote: ... responding in general to this part of the thread. * The GCC environment is not hostile, and has not been for the 15 or so years I’ve been part of the community. * We would notice if it became so, I’m not sure about the idea that the wool can be so easily pulled over our eyes. responding to the thread in general.. * Please could we try to seek consensus? - it is disappointing to see people treating this as some kind of point-scoring game when to those working on the compiler day to day it is far from a game. I'm not sure what the consensus is you're looking for. Let us start from the observations above and try to add in the issues that have arisen in the recent threads - and end with a proposal * One could be glib and suggest that discussions about governance and project process should be directed to a different (new) mailing list - but that does not solve the problem(s) it just moves them. - (however, it might still be valuable to folks who wish to have an automatic filter for these topics or have no interest in them). * I think we are all clear about the primary role of the gcc@ and gcc-patches@ lists - primarily technical discussion about current and future projects and patch review respectively. - we have a history of politely redirecting usage questions to the help list (while often answering them anyway), likewise with the irc channel. - I believe we also have a history of encouraging input and discussing the technical issues (reasonably) calmly. - to the best of my recollection I have never seen an idea excluded on any basis than technical content. * Without a specific list to process input on governance and project process, this list is a reasonable choice. ——— The observations above, copied from my first email, together with a belief that most of the current and potential contributor to GCC would prefer to function in a constructive environment, lead to the following proposition: * that, since the lists are generally constructive without additional management, (OK. there are occasional heated technical debates), it implies that this community by-and-large is already able to function without heavy-handed moderation. * It has been postulated that there could be valued technical input from people who have difficulty in interacting in a constructive manner (through no fault of their own). * no-one else would be making valued input, either they would be a spammer or intentionally acting in a destructive manner. - Let us propose that someone capable of working on a complex system such as a compiler would be able to read and act on a set of guidelines. - ergo, I propose that we have a set of guidelines to which someone who is being disruptive can be pointed. * (Probably?) no-one has any issue with a spammer being thrown off the list, for which I guess there is a process already - it would be reasonable to expect that genuine contributors (even with difficulties) would make an effort to follow guidelines - and that someone who was making no effort to do so is not really any different from a spammer. Of course, guidelines require debate (but I doubt that the right set would be much different from the obvious for this group). is seems to me that most of the strife in the last two weeks comes from a few key things: - attacking the person delivering a message rather than debating the message - introducing topics spurious and unrelated to the actual debate - trying to equate the process of this project with party or international Politics. === So .. in summary: 1/ I propose that we do have written guidelines, to which someone behaving in a non-constructive manner can be pointed. 2/ if those guidelines *are the consensus* of this group and someone is unable to follow them (given some reasonable chance to amend as is customary in matters such as employment law here, at least), then they are treated no differently from any other spam. * although one might lose some notionally valuable input, the judgement here is that the net benefit of such input is negative. 3/ I would recommend on the basis of another online community (about music) to which I belong, to suggest that Politics (party or international) and Religion are better discussed in other forums and are exceedingly unlikely to affect a technical decision on the progress of GCC - such discussions almost never end well. (I’d believe that any valid exception to the need to heed some political situation would be readily recognised by the participants here). 4/ It is likely that we can extract much of the basic guidelines from any other writing on communicating constructively - after all, it is how 99.99% of this list traffic is managed without intervention
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 5:31 AM > From: "David Malcolm via Gcc" > To: e...@thyrsus.com, "Joseph Myers" > Cc: gcc@gcc.gnu.org, "Nathan Sidwell" > Subject: Re: removing toxic emailers > > On Thu, 2021-04-15 at 09:49 -0400, Eric S. Raymond wrote: > > Joseph Myers : > > > 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. > > > > I do not have standing to argue this point. > > > > I will, however, point out that it is a very *different* point from > > "RMS has iupset some people and should therefore be canceled". > > [I'm sorry to everyone who's sick of these threads, but I feel I have > to respond to this one; sorry about writing another long email] > > Eric: I don't know if you're just being glib, or you're deliberately > trying to caricature those of us who are upset by RMS's behavior. > > I think the words "canceled" and "cancel culture" have effectively > become meaningless and should be avoided if we want to have a nuanced > discussion - no-one seems to have a definition of what counts as > "canceling" vs "consequences" vs "fair and measured responses". > > At one time, both you and RMS were heroes of mine, and I was a true > believer (of what, I'm no longer sure); I own copies of both "The > Cathedral and the Bazaar" and "Free Software - Free Society", though > both are currently in my attic, gathering dust. > > I've long felt that there was a massive hole in the GNU project and FSF > where effective technical leadership should have been - various > maintainers on gcc, gdb, etc have been implementing things, and things > were humming along, and those of us in Red Hat working on them tried to > coordinate on features we felt were important - but where was the top- > level response to, say, LLVM/clang? (to name just one of many changes > in the industry) In many ways the last 8 years of my career have been > an attempt to get gcc to respond to the appearance of LLVM/clang (I've > added JIT-compilation, improved diagnostics, and I'm implementing a > static analysis pass) I don't see a problem with improvements in appearance when valuable and useful. It is not easy to work with as it could be. One can also complain about what's missing in LLVM. I am however not a proponent of C++, and closely relate to Eric's comment about the unfortunate decline of C. Have worked on C++ myself in the oil, gas and mining industry, and in other things like underwater acoustics. Where the difficulties of working with object oriented programming made working with some kinds of algorithms impossible to track adequately. > - I'm lucky that my managers inside Red Hat are > happy to pay me to hack on this stuff and make GCC better - it helps > our customers, but it also helps GCC, and the broader FLOSS communities > using both toolchains). > > Where has the technical leadership from RMS been? Instead the long- > standing opposition by RMS to exposing the compiler's IR has hobbled > GCC, and partly contributed to the pile of technical debt we have to > dig our way out of. The only "leadership" coming out of GNU/FSF seem > to me to be dictats from on high about ChangeLog formats and coding > conventions. The GNU project seems to me to be stuck in the 1980s. > Perhaps a pronouncement like: "try to make everything be consumable as > libraries with APIs, as well as as standalone binaries" might have > helped (and still could; can we do that please?) > > Similarly, I agree with Joseph's observations of the ways that the FSF > and GNU have been bad umbrella organizations for the toolchain. > > But beyond the failure of technical leadership, and the organizational > incompetence/incoherence, is RMS's behavior, and the extent to which > it, as you put it "upset some people". > > RMS's defenders seem to have fixated on his 2019 comments on Marvin > Minsky, the uproar over those, and his responses to them (then and > recently), and seem keen to assure us that everything's OK now, or, at > least on a road to improvement. I have seen much discussion and arguments emanating from that. Includin
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 7:21 AM > From: "Iain Sandoe" > To: "GCC Development" > Subject: Re: removing toxic emailers > > Paul Koning wrote: > >> On Apr 15, 2021, at 11:17 AM, Iain Sandoe wrote: > >> > >> ... > >> responding in general to this part of the thread. > >> > >> * The GCC environment is not hostile, and has not been for the 15 or so > >> years I’ve been part of the community. > > >> * We would notice if it became so, I’m not sure about the idea that the > >> wool > >> can be so easily pulled over our eyes. > >> > > >> responding to the thread in general.. > >> > >> * Please could we try to seek consensus? > >> > >> - it is disappointing to see people treating this as some kind of > >> point-scoring game > >> when to those working on the compiler day to day it is far from a game. > > > > I'm not sure what the consensus is you're looking for. > > Let us start from the observations above and try to add in the issues that > have > arisen in the recent threads - and end with a proposal > > * One could be glib and suggest that discussions about governance and project >process should be directed to a different (new) mailing list > >- but that does not solve the problem(s) it just moves them. >- (however, it might still be valuable to folks who wish to have an > automatic filter > for these topics or have no interest in them). > > * I think we are all clear about the primary role of the gcc@ and > gcc-patches@ lists > >- primarily technical discussion about current and future projects and > patch review > respectively. > >- we have a history of politely redirecting usage questions to the help > list (while > often answering them anyway), likewise with the irc channel. > >- I believe we also have a history of encouraging input and discussing the > technical > issues (reasonably) calmly. > >- to the best of my recollection I have never seen an idea excluded on any > basis than > technical content. > > * Without a specific list to process input on governance and project > process, this >list is a reasonable choice. > > ——— > > The observations above, copied from my first email, together with a belief > that most of > the current and potential contributor to GCC would prefer to function in a > constructive > environment, lead to the following proposition: > >* that, since the lists are generally constructive without additional > management, > (OK. there are occasional heated technical debates), it implies that > this community > by-and-large is already able to function without heavy-handed moderation. > > * It has been postulated that there could be valued technical input from > people who > have difficulty in interacting in a constructive manner (through no fault > of their own). > > * no-one else would be making valued input, either they would be a spammer > or > intentionally acting in a destructive manner. > > - Let us propose that someone capable of working on a complex system such > as a > compiler would be able to read and act on a set of guidelines. > > - ergo, I propose that we have a set of guidelines to which someone who > is being > disruptive can be pointed. > >* (Probably?) no-one has any issue with a spammer being thrown off the > list, for which > I guess there is a process already - it would be reasonable to expect > that genuine > contributors (even with difficulties) would make an effort to follow > guidelines - and > that someone who was making no effort to do so is not really any > different from a > spammer. > > Of course, guidelines require debate (but I doubt that the right set would > be much > different from the obvious for this group). > > is seems to me that most of the strife in the last two weeks comes from a > few key > things: > >- attacking the person delivering a message rather than debating the > message >- introducing topics spurious and unrelated to the actual debate >- trying to equate the process of this project with party or international > Politics. > > === > > So .. in summary: > > 1/ I propose that we do have written guidelines, to which someone behaving > in a > non-constructive manner can be pointed. > > 2/ if those guidelines *are the consensus* of this group and someone is > unable to > follow them (given some reasonable chance to amend as is customary in > matters > such as employment law here, at least), then they are treated no > differently from > any other spam. Proposing the guidelines essentially means that the community accepts the fact that many of us are incapable of navigate everyday problems and dilemmas by making “right” decisions based on the use of good judgment and values rather than sterile sets of rules and conventions that typically disregard the individual, the particular, or the discrete. Thusl
Gcc as callable libraries (was: removing toxic emailers)
David, for some reason or other, I did not get your mail, so I will just reply copying in from the archive. First, thanks for injecting some sanity into the discussion. I will not discuss RMS' personal shortcomings or the lack of them. In today's toxic political climate, such allegations are often made up and weaponized without an effective defense for the alleged wrongdoer. I don't know the truth of the matter, and I make a point of not finding out. > In many ways the last 8 years of my career have been > an attempt to get gcc to respond to the appearance of LLVM/clang (I've > added JIT-compilation, improved diagnostics, and I'm implementing a > static analysis pass) And this is highly welcome, and has made gcc (including gfortran) a much better compiler. I well remember how you implemented the much better colored error messages that gfortran has now. > Perhaps a pronouncement like: "try to make everything be consumable as > libraries with APIs, as well as as standalone binaries" might have > helped (and still could; can we do that please?) That makes perfect sense, as LLVM shows, and is something that the steering committee could decide for the project (or rather, it could issue a pronouncement that this will not be opposed if some volunteer does it). I think this could be as close to an unanimous decision as there can be among such a diverse community as the gcc developers. If the FSF takes umbrage at this, the ball is in their court.
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 12:45 PM Christopher Dimech via Gcc wrote: > > Proposing the guidelines essentially means that the community accepts the fact > that many of us are incapable of navigate everyday problems and dilemmas by > making > “right” decisions based on the use of good judgment and values rather than > sterile > sets of rules and conventions that typically disregard the individual, the > particular, > or the discrete. Thusly, it is wrong to suggest that the problems are simply > associated with RMS, FSF and GNU. I think you are conflating two different things. Iain was describing general guidelines for communication, not saying anything about RMS, FSF, or GNU. Personally I would say that the purpose of communication guidelines for GCC mailing lists is not for existing members of the community. As several people have said, the GCC mailing lists are normally civil. It is to provide a mechanism for blocking people whose goal is, for whatever reason, to disrupt the community. Such a mechanism requires a lot of sensitivity to context and care on the part of the moderators. But it still helps to have a set of guidelines to refer to. Ian
Re: removing toxic emailers
Christopher Dimech wrote: Sent: Friday, April 16, 2021 at 7:21 AM From: "Iain Sandoe" To: "GCC Development" Subject: Re: removing toxic emailers Paul Koning wrote: On Apr 15, 2021, at 11:17 AM, Iain Sandoe wrote: ... responding in general to this part of the thread. * The GCC environment is not hostile, and has not been for the 15 or so years I’ve been part of the community. * We would notice if it became so, I’m not sure about the idea that the wool can be so easily pulled over our eyes. responding to the thread in general.. * Please could we try to seek consensus? - it is disappointing to see people treating this as some kind of point-scoring game when to those working on the compiler day to day it is far from a game. I'm not sure what the consensus is you're looking for. Let us start from the observations above and try to add in the issues that have arisen in the recent threads - and end with a proposal * One could be glib and suggest that discussions about governance and project process should be directed to a different (new) mailing list - but that does not solve the problem(s) it just moves them. - (however, it might still be valuable to folks who wish to have an automatic filter for these topics or have no interest in them). * I think we are all clear about the primary role of the gcc@ and gcc-patches@ lists - primarily technical discussion about current and future projects and patch review respectively. - we have a history of politely redirecting usage questions to the help list (while often answering them anyway), likewise with the irc channel. - I believe we also have a history of encouraging input and discussing the technical issues (reasonably) calmly. - to the best of my recollection I have never seen an idea excluded on any basis than technical content. * Without a specific list to process input on governance and project process, this list is a reasonable choice. ——— The observations above, copied from my first email, together with a belief that most of the current and potential contributor to GCC would prefer to function in a constructive environment, lead to the following proposition: * that, since the lists are generally constructive without additional management, (OK. there are occasional heated technical debates), it implies that this community by-and-large is already able to function without heavy-handed moderation. * It has been postulated that there could be valued technical input from people who have difficulty in interacting in a constructive manner (through no fault of their own). * no-one else would be making valued input, either they would be a spammer or intentionally acting in a destructive manner. - Let us propose that someone capable of working on a complex system such as a compiler would be able to read and act on a set of guidelines. - ergo, I propose that we have a set of guidelines to which someone who is being disruptive can be pointed. * (Probably?) no-one has any issue with a spammer being thrown off the list, for which I guess there is a process already - it would be reasonable to expect that genuine contributors (even with difficulties) would make an effort to follow guidelines - and that someone who was making no effort to do so is not really any different from a spammer. Of course, guidelines require debate (but I doubt that the right set would be much different from the obvious for this group). is seems to me that most of the strife in the last two weeks comes from a few key things: - attacking the person delivering a message rather than debating the message - introducing topics spurious and unrelated to the actual debate - trying to equate the process of this project with party or international Politics. === So .. in summary: 1/ I propose that we do have written guidelines, to which someone behaving in a non-constructive manner can be pointed. 2/ if those guidelines *are the consensus* of this group and someone is unable to follow them (given some reasonable chance to amend as is customary in matters such as employment law here, at least), then they are treated no differently from any other spam. Proposing the guidelines essentially means that the community accepts the fact that many of us are incapable of navigate everyday problems and dilemmas by making “right” decisions based on the use of good judgment and values rather than sterile sets of rules and conventions that typically disregard the individual, the particular, or the discrete. However, that isn’t what I wrote - what I wrote was the opposite; that history shows that almost everyone communicating on these lists can do so constructively *without* recourse to written guidelines. It is not the general case that has precipitated this discussion but, rather, the exceptional. Thusly, it is wrong to sugges
Re: removing toxic emailers
What I see here in sum is another high level tightly integrated Red Hat employee saying the gist of "I'm really not saying it out of my employer's interest and it has nothing to do with my personal feelings". Every single proponent of this argument that I have seen so far is employed by one of the same 5 companies and "really isn't doing it on behalf of my company I swear". Why is it almost exclusively that specific crowd saying it here, then? I just don't buy it. Please say anything that would not support the emerging theory that these companies are using integrated employees to try to emulate justification/pretext for a rift to attack the free software world. Anything at all. -C On Thu, 2021-04-15 at 13:31 -0400, David Malcolm via Gcc wrote: > On Thu, 2021-04-15 at 09:49 -0400, Eric S. Raymond wrote: > > Joseph Myers : > > > 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. > > > > I do not have standing to argue this point. > > > > I will, however, point out that it is a very *different* point from > > "RMS has iupset some people and should therefore be canceled". > > [I'm sorry to everyone who's sick of these threads, but I feel I have > to respond to this one; sorry about writing another long email] > > Eric: I don't know if you're just being glib, or you're deliberately > trying to caricature those of us who are upset by RMS's behavior. > > I think the words "canceled" and "cancel culture" have effectively > become meaningless and should be avoided if we want to have a nuanced > discussion - no-one seems to have a definition of what counts as > "canceling" vs "consequences" vs "fair and measured responses". > > At one time, both you and RMS were heroes of mine, and I was a true > believer (of what, I'm no longer sure); I own copies of both "The > Cathedral and the Bazaar" and "Free Software - Free Society", though > both are currently in my attic, gathering dust. > > I've long felt that there was a massive hole in the GNU project and > FSF > where effective technical leadership should have been - various > maintainers on gcc, gdb, etc have been implementing things, and > things > were humming along, and those of us in Red Hat working on them tried > to > coordinate on features we felt were important - but where was the > top- > level response to, say, LLVM/clang? (to name just one of many changes > in the industry) In many ways the last 8 years of my career have > been > an attempt to get gcc to respond to the appearance of LLVM/clang > (I've > added JIT-compilation, improved diagnostics, and I'm implementing a > static analysis pass) - I'm lucky that my managers inside Red Hat are > happy to pay me to hack on this stuff and make GCC better - it helps > our customers, but it also helps GCC, and the broader FLOSS > communities > using both toolchains). > > Where has the technical leadership from RMS been? Instead the long- > standing opposition by RMS to exposing the compiler's IR has hobbled > GCC, and partly contributed to the pile of technical debt we have to > dig our way out of. The only "leadership" coming out of GNU/FSF seem > to me to be dictats from on high about ChangeLog formats and coding > conventions. The GNU project seems to me to be stuck in the 1980s. > Perhaps a pronouncement like: "try to make everything be consumable > as > libraries with APIs, as well as as standalone binaries" might have > helped (and still could; can we do that please?) > > Similarly, I agree with Joseph's observations of the ways that the > FSF > and GNU have been bad umbrella organizations for the toolchain. > > But beyond the failure of technical leadership, and the > organizational > incompetence/incoherence, is RMS's behavior, and the extent to which > it, as you put it "upset some people". > > RMS's defenders seem to have fixated on his 2019 comments on Marvin > Minsky, the uproar over those, and his responses to them (then and > recently), and seem keen to assure us that everything's OK now, or, > at > least on a road to im
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 1:26 PM Chris Punches via Gcc wrote: > > Every single proponent of this argument that I have seen so far is > employed by one of the same 5 companies and "really isn't doing it on > behalf of my company I swear". > > Why is it almost exclusively that specific crowd saying it here, then? For better or for worse, since the early '90s the majority of people who do serious work on GCC have been hired by companies that want to do serious work on GCC. After all, it's a win-win: the company gets work done, the GCC programmer gets well paid. The effect is that most of the major GCC contributors work for a relatively small number of companies. There are of course many exceptions, but that is the general rule. Ian
Re: removing toxic emailers
> >> === > >> > >> So .. in summary: > >> > >> 1/ I propose that we do have written guidelines, to which someone behaving > >> in a > >> non-constructive manner can be pointed. > >> > >> 2/ if those guidelines *are the consensus* of this group and someone is > >> unable to > >> follow them (given some reasonable chance to amend as is customary in > >> matters > >> such as employment law here, at least), then they are treated no > >> differently from > >> any other spam. > > > > Proposing the guidelines essentially means that the community accepts the > > fact > > that many of us are incapable of navigate everyday problems and dilemmas > > by making > > “right” decisions based on the use of good judgment and values rather > > than sterile > > sets of rules and conventions that typically disregard the individual, > > the particular, > > or the discrete. > > However, that isn’t what I wrote - what I wrote was the opposite; that > history shows > that almost everyone communicating on these lists can do so constructively > *without* > recourse to written guidelines. > > It is not the general case that has precipitated this discussion but, > rather, the exceptional. There have been many discussions emanating from Nathan's messages, that toxity is endemic. I disagree with that in practice as you do. But there are some discussions that potentially lead to the opposite. I feel that when the issues at hand produce a series of contrasting views that are significant. taking a guideline approach could result > > Thusly, it is wrong to suggest that the problems are simply associated > > with RMS, FSF and GNU. > > My mail contains no reference to any of these, but simply to identifying > processes > that have failed to work in discussions (about those topics, granted). No, your message did not reference that. But was a general assessment of what I have seen developing. Indeed, the discussion started with the same person suggesting "white male privilege", the source of all toxicity coming from one individual and those associated with him, etc. > > Human beings have the capacity to be wise and develop their thoughts on > > wise > > decision-making skills that evolve from a combination of experience, > > empathy, > > and intellect. Many times, this means having the capacity to break those > > guidelines and rules. > > “rules are for the obedience of fools and the guidance of wise men”? > > As noted above, 99.99% (guessed of course) of the list traffic is carried > out in > the guise you mention, and probably would continue to be so… > > … the proposal is to have a mechanism to deal with the exceptional. That depends on the arguments of the discussion. It is acceptable at times to respond roughly to some kinds of discursive treatment. Although Nathan was allowed to write, he was surely aware of the implications - that a schism was likely. > > In the World Trade Center Disaster, many people who were used to following > > the rules died because they did what they were told by authority figures. > > I know about these things as part of my industrial work experience. > > Probably almost no-one “here” would be able to substantiate or deny this - > am I to > take it that it is a serious data point suggesting that absence of control > is a better > process? There have been numerous historical instances - let's say in the journalistic realm where I do operate - when that was true. Still, I am not against moderation when required in principle. Indeed, it is part of the job as maintainer (and co-maintainers, etc.) to exercise authority on these points when they arise. Personally, I am not afraid to exercise them when associated with my own work. Customarily, I would not oppose to intervention, except on special instances when the assessments was faulty - I specifically mention Gnu Health and the arguments Dr. Luis Falcon had with Savannah regarding package admin. May I remind everybody that Argentina opted for GNU Health for COVID19 observatory and contact tracing. At the time, I was also doing my own work on COVID19 and considered my intervention necessary. > There is no counter experiment to determine the outcome in the case that > there > were no authority figures and no rules (nor would anyone wish to conduct > such an > experiment). > > To me this is spurious input, I cannot see how it could be used to make any > guidance > to the progress here. > > Iain > > > > >>* although one might lose some notionally valuable input, the judgement > >> here is that > >>the net benefit of such input is negative. > >> > >> 3/ I would recommend on the basis of another online community (about > >> music) > >> to > >>which I belong, to suggest that Politics (party or international) and > >> Religion are better > >>discussed in other forums and are exceedingly unlikely to affect a > >> technical decision > >>on the progress of
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 8:51 AM > From: "Ian Lance Taylor via Gcc" > To: chris.punc...@silogroup.org > Cc: "GCC Development" > Subject: Re: removing toxic emailers > > On Thu, Apr 15, 2021 at 1:26 PM Chris Punches via Gcc wrote: > > > > Every single proponent of this argument that I have seen so far is > > employed by one of the same 5 companies and "really isn't doing it on > > behalf of my company I swear". > > > > Why is it almost exclusively that specific crowd saying it here, then? > > For better or for worse, since the early '90s the majority of people > who do serious work on GCC have been hired by companies that want to > do serious work on GCC. After all, it's a win-win: the company gets > work done, the GCC programmer gets well paid. The effect is that most > of the major GCC contributors work for a relatively small number of > companies. There are of course many exceptions, but that is the > general rule. > > Ian Such contributions are valued, and companies where talent is allowed to flow towards the public is commendable, even for those with a history of exploitation. Many of us pay their taxes, not because we see crowds of people sent to jail. But because spontaneous compliance is the way for things to work. That's what I hope for.
Re: removing toxic emailers
On Thu, 2021-04-15 at 16:26 -0400, Chris Punches wrote: > What I see here in sum is another high level tightly integrated Red > Hat > employee saying the gist of "I'm really not saying it out of my > employer's interest and it has nothing to do with my personal > feelings". I'm not sure I'm "high level", but I guess I'll take that as a compliment. I stated that the opinions in my screed were my own, but I'm a former FLOSS enthusiast in the fortunate position of being paid to work on GCC. I've tried to be open about my biases. > > Every single proponent of this argument that I have seen so far is > employed by one of the same 5 companies and "really isn't doing it on > behalf of my company I swear". > > Why is it almost exclusively that specific crowd saying it here, > then? Because, sadly, there's only a small group of companies that employ GCC developers. These developers tend to have an emotional attachment to the project (e.g. a broad agreement with the professed goals of the FSF). Part of the reason I work at Red Hat is that its own internal culture aligns with mine, much of the time, anyway (and I know we're not perfect). Hence there's some correlation between those with strong opinions on the project and those who are being paid to work on it. I don't see that as malicious or a conspiracy - just that we, reasonably, care about the work we do and its context. It's not necessarily just a job for me. > > I just don't buy it. Please say anything that would not support the > emerging theory that these companies are using integrated employees > to > try to emulate justification/pretext for a rift to attack the free > software world. Anything at all. I hope I just did. Dave
Re: Gcc as callable libraries (was: removing toxic emailers)
On Thu, Apr 15, 2021 at 5:04 PM Thomas Koenig via Gcc wrote: > > David, > > for some reason or other, I did not get your mail, so I will > just reply copying in from the archive. > > First, thanks for injecting some sanity into the discussion. > > I will not discuss RMS' personal shortcomings or the lack of them. > In today's toxic political climate, such allegations are often > made up and weaponized without an effective defense for the > alleged wrongdoer. I don't know the truth of the matter, and I make > a point of not finding out. > > > In many ways the last 8 years of my career have been > > an attempt to get gcc to respond to the appearance of LLVM/clang (I've > > added JIT-compilation, improved diagnostics, and I'm implementing a > > static analysis pass) > > And this is highly welcome, and has made gcc (including gfortran) a much > better compiler. I well remember how you implemented the much better > colored error messages that gfortran has now. > > > Perhaps a pronouncement like: "try to make everything be consumable as > > libraries with APIs, as well as as standalone binaries" might have > > helped (and still could; can we do that please?) > > That makes perfect sense, as LLVM shows, and is something that the > steering committee could decide for the project (or rather, it could > issue a pronouncement that this will not be opposed if some volunteer > does it). > > I think this could be as close to an unanimous decision as there can > be among such a diverse community as the gcc developers. If the FSF > takes umbrage at this, the ball is in their court. Andrew Macleod led a BOF at GNU Cauldron 2013 that discussed re-architecting and modularizing GCC along these same lines. The header flattening was one step. Thanks, David
Re: Gcc as callable libraries (was: removing toxic emailers)
On Thu, 2021-04-15 at 21:48 +0200, Thomas Koenig wrote: > David, > > for some reason or other, I did not get your mail, so I will > just reply copying in from the archive. > > First, thanks for injecting some sanity into the discussion. Thanks Thomas > I will not discuss RMS' personal shortcomings or the lack of them. > In today's toxic political climate, such allegations are often > made up and weaponized without an effective defense for the > alleged wrongdoer. I don't know the truth of the matter, and I make > a point of not finding out. Fair enough. > > In many ways the last 8 years of my career have been > > an attempt to get gcc to respond to the appearance of LLVM/clang > (I've > > added JIT-compilation, improved diagnostics, and I'm implementing > a > > static analysis pass) > > And this is highly welcome, and has made gcc (including gfortran) a > much > better compiler. I well remember how you implemented the much better > colored error messages that gfortran has now. I've added a bunch of features to the C and C++ frontends (underlined ranges, labelling of such reanges, fix-it hints, etc), but I don't have the Fortran skills to know what would be appropriate to gfortran. Let me know if you have ideas for specific improvements to how gfortran diagnostics work that I might be able to help implement. > > > Perhaps a pronouncement like: "try to make everything be > consumable as > > libraries with APIs, as well as as standalone binaries" might have > > helped (and still could; can we do that please?) > > That makes perfect sense, as LLVM shows, and is something that the > steering committee could decide for the project (or rather, it could > issue a pronouncement that this will not be opposed if some volunteer > does it). > > I think this could be as close to an unanimous decision as there can > be among such a diverse community as the gcc developers. If the FSF > takes umbrage at this, the ball is in their court. I deliberately added the weasel-words "try to", because these things are, of course, much easier said that done. I attempted to reduce gcc's use of global state back in 2013 with a view to making it a shared library, but eventually the sheer size of the task overwhelmed me. In libgccjit I hid everything behind a separate API, with a bug mutex guarding all of gcc's global state, which feels like something of a cop-out. One idea I had would be to refactor out our diagnostics code into a libdiagnostics (or similar), so that all of the source- printing/underlining/fix-it logic etc could be used outside of gcc, and the use of diagnostic_context might help towards that. But even "just" that's decidedly non-trivial. Hope this is constructive Dave
Re: Gcc as callable libraries (was: removing toxic emailers)
On Thu, 2021-04-15 at 17:31 -0400, David Malcolm via Gcc wrote: > On Thu, 2021-04-15 at 21:48 +0200, Thomas Koenig wrote: [...snip...] > > > Perhaps a pronouncement like: "try to make everything be > > consumable as > > > libraries with APIs, as well as as standalone binaries" might > > have > > > helped (and still could; can we do that please?) > > > > That makes perfect sense, as LLVM shows, and is something that the > > steering committee could decide for the project (or rather, it > > could > > issue a pronouncement that this will not be opposed if some > > volunteer > > does it). > > > > I think this could be as close to an unanimous decision as there > > can > > be among such a diverse community as the gcc developers. If the > > FSF > > takes umbrage at this, the ball is in their court. > > I deliberately added the weasel-words "try to", because these things > are, of course, much easier said that done. > > I attempted to reduce gcc's use of global state back in 2013 with a > view to making it a shared library, but eventually the sheer size of > the task overwhelmed me. In libgccjit I hid everything behind a > separate API, with a bug mutex guarding all of gcc's global state, ~~~ big, I meant to write. > which feels like something of a cop-out. libgccjit calls into as and ld, which shows up in the profile, so another idea I dabbled in the whole "libraries rather than just executables" area is to make as and ld buildable as shared libraries; hence this 2015 experiment: "[PATCH 00/16] RFC: Embedding as and ld inside gcc driver and into libgccjit" crossposted between gcc-patches and binutils here: https://gcc.gnu.org/legacy-ml/gcc-patches/2015-06/msg00116.html https://sourceware.org/legacy-ml/binutils/2015-06/msg00010.html (admittedly my prototype had a barely-existent API, but it gave me a 5x speedup on a synthetic benchmark, which was dominated by the overhead of dynamically linking libbfd into as and ld on each invocation IIRC; better to do it once when libgccjit is linked into the process). > > One idea I had would be to refactor out our diagnostics code into a > libdiagnostics (or similar), so that all of the source- > printing/underlining/fix-it logic etc could be used outside of gcc, and > the use of diagnostic_context might help towards that. But even "just" > that's decidedly non-trivial. > > Hope this is constructive > Dave > >
Re: removing toxic emailers
On Thu, 15 Apr 2021 at 21:26, Chris Punches via Gcc wrote: > > What I see here in sum is another high level tightly integrated Red Hat > employee saying the gist of "I'm really not saying it out of my > employer's interest and it has nothing to do with my personal > feelings". > > Every single proponent of this argument that I have seen so far is > employed by one of the same 5 companies and "really isn't doing it on > behalf of my company I swear". > > Why is it almost exclusively that specific crowd saying it here, then? > > I just don't buy it. Please say anything that would not support the > emerging theory that these companies are using integrated employees to > try to emulate justification/pretext for a rift to attack the free > software world. Anything at all. > One reason you might be seeing this is people who (a) are not paid to work on GCC, and (b) found RMS and parts of the GNU community unpleasant to work with, left years ago. Chris
gcc-8-20210415 is now available
Snapshot gcc-8-20210415 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20210415/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision 76b6aa67489132e725af34f14938e9d8d6ef4a67 You'll find: gcc-8-20210415.tar.xzComplete GCC SHA256=d391b3d3c4dff9933b32db5366a1a6ca3e0f575970a267e9b2202139799d3d0b SHA1=5da5b1afb5d8cb706a8403623c21b8bd1a6c41f5 Diffs from 8-20210408 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: removing toxic emailers
On 4/15/2021 2:26 PM, Chris Punches via Gcc wrote: What I see here in sum is another high level tightly integrated Red Hat employee saying the gist of "I'm really not saying it out of my employer's interest and it has nothing to do with my personal feelings". Every single proponent of this argument that I have seen so far is employed by one of the same 5 companies and "really isn't doing it on behalf of my company I swear". Why is it almost exclusively that specific crowd saying it here, then? I just don't buy it. Please say anything that would not support the emerging theory that these companies are using integrated employees to try to emulate justification/pretext for a rift to attack the free software world. Anything at all. [ Again, speaking or myself, not my employer or for the steering committee. ] So first, my employer (Tachyum) has had absolutely no clue what's going on with this discussion until yesterday afternoon when I mentioned it in passing. We're much more focused on getting our bits where they need to be rather than policy, procedures and politics of the upstream projects. However they have repeatedly, up to the CEO level emphasized that upstreaming our work and being good players in the various relevant communities is important and the various concerns I raised around that prior to joining were answered to my satisfaction. Second, I was the technical lead for Red Hat's tools team until about a month ago. I've also held management positions in Red Hat (and Cygnus prior to the acquisition) during my 25+ year career there. Red Hat and Cygnus have consistently worked through the years to be good stewards for the GNU tools. Management has consistently had a hands-off approach to the upstream community, allowing engineers to exercise their own judgment on if when and how to engage in various discussions. The only time management got involved in these kinds of discussions was to throw support behind EGCS -- including being supportive of bringing in outside advisors for what ultimately became the steering committee. You may not buy it, but that's OK. That's ultimately your decision to make. I do buy it. It's consistent with what I've seen over nearly three decades of dealing with GNU tools and what I've *directly observed* as part of the leadership and management teams. Jeff
Re: removing toxic emailers
On Thu Apr 15, 2021 at 3:40 PM BST, Eric S. Raymond wrote:
> I intended the weaker observation that driving away a large number of
> smart autistic assholes (and non-assholes with poor social skills)
> is not necessarily a good trade for the people the project might
> recruit by being "more welcoming".
>
> Possibly that *would* be a good trade. I have decades of experience
> that makes me doubt this. I think the claim needs to be examined
> skeptically, not just uncritically accepted because we value being
> "nice".
I'm not even sure that this only applies to autists, over the years
I've had various interactions where I've thought someone was being
an asshole but it turned out English wasn't their first language and
they just lacked the depth of vocabulary to express a point politely.
There are also huge disparities in what cultures deem to be polite vs
impolite (high context vs low context cultures, cultural sensitivities
to particular phrases or concepts, etc). I remain unconvinced that
trying to define 'jerks' by a narrow-minded west coast American ideal
and enforce that on a global community is not, itself, jerkish.
More often than not, strict speech codes just encourage people to
assume bad faith of each other, and to tone police each other instead
of engaging in substantive debate on the issues. I also cannot remember
ever seeing one enforced equally against everyone, rather than become
a tool of an entrenched majority culture against a minority culture.
I have yet to see a project where a strict speech code has improved the
dialectic, rather than degraded it.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Thu Apr 15, 2021 at 9:51 PM BST, Ian Lance Taylor via Gcc wrote:
> On Thu, Apr 15, 2021 at 1:26 PM Chris Punches via Gcc
> wrote:
> >
> > Every single proponent of this argument that I have seen so far is
> > employed by one of the same 5 companies and "really isn't doing it on
> > behalf of my company I swear".
> >
> > Why is it almost exclusively that specific crowd saying it here, then?
>
> For better or for worse, since the early '90s the majority of people
> who do serious work on GCC have been hired by companies that want to
> do serious work on GCC. After all, it's a win-win: the company gets
> work done, the GCC programmer gets well paid. The effect is that most
> of the major GCC contributors work for a relatively small number of
> companies. There are of course many exceptions, but that is the
> general rule.
>
> Ian
In my view, if people employed by a small number of American companies
succeed in disassociating GCC from GNU/FSF, which is representative of
the free software grassroots community, this is not a win-win. This is
powerful US corporations removing something our community created from
our community's oversight and moving it into a space where it's governed
by representatives of Silicon Valley rather than a membership-based non
profit.
Whilst everyone's contributions to the software should be welcomed, I
don't think you'll find many FSF members celebrating the impact of paid
Corporate engineers on GCC if this sorry state of affairs comes to be.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 6:30 PM David Malcolm via Gcc wrote: > On Thu, 2021-04-15 at 16:26 -0400, Chris Punches wrote: > > What I see here in sum is another high level tightly integrated Red > > Hat > > employee saying the gist of "I'm really not saying it out of my > > employer's interest and it has nothing to do with my personal > > feelings". > > I'm not sure I'm "high level", but I guess I'll take that as a > compliment. > > I stated that the opinions in my screed were my own, but I'm a former > FLOSS enthusiast in the fortunate position of being paid to work on > GCC. I've tried to be open about my biases. Then let me offer my perspective, again. I am not affiliated with RedHat, IBM, or what have you. I do not work for them, never have worked for them, and have contributed to the C, C++, and other Systems Programming communities entirely out-of-pocket or through scholarship and donation. I submitted my Copyright Revocation to the Free Software Foundation after giving the greenlight to merge the last of my already-submitted patches into GCC. Stallman is an exceptionally poor leader for Free Software. We routinely complain about LLVM here but Stallman had the chance to get on top of LLVM and guide it into the Free Software world; he missed the e-mail and "found" it 10 years later. Stallman was horrible to the people employed by the Free Software Foundation and apparently the board was barely able to keep him in check, resulting in his employees needing to have Shop Stewards with a Union in order to keep it workable for employees. Stallman is terrible at his job, and this group's inability to have a secondary or tertiary copyright assignment has cost them my contributions for the foreseeable future. Stallman's defenders are ableist, because Stallman himself - in the FSF book and more - have publicly stated that he is not autistic or neurodivergent. Stallman has also stated this publicly, but the fact that Bruce Perens, Eric S. Raymond, and more feel the need to show up and claim on behalf of all Neuroatypical people and Neurodivergent people that they are fighting for us while pushing a disgusting, ableist theory that "Neurodivergent == Definitely An Asshole And Needs To Be Deprived Of Agency For Their Actions" is disgusting. That people feel the need to stereotype neurodivergent people like me for the sake of Stallman's defense is horrible. That people would stand by and claim this is some kind of great advocacy for someone like me is a series of mental gymnastics I do not want to be apart of. This place is fetid, and contrary to Raymond's idea that toxicity has no cost, it most certainly did cost it myself and many other people like me. Sincerely, JeanHeyd
Re: removing toxic emailers
David Malcolm : > > I will, however, point out that it is a very *different* point from > > "RMS has iupset some people and should therefore be canceled". > > Eric: I don't know if you're just being glib, or you're deliberately > trying to caricature those of us who are upset by RMS's behavior. My intent was not caricature. I was being dismissive and snarky because I genuinely consider the personality complaints against RMS to be pretty trivial. Not the managerial ones Joseph Myers listed; those are serious. But they're not the cause of the current ruckus. To make the "triviality" point in the most forceful possible way, I will take the bull by the horns and directly address RMS's behavior towards women. And I will reveal a few things that I haven't talked about in public for 40 years. I've known RMS since 1979; I'm fully aware of how obnoxious he can be towards both men and women. There have been occasions on which I have thought the state of the universe would have been improved if he'd gotten a swift slap in the face. In fact, the first or second time I met him face to face it was because he was rather determinedly pursuing my then-girlfriend. A hostile witness might have said he was creeping on her, though that slang for it wouldn't be invented until much later. I think an explanation of how how I reasoned about that situation has some value in light of the current attempt to ostracize RMS. I paid very careful attention to whether my girlfriend appeared to need any help dealing with him. I regarded her as an adult fully capable of making her own decisions. One of those decisions could have been to slap his face. If a more severe sanction had been required, and she had yelled for help, I would cheerfully have punched his lights out. No fisticuffs were required. She gently discouraged him, and we both established friendly relations with him. In later years RMS and I remained fairly close long after I broke up with that girlfriend. He made passes at at least two of my later girlfriends that I know of, including the woman I am still married to. In all cases, I trusted these ladies to handle the situation like adults, and they did. It really would not have occurred to me to do otherwise. I hear a lot of talk about RMS's behavior towards women being some sort of vast horrible transgression that will drive all women everywhere to flee from ever being contributors to FSF projects. To me this seems just silly, and very infantilizing of women in general. My girlfriends were emtirely able to (1) short-stop his advances when they became unwelcome (2) understand that some men have poor social skills and trouble recognizing boundaries, (3) and *stay on friendly terms with him anyway*. I mean I saw this not just more than once, but every single time it came up. I don't assume that any adult female is incapable of these things; I respect women as fully capable of asserting and defending their interests, I *expect* women to do that, and I thus consider a lot of the white-knighting on their behalf to be at best empty virtue signaling and at worst a cover for much more discreditable motives. Of course, he offends men too. When I deal with RMS, I know that I'm going to have to cope with a certain amount of unpleasantness because he has autism-like deficits amplified by some unfortunate personal history. Yes. So what? He's one of my oldest friends anyway. He has many admirable qualities; I respect and value him even when I have to argue with him. And I can work with him when I need to. Why in the *hell* should I assume anyone with female genitalia is incapable of doing the same? More to the point, why is anybody else making such a silly, reductive assumption and then turning it into a galloping moral panic that somehow justifies stoning RMS and driving him out of the village? *grumble* Get *over* yourselves. You want to be "welcoming" to women? Don't patronize or infantilize them - respect their ability to tell off RMS for themselves *and then keep working with him*! -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 11:11 AM
> From: "Frosku"
> To: "Ian Lance Taylor" , chris.punc...@silogroup.org
> Cc: "GCC Development"
> Subject: Re: removing toxic emailers
>
> On Thu Apr 15, 2021 at 9:51 PM BST, Ian Lance Taylor via Gcc wrote:
> > On Thu, Apr 15, 2021 at 1:26 PM Chris Punches via Gcc
> > wrote:
> > >
> > > Every single proponent of this argument that I have seen so far is
> > > employed by one of the same 5 companies and "really isn't doing it on
> > > behalf of my company I swear".
> > >
> > > Why is it almost exclusively that specific crowd saying it here, then?
> >
> > For better or for worse, since the early '90s the majority of people
> > who do serious work on GCC have been hired by companies that want to
> > do serious work on GCC. After all, it's a win-win: the company gets
> > work done, the GCC programmer gets well paid. The effect is that most
> > of the major GCC contributors work for a relatively small number of
> > companies. There are of course many exceptions, but that is the
> > general rule.
> >
> > Ian
>
> In my view, if people employed by a small number of American companies
> succeed in disassociating GCC from GNU/FSF, which is representative of
> the free software grassroots community, this is not a win-win. This is
> powerful US corporations removing something our community created from
> our community's oversight and moving it into a space where it's governed
> by representatives of Silicon Valley rather than a membership-based non
> profit.
>
> Whilst everyone's contributions to the software should be welcomed, I
> don't think you'll find many FSF members celebrating the impact of paid
> Corporate engineers on GCC if this sorry state of affairs comes to be.
The commercial use of free software is our hope, not our fear. When people
at IBM began to come to free software, wanting to recommend it and use it,
and maybe distribute it themselves or encourage other people to distribute
it for them, we did not criticise them for not being non-profit virtuous
enough, or said "we are suspicious of you", let alone threatening them.
> >>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
>
Re: removing toxic emailers
On Fri Apr 16, 2021 at 12:36 AM BST, Christopher Dimech wrote:
>
> The commercial use of free software is our hope, not our fear. When
> people
> at IBM began to come to free software, wanting to recommend it and use
> it,
> and maybe distribute it themselves or encourage other people to
> distribute
> it for them, we did not criticise them for not being non-profit virtuous
> enough, or said "we are suspicious of you", let alone threatening them.
>
There is a colossal difference between commercial use and commercial
entities buying control of projects currently governed by entities
which are answerable to the grassroots (GNU) and then toppling that
governance structure in favor of one which is only answerable to
boardrooms in Silicon Valley and Seattle WA.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
> On Apr 15, 2021, at 7:44 PM, Frosku wrote: > > On Fri Apr 16, 2021 at 12:36 AM BST, Christopher Dimech wrote: >> >> The commercial use of free software is our hope, not our fear. When >> people >> at IBM began to come to free software, wanting to recommend it and use >> it, >> and maybe distribute it themselves or encourage other people to >> distribute >> it for them, we did not criticise them for not being non-profit virtuous >> enough, or said "we are suspicious of you", let alone threatening them. >> > > There is a colossal difference between commercial use and commercial > entities buying control of projects currently governed by entities > which are answerable to the grassroots (GNU) and then toppling that > governance structure in favor of one which is only answerable to > boardrooms in Silicon Valley and Seattle WA. There are, or would be if that were a real issue. It's not something that is feasible with GPL licensed code, whether the copyright is held by the FSF as it is for GCC, or by all the authors as for Linux. paul
Re: removing toxic emailers
Christopher Dimech via Gcc : > The commercial use of free software is our hope, not our fear. When people > at IBM began to come to free software, wanting to recommend it and use it, > and maybe distribute it themselves or encourage other people to distribute > it for them, we did not criticise them for not being non-profit virtuous > enough, or said "we are suspicious of you", let alone threatening them. Actually, some of us did *exactly* those things late in the last century. One of the challenges I faced in my early famous years was persuading the hacker culture as a whole to treat the profit-centered parts of the economy as allies rather than enemies. I won't say that a *majority* of us were resistent to this, but I did have to work hard on the problem for a while, between 1997 and about 2003. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: removing toxic emailers
On Fri Apr 16, 2021 at 12:52 AM BST, Paul Koning wrote:
>
>
> > On Apr 15, 2021, at 7:44 PM, Frosku wrote:
> >
> > On Fri Apr 16, 2021 at 12:36 AM BST, Christopher Dimech wrote:
> >>
> >> The commercial use of free software is our hope, not our fear. When
> >> people
> >> at IBM began to come to free software, wanting to recommend it and use
> >> it,
> >> and maybe distribute it themselves or encourage other people to
> >> distribute
> >> it for them, we did not criticise them for not being non-profit virtuous
> >> enough, or said "we are suspicious of you", let alone threatening them.
> >>
> >
> > There is a colossal difference between commercial use and commercial
> > entities buying control of projects currently governed by entities
> > which are answerable to the grassroots (GNU) and then toppling that
> > governance structure in favor of one which is only answerable to
> > boardrooms in Silicon Valley and Seattle WA.
>
> There are, or would be if that were a real issue. It's not something
> that is feasible with GPL licensed code, whether the copyright is held
> by the FSF as it is for GCC, or by all the authors as for Linux.
>
> paul
Paul,
Short of maintaining the FSF branch of the fork, I don't see a way to
keep the project's direction accountable to end users.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Fri, 16 Apr 2021, Frosku wrote: > There is a colossal difference between commercial use and commercial > entities buying control of projects currently governed by entities > which are answerable to the grassroots (GNU) and then toppling that RMS's notion of GNU is as something under his personal direction and control, not answerable to the grassroots at all. For answerability to the grassroots, whatever organization the toolchain falls under, it's better for it to *explicitly* act only as an umbrella organization, serving the toolchain community rather than having any authority to direct it. -- Joseph S. Myers jos...@codesourcery.com
Re: removing toxic emailers
On Fri Apr 16, 2021 at 12:52 AM BST, Eric S. Raymond wrote:
> Christopher Dimech via Gcc :
> > The commercial use of free software is our hope, not our fear. When people
> > at IBM began to come to free software, wanting to recommend it and use it,
> > and maybe distribute it themselves or encourage other people to distribute
> > it for them, we did not criticise them for not being non-profit virtuous
> > enough, or said "we are suspicious of you", let alone threatening them.
>
> Actually, some of us did *exactly* those things late in the last
> century.
>
> One of the challenges I faced in my early famous years was persuading
> the hacker culture as a whole to treat the profit-centered parts of the
> economy as allies rather than enemies.
>
> I won't say that a *majority* of us were resistent to this, but I
> did have to work hard on the problem for a while, between 1997
> and about 2003.
ESR,
My criticism has nothing to do with profit and everything to do with
accountability. GCC is a project which is used by almost everyone in the
ecosystem, and whose future direction is important to almost everyone in
the ecosystem. Right now, the ultimate oversight of GCC sits with GNU &
FSF -- both institutions with a mandate to represent the ecosystem based
on level of membership and time spent fighting for free software.
GCC forking away from those institutions removes that oversight, and
unless something which is equally or more representative is brought in to
replace that oversight role, I find it difficult to believe that this
doesn't represent a huge step backwards in terms of who ultimately has
an input into the future direction of GCC. It should be, at the very
minimum, challenging for representatives of Google, Red Hat and other
corporations to convince anyone -- after wrestling the project away from
GCC -- that their interests are not at odds with GCC users'.
I would say *exactly* the same thing if you replaced Google/Red Hat with
nonprofits which have less trust in free software than GNU/FSF.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Fri, 16 Apr 2021, Frosku wrote: > Right now, the ultimate oversight of GCC sits with GNU & > FSF -- both institutions with a mandate to represent the ecosystem based > on level of membership and time spent fighting for free software. I think the oversight of glibc by development working through discussion seeking consensus, and rejecting any attempt to override such consensus "from above", is much more effective than any attempt GNU or FSF makes at oversight. An umbrella organization for the toolchain should not act as an "above" that can override the community at all; it should provide services to the toolchain (e.g. legal support) as needed. -- Joseph S. Myers jos...@codesourcery.com
Re: removing toxic emailers
I fully agree with your assessment. Have in the past organised meetings for him and never seen any bs. Having led the discussions, RMS was always cooperative and at no point disrupted procedure. This was 2017-2018 when I was in Barcelona coordinating all this - leading to the CaixaForum conversation on digital cities with Barcelona City Council Chief of Technology Francesca Bria. And other interactions, e.g. with Behavioral Expert Dr Diane Hamilton. If anyone thinks the two women needed white-knighting, people who think this way, should go and get their head tested. Although the 14th century is long past, many educated people today are either uneducated, or education has educated them out of it. - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Friday, April 16, 2021 at 11:28 AM > From: "Eric S. Raymond" > To: "David Malcolm" > Cc: gcc@gcc.gnu.org, "Nathan Sidwell" , "Joseph Myers" > > Subject: Re: removing toxic emailers > > David Malcolm : > > > I will, however, point out that it is a very *different* point from > > > "RMS has iupset some people and should therefore be canceled". > > > > Eric: I don't know if you're just being glib, or you're deliberately > > trying to caricature those of us who are upset by RMS's behavior. > > My intent was not caricature. I was being dismissive and snarky > because I genuinely consider the personality complaints against RMS to > be pretty trivial. Not the managerial ones Joseph Myers listed; those > are serious. But they're not the cause of the current ruckus. > > To make the "triviality" point in the most forceful possible way, I > will take the bull by the horns and directly address RMS's behavior towards > women. And I will reveal a few things that I haven't talked about in > public for 40 years. > > I've known RMS since 1979; I'm fully aware of how obnoxious he can be > towards both men and women. There have been occasions on which I have > thought the state of the universe would have been improved if he'd > gotten a swift slap in the face. > > In fact, the first or second time I met him face to face it was > because he was rather determinedly pursuing my then-girlfriend. > A hostile witness might have said he was creeping on her, though > that slang for it wouldn't be invented until much later. > > I think an explanation of how how I reasoned about that situation has > some value in light of the current attempt to ostracize RMS. > > I paid very careful attention to whether my girlfriend appeared to > need any help dealing with him. I regarded her as an adult fully > capable of making her own decisions. One of those decisions could > have been to slap his face. If a more severe sanction had been > required, and she had yelled for help, I would cheerfully have > punched his lights out. > > No fisticuffs were required. She gently discouraged him, and we both > established friendly relations with him. In later years RMS and I > remained fairly close long after I broke up with that girlfriend. He > made passes at at least two of my later girlfriends that I know of, > including the woman I am still married to. In all cases, I trusted > these ladies to handle the situation like adults, and they did. It > really would not have occurred to me to do otherwise. > > I hear a lot of talk about RMS's behavior towards women being some sort > of vast horrible transgression that will drive all women everywhere to > flee from ever being contributors to FSF projects. To me this seems > just silly, and very infantilizing of women in general. My > girlfriends were emtirely able to > > (1) short-stop his advances when they became unwelcome > > (2) understand that some men have poor social skills and > trouble recognizing boundaries, > > (3) and *stay on friendly terms with him anyway*. > > I mean I saw this not just more than once, but every single time it > came up. > > I don't assume that any adult female is incapable of these things; I > respect women as fully capable of asserting and defending their > interests, I *expect* women to do that, and I thus consider a lot of the > white-knighting on their behalf to be at best empty virtue signaling > and at worst a cover for much more discreditable motives. > > Of course, he offends men too. When I deal with RMS, I know that I'm > going to have to cope with a certain amount of unpleasantness because > he has autism-like deficits amplified by some unfortunate personal > history. Yes. So what? He's one of my oldest friends anyway. He > has many admirable qualities; I respect and value him even when I have > to argue with him. And I can work with him when I need to. > > Why in the *hell* should I assume anyone with female genitalia is > incapable of doing the same? More
Re: removing toxic emailers
On Fri Apr 16, 2021 at 1:16 AM BST, Joseph Myers wrote:
> On Fri, 16 Apr 2021, Frosku wrote:
>
> > Right now, the ultimate oversight of GCC sits with GNU &
> > FSF -- both institutions with a mandate to represent the ecosystem based
> > on level of membership and time spent fighting for free software.
>
> I think the oversight of glibc by development working through discussion
> seeking consensus, and rejecting any attempt to override such consensus
> "from above", is much more effective than any attempt GNU or FSF makes
> at
> oversight. An umbrella organization for the toolchain should not act as
> an "above" that can override the community at all; it should provide
> services to the toolchain (e.g. legal support) as needed.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
The way I see it, the developers represent the interests of the developers,
and FSF/GNU represent the interests of the users. The users should always
have some level of representation in any steering discussion, especially
for a project like GCC where any poor decision could have a negative effect
on so many other free software projects.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 11:52 AM > From: "Eric S. Raymond" > To: "Christopher Dimech" > Cc: "Frosku" , "GCC Development" > Subject: Re: removing toxic emailers > > Christopher Dimech via Gcc : > > The commercial use of free software is our hope, not our fear. When people > > at IBM began to come to free software, wanting to recommend it and use it, > > and maybe distribute it themselves or encourage other people to distribute > > it for them, we did not criticise them for not being non-profit virtuous > > enough, or said "we are suspicious of you", let alone threatening them. > > Actually, some of us did *exactly* those things late in the last century. When I worked in ocean acoustics, everything was kept secret. Yet russian oceanographers (e.g. Leonid Brekhovshkikh who was working in the Sea Japan) had themselves figured out the same phenomena independently at around the same time. > One of the challenges I faced in my early famous years was persuading > the hacker culture as a whole to treat the profit-centered parts of the > economy as allies rather than enemies. > > I won't say that a *majority* of us were resistent to this, but I > did have to work hard on the problem for a while, between 1997 > and about 2003. About ten years ago, free software was chosen as the operating system of the International Space Station. Things have been changing, but I agree that there is much work to be done. Our approach has been a noticeable proposition, not just to us - though we understand why it is socially and politically desirable that the world works this way. > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > >
Re: removing toxic emailers
> Sent: Friday, April 16, 2021 at 12:16 PM > From: "Joseph Myers" > To: "Frosku" > Cc: e...@thyrsus.com, "Christopher Dimech" , "GCC > Development" > Subject: Re: removing toxic emailers > > On Fri, 16 Apr 2021, Frosku wrote: > > > Right now, the ultimate oversight of GCC sits with GNU & > > FSF -- both institutions with a mandate to represent the ecosystem based > > on level of membership and time spent fighting for free software. > > I think the oversight of glibc by development working through discussion > seeking consensus, and rejecting any attempt to override such consensus > "from above", is much more effective than any attempt GNU or FSF makes at > oversight. An umbrella organization for the toolchain should not act as > an "above" that can override the community at all; it should provide > services to the toolchain (e.g. legal support) as needed. It should act as an umbrella organization for distributing useful code under robust legal theory during the production of software in commons. That's my position, anyway. > -- > Joseph S. Myers > jos...@codesourcery.com >
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 4:29 PM Eric S. Raymond wrote: > > *grumble* Get *over* yourselves. You want to be "welcoming" to > women? Don't patronize or infantilize them - respect their ability to > tell off RMS for themselves *and then keep working with him*! Thank you for sharing your experiences. I just want to note that I think this last paragraph misses the point. Patronizing or infantilizing anybody doesn't come into this at all. This is about work. There are social aspects to free software, but it's not fundamentally a social activity. It's about getting something done, and for many people it's their job. For the sake of argument, I'm going to temporarily set aside all consideration of how people should behave in a professional setting, not because it doesn't matter, but just to try to clarify matters. Let's just think about the project. We want free software to succeed. Free software is more likely to succeed if more people work on it. If you are a volunteer, as many are, you can choose to spend your time on the project where you have to short-stop unwelcome advances, where you are required to deal with "men with poor social skills." Or you can choose to spend your time on the project where people treat you with respect. Which one do you choose? Or perhaps you have a job that requires you to work on free software. Now, if you work on a project where the people act like RMS, you are being forced by your employer to work in a space where you face unwelcome advances and men who have "trouble recognizing boundaries." That's textbook hostile environment, and a set up for you to sue your employer. So your employer will never ask anyone to work on a project where people act like that--at least, they won't do it more than once. In other words, having people who act in the way that you describe RMS as acting is actively harmful for a free software project, because it will discourage people from working on it. (Entirely separately, I don't get the slant of your whole e-mail. You can put up with RMS despite the boorish behavior you describe. Great. You're a saint. Why do you expect everyone else to be a saint? I don't meet with people who act like that, not more than once. Life is too short. I'll work with them if I must, but not if I don't have to.) Ian
Re: removing toxic emailers
On Fri Apr 16, 2021 at 3:47 AM BST, Ian Lance Taylor via Gcc wrote:
> This is about work. There are social aspects to free software, but
> it's not fundamentally a social activity. It's about getting
> something done, and for many people it's their job. For the sake of
> argument, I'm going to temporarily set aside all consideration of how
> people should behave in a professional setting, not because it doesn't
> matter, but just to try to clarify matters. Let's just think about
> the project.
>
> We want free software to succeed. Free software is more likely to
> succeed if more people work on it. If you are a volunteer, as many
> are, you can choose to spend your time on the project where you have
> to short-stop unwelcome advances, where you are required to deal with
> "men with poor social skills." Or you can choose to spend your time
> on the project where people treat you with respect. Which one do you
> choose?
The one where technical excellence is prioritized over social skills,
personally. If I have a choice between partaking in a project where I
have to walk on eggshells for fear of people coming with torches and
pitchforks to expel me because I was a bit too harsh in my critique or
posted an opinion on my personal blog which wasn't something they
agreed with, or a project where some of the other people are people I
wouldn't share a beer with but the technical standard is high and free
expression is generally valued, I would choose the latter.
This comes down to culture. I did not grow up in a culture where I was
taught that other people need to wrap me in cotton wool. I grew up in a
culture where arguments were judged on merit and generally as people we
accepted other peoples' rights to hold shitty opinions. For many of us,
the latter is more comfortable.
> Or perhaps you have a job that requires you to work on free software.
> Now, if you work on a project where the people act like RMS, you are
> being forced by your employer to work in a space where you face
> unwelcome advances and men who have "trouble recognizing boundaries."
> That's textbook hostile environment, and a set up for you to sue your
> employer. So your employer will never ask anyone to work on a project
> where people act like that--at least, they won't do it more than once.
I have never seen RMS act like that in a technical setting though, and
if he did, I think that would be a valid reason to remove him from the
mailing list and demand that GNU chooses someone else to represent
itself when communicating with GCC.
> In other words, having people who act in the way that you describe RMS
> as acting is actively harmful for a free software project, because it
> will discourage people from working on it.
>
> (Entirely separately, I don't get the slant of your whole e-mail. You
> can put up with RMS despite the boorish behavior you describe. Great.
> You're a saint. Why do you expect everyone else to be a saint? I
> don't meet with people who act like that, not more than once. Life is
> too short. I'll work with them if I must, but not if I don't have
> to.)
I don't think anyone needs to be a saint, but we do need to be able to
collaborate with people from different cultural, political, and personal
backgrounds to our own. Enforcing a social code which is exclusive to
the coasts of the United States on a global community seems to me to be
even more exclusionary than allowing people with poor social skills.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 8:02 PM Frosku wrote: > > > We want free software to succeed. Free software is more likely to > > succeed if more people work on it. If you are a volunteer, as many > > are, you can choose to spend your time on the project where you have > > to short-stop unwelcome advances, where you are required to deal with > > "men with poor social skills." Or you can choose to spend your time > > on the project where people treat you with respect. Which one do you > > choose? > > The one where technical excellence is prioritized over social skills, > personally. If I have a choice between partaking in a project where I > have to walk on eggshells for fear of people coming with torches and > pitchforks to expel me because I was a bit too harsh in my critique or > posted an opinion on my personal blog which wasn't something they > agreed with, or a project where some of the other people are people I > wouldn't share a beer with but the technical standard is high and free > expression is generally valued, I would choose the latter. Those are not the only two possible ways that a project can work. Also, you seem to be making the implicit assumption that there is some sort of trade off between technical excellence and social skills. That is false. They are independent axes. Ian
Re: removing toxic emailers
On Fri Apr 16, 2021 at 4:19 AM BST, Ian Lance Taylor wrote:
> On Thu, Apr 15, 2021 at 8:02 PM Frosku wrote:
> >
> > > We want free software to succeed. Free software is more likely to
> > > succeed if more people work on it. If you are a volunteer, as many
> > > are, you can choose to spend your time on the project where you have
> > > to short-stop unwelcome advances, where you are required to deal with
> > > "men with poor social skills." Or you can choose to spend your time
> > > on the project where people treat you with respect. Which one do you
> > > choose?
> >
> > The one where technical excellence is prioritized over social skills,
> > personally. If I have a choice between partaking in a project where I
> > have to walk on eggshells for fear of people coming with torches and
> > pitchforks to expel me because I was a bit too harsh in my critique or
> > posted an opinion on my personal blog which wasn't something they
> > agreed with, or a project where some of the other people are people I
> > wouldn't share a beer with but the technical standard is high and free
> > expression is generally valued, I would choose the latter.
>
> Those are not the only two possible ways that a project can work.
>
> Also, you seem to be making the implicit assumption that there is some
> sort of trade off between technical excellence and social skills.
> That is false. They are independent axes.
I shouldn't really use the term 'social skills' when what I really mean is
conformance to a specific set of cultural norms. I don't necessarily think
that social skills are quantifiable in the way that i.e. writing performant
and secure code is. Someone could be highly compliant with social norms in
their own culture, in their first language, without necessarily being as
conformant with foreign cultural norms in a second language, for example.
I agree with you that a project which creates a hostile atmosphere to women
would drive people away, not just women but men with a sense of decency. I
would not want to be a part of such a project. I would differ from you on
whether RMS has created such a thing given his seemingly limited
interactions with the project spaces. If I am wrong, and he has been here
harassing women, or on other project-related spaces, I am very willing to
admit I'm wrong.
On the other hand, I also think that a project which goes too far in
policing speech, especially speech unrelated to the project, will drive away
talented people who are more than willing to comply with the project's norms
within the project's spaces. Trying to enforce the 'California cultural
standard' on not only someone's interactions with the project but their
entire life (which may be lived in a very different cultural setting) seems
very invasive and culturally exclusionary.
I'd be interested to know where you draw the line as to what behavior is
related to the project, or if you don't draw a line, why volunteers in China,
Russia, Poland etc should be expected to accept an entire political doctrine
over their life to contribute to a compiler toolchain.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
Ian Lance Taylor : > Patronizing or infantilizing anybody doesn't come into this at all. I am not even *remotely* persuaded of this. This whole attitude that if a woman is ever exposed to a man with less than perfect American upper-middle-class manners it's a calamity requiring intervention and mass shunning, that *reeks* of infantilizing women. > We want free software to succeed. Free software is more likely to > succeed if more people work on it. If you are a volunteer, as many > are, you can choose to spend your time on the project where you have > to short-stop unwelcome advances, where you are required to deal with > "men with poor social skills." Or you can choose to spend your time > on the project where people treat you with respect. Which one do you > choose? The one where your expected satisfaction is higher, with boorishness from autistic males factored in as one of the overheads. Don't try to tell me that's a deal-killer, I've known too many women who would laugh at you for that assumption. > Or perhaps you have a job that requires you to work on free software. > Now, if you work on a project where the people act like RMS, you are > being forced by your employer to work in a space where you face > unwelcome advances and men who have "trouble recognizing boundaries." > That's textbook hostile environment, and a set up for you to sue your > employer. So your employer will never ask anyone to work on a project > where people act like that--at least, they won't do it more than once. Here's what happens in the real world (and I'm not speculating, I was a BoD member of a tech startup at one time, stuff like this came up). You say "X is being a jerk - can I work on something else?" Your employer, rightly terrified of the next step, is not going to "force" you to do a damn thing. He's going to bend over backwards to accommodate you. > (Entirely separately, I don't get the slant of your whole e-mail. You > can put up with RMS despite the boorish behavior you describe. Great. > You're a saint. Why do you expect everyone else to be a saint? I'm no saint, I'm merely an adult who takes responsibility for my own choices when dealing with people who have minimal-brain-damage syndromes. OK, I have probably acquired a bit more tolerance for their quirks than average from long experience, but I don't believe I'm an extreme outlier that way. What I am pushing for is for everyone to recognize that *women are adults* - they have their own agency and are in general perfectly capable of treating an RMS-class jerk as at worst a minor annoyance. Behaving as though he's some sort of icky monster who should be shunned by all right-thinking people and taints everything he touches is ... just unbelievably disconnected from reality. Bizarre neo-Puritan virtue signaling of no help to anyone. If I needed more evidence that many Americans lead pampered, cossetted, hyper-insulated lives that require them to make up their own drama, this whole flap would be it. -- http://www.catb.org/~esr/";>Eric S. Raymond
A proposal for management of change
From the discussion, it seems that there is concern about some of the the technical directions imposed on gcc by the FSF. If we want to resolve the current crisis without causing a fatal split within the gcc community, we need a way at least to address those. Therefore, a proposal for a procedure for setting guidelines which may also deviate from the ones If such a deviation is deemed necessary by somebody, it is handed to the steering comittee, which puts it to the gcc mailing list as an officlal RFC. Going through the steering committee is a step for weeding out suggestions which are obviously frivolous or trivial. If, after discussion and possible modification, there is unanimous or near-unanimous consent, the RFC is approved or rejected. If there is significant division, it is put to a vote. Everybody who is listed in the MAINTAINERS file gets a vote, and the majority vote is binding if there is a majority of at least n votes (with n to be discussed). The steering committee then documents the new guideline. The whole thing should be restricted to technical matters, and I would envision this only happening rarely, like once or twice a year. Why this rather bureaucratic procedure? Because it gives a clear and documented mandate for a change, if it is supported by the majority of the developers. If anybody (like the FSF) takes exception to the change, it would be something to go up against. Comments?
