Re: A proposal for management of change
On Fri Apr 16, 2021 at 7:37 AM BST, Thomas Koenig via Gcc wrote:
> 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?
This seems like a very sensible proposal.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
Ian Lance Taylor via Gcc 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. Absolutely! This forum (barring the current discussion where, frankly, the dissent is not coming from people who are actually active contributors), does not usually have a problem. Nor is this isolated; I participate in two other forums where there are many excellent software engineers with good social and communication skills (and those that would not, perhaps, do this naturally have managed to adapt). The world has changed (for the better in my view) this is 2021, not 1971; it is not a passing fashion to treat each other with respect, but a steady progression that I’ve witnessed over my adult life. Perpetuating the stereotypical “excellent” engineer (this problem is not confined to software) as a beer-drinking male social misfit is a huge disservice to engineering everywhere. It is already a considerable leap for many engineers to post code for public review; it is essential (IMO) that review of code is carried out on a fair and technical basis without personal attack or harrassment (or unwelcome unrelated attention). “Grow a thicker skin” is an appalling advertising slogan. Iain
Re: removing toxic emailers
On Fri, 16 Apr 2021 at 05:59, Eric S. Raymond wrote: > 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. > > Im glad there are people like you on the project Eric, because you express exactly what a lot of people see - even if a minority of people chose to ignore it, To a lot of "non americans", the events on here appear as nothing more than a power grab by a small minority of developers, abusing their position and american corporate ideologies to enact change, ignoring any one who dares question or disagree unless they fit into a clique they have built (and want to maintain by ostracizing people they deem unworthy), brandishing them jerks, trolls, toxic and other childish names. Im glad there are a few devs that can see this, but it feels like they are stepping on egg shells (despite the rhetoric about how well the people in said clique can communicate on technical matters).
Re: removing toxic emailers
On Fri Apr 16, 2021 at 10:39 AM BST, Kalamatee via Gcc wrote:
> On Fri, 16 Apr 2021 at 05:59, Eric S. Raymond wrote:
>
> > 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.
> >
> >
> Im glad there are people like you on the project Eric, because you
> express
> exactly what a lot of people see - even if a minority of people chose to
> ignore it,
>
> To a lot of "non americans", the events on here appear as nothing more
> than
> a power grab by a small minority of developers, abusing their position
> and
> american corporate ideologies to enact change, ignoring any one who
> dares
> question or disagree unless they fit into a clique they have built (and
> want to maintain by ostracizing people they deem unworthy),
> brandishing them jerks, trolls, toxic and other childish names. Im glad
> there are a few devs that can see this, but it feels like they are
> stepping
> on egg shells (despite the rhetoric about how well the people in said
> clique can communicate on technical matters).
A lot of Americans see it too, just many are petrified of speaking out
against this new illiberal orthodoxy.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On 16.04.21 10:54, Iain Sandoe via Gcc wrote: This forum (barring the current discussion where, frankly, the dissent is not coming from people who are actually active contributors), Maybe I should have been less diplomatic :-) I dissent, strongly.
A suggestion for going forward from the RMS/FSF debate
Huge apologies for mis-sending this to gcc-patches, my email client makes suggestions when I attempt to send to a gcc list. :D The actual suggestion is at the end; skip straight to it if you wish. >Im glad there are people like you on the project Eric, because you express exactly what a lot of people see - even if a minority of people chose to ignore it, >To a lot of "non americans", the events on here appear as nothing more than a power grab by a small minority of developers, abusing their position and american corporate ideologies to enact change, ignoring any one who dares question or disagree unless they fit into a clique they have built (and want to maintain by ostracizing people they deem unworthy), brandishing them jerks, trolls, toxic and other childish names. Im glad there are a few devs that can see this, but it feels like they are stepping on egg shells (despite the rhetoric about how well the people in said clique can communicate on technical matters). That's a) incorrect b) beside some rather important points. The "small minority of developers" you speak of sure seems to consist of developers who are not in the minority considering how much they _actually contribute_ to the project. Some of them don't need to perform a "power grab"; they already have all the power fathomable, by virtue of being maintainers and active developers. This whole discussion, again, at least to me, boils down to two things, actually three: 1) is the technical leadership of RMS/GNU/FSF useful for the project? Is it beneficial, or harmful? 2) is the PR/public-face position of RMS/FSF useful for the project? Is it beneficial, or harmful? 3) Who should make decisions related to that? The developers and maintainers, or people who are neither of those, but are certainly vocal in these discussions? On the first part, other people have touched on it already, but the fear of a dreaded non-free software vendor co-opting GCC as a library to a non-free project has resulted in GCC being unsuitable to be used as a library in free software projects. This approach alone made sure that the meteoric rise of LLVM happened; there are recorded statements from LLVM developers trying to talk about this to RMS, and the answer, as they phrased it, "wasn't useful", because RMS decided that GCC shouldn't be a library to make it harder to use it in conjunction with non-free programs. Congratulations, it remains hard to use in conjunction with free programs, and everybody who wants to do something like that looks at LLVM first. RMS made a lofty attempt to promote copyleft software for such purposes, and failed miserably, leading us into a situation where such problems are not solved with copyleft software, but with LLVM instead. On the second part, we can discuss whether the reasons for various people not wanting RMS/FSF to be the PR department of GCC developers are sound, or whether we agree with them, until the cows come home. But that doesn't matter. Bad PR is bad PR, and it seems strikingly simple to consider trying a PR department that doesn't have the baggage of the previous one. And if you ask me, *that* should be a choice of the developers and maintainers, and them alone. It's their work; they should have a say in who and what the public face of the work is to the outside world. Whether their choice is made because they live a pampered and cosseted life is very much secondary. I don't have to agree with every viewpoint of the people who have suggested that RMS shouldn't lead this project, or that this project shouldn't necessarily be tied to FSF any more. I don't even need to "accept" it. I don't consider it something that needs my approval or acceptance, I'm not a maintainer or a major contributor. However, I consider it something that needs even LESS acceptance or approval of ESR or Mr. Dimech or various other people. I happen to have Write-After-Approval permission for this project. They don't. Because they're not members of this project, they don't contribute code to it. Finally, with regards to there existing a power grab or a sinister corporation plot to take GCC away from being "accountable to its community": 1) that's just pure horseshit. The people wanting to disassociate the project from RMS and/or FSF worked on GCC before their current employment, and will work on GCC after their current employment. There is no power grab, and there is no sinister corporation plot, and that wouldn't work anyway due to the license and due to how the project _actually works_. 2) the project isn't accountable that way today, anyway. That concern is pure fantasy. So, I have a moderate suggestion, and I will fairly entertain it being a bold suggestion for some people: A) Detach GCC from FSF (and RMS), have it be hosted on non-gnu sites, make it a project separate from FSF, other than B) Don't drop the copyright assignment requirement, at least not yet. C) Run in that mode for a while, and see what happens. This allows re-attac
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Friday, April 16, 2021 at 10:16 PM > From: "Ville Voutilainen via Gcc" > To: "GCC Development" > Subject: A suggestion for going forward from the RMS/FSF debate > > Huge apologies for mis-sending this to gcc-patches, > my email client makes suggestions when I attempt > to send to a gcc list. :D > > The actual suggestion is at the end; skip straight to it if you wish. > > >Im glad there are people like you on the project Eric, because you express > exactly what a lot of people see - even if a minority of people chose to > ignore it, > > >To a lot of "non americans", the events on here appear as nothing more than > a power grab by a small minority of developers, abusing their position and > american corporate ideologies to enact change, ignoring any one who dares > question or disagree unless they fit into a clique they have built (and > want to maintain by ostracizing people they deem unworthy), > brandishing them jerks, trolls, toxic and other childish names. Im glad > there are a few devs that can see this, but it feels like they are stepping > on egg shells (despite the rhetoric about how well the people in said > clique can communicate on technical matters). > > That's a) incorrect b) beside some rather important points. > > The "small minority of developers" you speak of sure > seems to consist of developers who are not in the minority > considering how much they _actually contribute_ to the project. Due to their being paid for the work. Have no doubt that if others were being paid, the contributions could likely drown the current contributors. Thus, the claim of a power grab is valid. > Some of them don't need to perform a "power grab"; they > already have all the power fathomable, by virtue of being maintainers > and active developers. > > This whole discussion, again, at least to me, boils down to two > things, actually three: It can also boil down about whether people want their work to form part of the Gnu Project or not!!! > 1) is the technical leadership of RMS/GNU/FSF useful for > the project? Is it beneficial, or harmful? > > 2) is the PR/public-face position of RMS/FSF useful for > the project? Is it beneficial, or harmful? > > 3) Who should make decisions related to that? The developers > and maintainers, or people who are neither of those, but > are certainly vocal in these discussions? > > On the first part, other people have touched on it already, > but the fear of a dreaded non-free software vendor co-opting > GCC as a library to a non-free project has resulted in GCC > being unsuitable to be used as a library in free software > projects. This approach alone made sure that the meteoric > rise of LLVM happened; there are recorded statements > from LLVM developers trying to talk about this to RMS, > and the answer, as they phrased it, "wasn't useful", because > RMS decided that GCC shouldn't be a library to make it > harder to use it in conjunction with non-free programs. > > Congratulations, it remains hard to use in conjunction > with free programs, and everybody who wants to do something > like that looks at LLVM first. RMS made a lofty attempt to > promote copyleft software for such purposes, and failed > miserably, leading us into a situation where such problems > are not solved with copyleft software, but with LLVM instead. > > On the second part, we can discuss whether the reasons > for various people not wanting RMS/FSF to be the PR department > of GCC developers are sound, or whether we agree with them, > until the cows come home. > > But that doesn't matter. Bad PR is bad PR, and it seems strikingly > simple to consider trying a PR department that doesn't have > the baggage of the previous one. > > And if you ask me, *that* should be a choice of the developers > and maintainers, and them alone. It's their work; they should > have a say in who and what the public face of the work is > to the outside world. Whether their choice is made because > they live a pampered and cosseted life is very much secondary. > > I don't have to agree with every viewpoint of the people who > have suggested that RMS shouldn't lead this project, or that > this project shouldn't necessarily be tied to FSF any more. > I don't even need to "accept" it. I don't consider it something > that needs my approval or acceptance, I'm not a maintainer > or a major contributor. > > However, I consider it something that needs even LESS > acceptance or approval of ESR or Mr. Dimech or various > other people. I happen to have Write-After-Approval permission > for this project. They don't. Because they're not members > of this project, they don't contribute code to it. > > Finally, with regards to there existing a power grab or a sinister > corporation plot to take GCC away from being "accountable > to its community": > > 1) that's just pure horseshit. The people wanting to disassociate > the project from RMS and/or FSF worked on GCC before > their current employment, and will work on GCC after their > c
Fsf decision
Hello, I somehow got the feeling the truth and reason have won although there were many odds against them. https://www.fsf.org/news/statement-of-fsf-board-on-election-of-richard-stallman Big thanks and congratulations to fsf board and rms himself. Wonder what wokistanis gonna do now. Wonder whether there will be some action against organizers of open letter with no opt out option a hutzpah plus supporters of initial motion. I honestly hope so. Best regards, Pk
Re: Fsf decision
This is not new, this was what his FSF put out four or five days ago that that a lot of people found unacceptable. Get a load of this, emphasis mine: > RMS acknowledges that he has made mistakes. He has sincere regrets, > **especially at how anger toward him personally has negatively impacted the > reputation**and mission of FSF. While *his personal style remains troubling > for some*, a majority of the board feel his behavior has moderated and > believe that **his thinking strengthens the work** of the FSF in pursuit of > its mission. Aaron
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > The "small minority of developers" you speak of sure > > seems to consist of developers who are not in the minority > > considering how much they _actually contribute_ to the project. > > Due to their being paid for the work. Have no doubt that if others > were being paid, the contributions could likely drown the current > contributors. Thus, the claim of a power grab is valid. How convenient to make that claim and just bypass what's said in the next bit: > > > Some of them don't need to perform a "power grab"; they > > already have all the power fathomable, by virtue of being maintainers > > and active developers. I very much doubt your lofty hypothesis that if "others" were being paid, the contributions would "likely drown" the current contributors. Especially when we're talking about people who have submitted pretty close to ZERO patches to GCC. You can give a claim that a person $foo would contribute if being paid to do it. I'll buy that claim if you're talking about people like Nathan Sidwell and Iain Sandoe from the time before they became active contributors again, now that they've been hired to do that. I will not buy that claim about people who haven't been GCC contributors before. > > This whole discussion, again, at least to me, boils down to two > > things, actually three: > > It can also boil down about whether people want their work to form part > of the Gnu Project or not!!! Oh, sure it can. So perhaps we should do something along the lines of what Thomas outlined: - ask the maintainers what they want to do - then do that
Re: A suggestion for going forward from the RMS/FSF debate
> Due to their being paid for the work. Have no doubt that if others > were being paid, the contributions could likely drown the current > contributors. Thus, the claim of a power grab is valid. This is a non-sequitur.
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Saturday, April 17, 2021 at 1:03 AM > From: "Ville Voutilainen" > To: "Christopher Dimech" > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > The "small minority of developers" you speak of sure > > > seems to consist of developers who are not in the minority > > > considering how much they _actually contribute_ to the project. > > > > Due to their being paid for the work. Have no doubt that if others > > were being paid, the contributions could likely drown the current > > contributors. Thus, the claim of a power grab is valid. > > How convenient to make that claim and just bypass what's said in the next bit: > > > > > > Some of them don't need to perform a "power grab"; they > > > already have all the power fathomable, by virtue of being maintainers > > > and active developers. > > I very much doubt your lofty hypothesis that if "others" were being paid, the > contributions would "likely drown" the current contributors. Especially > when we're talking about people who have submitted pretty close to ZERO > patches to GCC. You can give a claim that a person $foo would contribute > if being paid to do it. I'll buy that claim if you're talking about people > like > Nathan Sidwell and Iain Sandoe from the time before they became active > contributors again, now that they've been hired to do that. I will not > buy that claim about people who haven't been GCC contributors before. Many do not contribute because they do not have time, resources or support. Additionally, maintainers have always been aware that being a Gnu Maintainer meant that coordinating activities in the GNU Project were on behalf of RMS. > > > This whole discussion, again, at least to me, boils down to two > > > things, actually three: > > > > It can also boil down about whether people want their work to form part > > of the Gnu Project or not!!! > > Oh, sure it can. So perhaps we should do something along the lines of what > Thomas outlined: > > - ask the maintainers what they want to do > - then do that >
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, 16 Apr 2021 at 16:22, Christopher Dimech wrote: > Many do not contribute because they do not have time, resources or support. Yes? And? Even if GCC detaches itself from FSF, those who can contribute will continue to contribute. And those who talk about contributing but don't contribute will likely continue talking and not contributing. > Additionally, maintainers have always been aware that being a Gnu Maintainer > meant that coordinating activities in the GNU Project were on behalf of RMS. Fine. And if those maintainers no longer wish to be coordinating activities on behalf of RMS, they should make that decision and run with it. Or make a decision not to.
Re: Fsf decision
Hello, Sorry for lags but im across the pond. Thanks for bearing with me. Spot on emphasis. Yes agree with you fully BOTH rms and his opponents should watch the tongues a little more possibly if goodwilled towards fsf to make my point weakest. Albeit the weight of guilt of theirs looks slightly bigger than his imho but i may be biased. Id say if i was to advice if anyone some all half whatever are weak in discussions or get triggered good style would be non discussion of politics like we treat religion. On other hand i dream of and will die fighting fir it albeit out of fsf and gnu etc fir a world where anyone and everyone can sit diwn calmly exchange the ideas learn from each other where can be and close the topic. Although my understanding of reality is reality is not ideal. Cheers, Pk pt., 16.04.2021, 14:54 użytkownik Aaron Gyes napisał: > This is not new, this was what his FSF put out four or five days ago that > that a lot of people found unacceptable. > > Get a load of this, emphasis mine: > > > RMS acknowledges that he has made mistakes. He has sincere regrets, > **especially at how anger toward him personally has negatively impacted the > reputation**and mission of FSF. While *his personal style remains troubling > for some*, a majority of the board feel his behavior has moderated and > believe that **his thinking strengthens the work** of the FSF in pursuit of > its mission. > > Aaron >
Re: removing toxic emailers
Kalamatee wrote: On Fri, 16 Apr 2021 at 11:05, Kalamatee wrote: On Fri, 16 Apr 2021 at 10:42, Iain Sandoe via Gcc wrote: It is already a considerable leap for many engineers to post code for public review; it is essential (IMO) that review of code is carried out on a fair and technical basis without personal attack or harrassment (or unwelcome unrelated attention). “Grow a thicker skin” is an appalling advertising slogan. I just want to clarify - i am not posting these things to be a "troll" or awkward, but as someone that uses "your" toolchain, because we depend on it to build "our" operating system, and the actions (and inactions!) on this list are a bit disturbing when taken in context of the whole thread. I have a massive amount of respect for the people involved in developing gcc (which is far beyond my capabilities, of just developing patches to support the OS I contribute to), but I still have a vested interest in what happens because of the actions here - as do many corporate, commercial and academic institutes that invest money and time on "your" toolchain - so to exclude everyone except a group of people who have built a rapport in discussions that affect us feels a bit offensive to be honest. I am saddened by the prospect that there might be no consensus available here. This thread has become so intertwined with different discussions it seems that people are mistaking who has said what. For the record (on-one needs to take my word for it, the list is archived). * I am not being paid to work on GCC, I have been once (some time ago now) - however almost all my input is voluntary over the 12 years or so since I made my first commit. * I have not: expressed any opinion re RMS expressed any opinion re FSF or the desirability of a fork said that people need to agree (technically or procedurally) required people to have rapport (I doubt that there is as much as folks think). I have said: if people are not willing to resolve differences in a civilised manner, that perhaps indicates that they have no interest in resolving anything. This does not seem contrary to general GNU guidelines either: https://www.gnu.org/philosophy/kind-communication.en.html I am not willing to spend my spare time working in a hostile environment. well, I did post in good faith, Iain
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Saturday, April 17, 2021 at 1:03 AM > From: "Ville Voutilainen" > To: "Christopher Dimech" > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > The "small minority of developers" you speak of sure > > > seems to consist of developers who are not in the minority > > > considering how much they _actually contribute_ to the project. > > > > Due to their being paid for the work. Have no doubt that if others > > were being paid, the contributions could likely drown the current > > contributors. Thus, the claim of a power grab is valid. > > How convenient to make that claim and just bypass what's said in the next bit: > > > > > > Some of them don't need to perform a "power grab"; they > > > already have all the power fathomable, by virtue of being maintainers > > > and active developers. > > I very much doubt your lofty hypothesis that if "others" were being paid, the > contributions would "likely drown" the current contributors. Especially > when we're talking about people who have submitted pretty close to ZERO > patches to GCC. You can give a claim that a person $foo would contribute > if being paid to do it. I'll buy that claim if you're talking about people > like > Nathan Sidwell and Iain Sandoe from the time before they became active > contributors again, now that they've been hired to do that. I will not > buy that claim about people who haven't been GCC contributors before. There are many users of gcc who are more qualified to know what is needed in gcc, than developers. That does not mean than I want to diminish their authority for gcc. But that authority was still conferred to them by the the Gnu Project - which demands responsibility to carry out the assigned tasks to the best of their ability, not to excoriate their obligation towards the project itself. The ultimate authority is the final responsibility of the Gnu Project, not only that of gcc. > > > This whole discussion, again, at least to me, boils down to two > > > things, actually three: > > > > It can also boil down about whether people want their work to form part > > of the Gnu Project or not!!! > > Oh, sure it can. So perhaps we should do something along the lines of what > Thomas outlined: > > - ask the maintainers what they want to do > - then do that >
Re: removing toxic emailers
> Sent: Saturday, April 17, 2021 at 2:42 AM > From: "Iain Sandoe via Gcc" > To: "GCC Development" > Cc: "Thomas Koenig" > Subject: Re: removing toxic emailers > > Kalamatee wrote: > > On Fri, 16 Apr 2021 at 11:05, Kalamatee wrote: > > > > > > On Fri, 16 Apr 2021 at 10:42, Iain Sandoe via Gcc wrote: > > > > It is already a considerable leap for many engineers to post code for > > public > > review; it is essential (IMO) that review of code is carried out on a fair > > and > > technical basis without personal attack or harrassment (or unwelcome > > unrelated > > attention). > > > > “Grow a thicker skin” is an appalling advertising slogan. > > > > I just want to clarify - i am not posting these things to be a "troll" > > or awkward, but as someone that uses "your" toolchain, because we depend > > on it to build "our" operating system, and the actions (and inactions!) > > on this list are a bit disturbing when taken in context of the whole > > thread. > > > > I have a massive amount of respect for the people involved in developing > > gcc (which is far beyond my capabilities, of just developing patches to > > support the OS I contribute to), but I still have a vested interest in > > what happens because of the actions here - as do many corporate, > > commercial and academic institutes that invest money and time on "your" > > toolchain - so to exclude everyone except a group of people who have > > built a rapport in discussions that affect us feels a bit offensive to be > > honest. > > I am saddened by the prospect that there might be no consensus available > here. > > > > This thread has become so intertwined with different discussions it seems > that people are mistaking who has said what. > > For the record (on-one needs to take my word for it, the list is archived). > > * I am not being paid to work on GCC, I have been once (some time ago now) > - however almost all my input is voluntary over the 12 years or so since I > made my first commit. > > * I have not: > >expressed any opinion re RMS >expressed any opinion re FSF or the desirability of a fork > >said that people need to agree (technically or procedurally) >required people to have rapport (I doubt that there is as much as folks > think). > > I have said: > >if people are not willing to resolve differences in a civilised manner, > that perhaps indicates that they have no interest in resolving anything. > This does not seem contrary to general GNU guidelines either: > https://www.gnu.org/philosophy/kind-communication.en.html It has been occurring to me that Nathan-and-Associates do not want a fork. This has became problematic because they do not seem to be able to successfully run a Gnu Package because they would have to deal with RMS. Although I have not campaigned against their continuation as maintainers, they lobbied for my removal. And that's definitely not on! >I am not willing to spend my spare time working in a hostile environment. > > well, I did post in good faith, > Iain > >
Re: A suggestion for going forward from the RMS/FSF debate
Hello world, realising that my e-mails may have done more harm than good, I will now unsubscribe from the gcc mailing list, so please don't expect a reply unless you copy me in. Best regards Thomas
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc wrote: > > Sent: Saturday, April 17, 2021 at 1:03 AM > > From: "Ville Voutilainen" > > To: "Christopher Dimech" > > Cc: "GCC Development" > > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > > The "small minority of developers" you speak of sure > > > > seems to consist of developers who are not in the minority > > > > considering how much they _actually contribute_ to the project. > > > > > > Due to their being paid for the work. Have no doubt that if others > > > were being paid, the contributions could likely drown the current > > > contributors. Thus, the claim of a power grab is valid. > > > > How convenient to make that claim and just bypass what's said in the next > > bit: > > > > > > > > > Some of them don't need to perform a "power grab"; they > > > > already have all the power fathomable, by virtue of being maintainers > > > > and active developers. > > > > I very much doubt your lofty hypothesis that if "others" were being paid, > > the > > contributions would "likely drown" the current contributors. Especially > > when we're talking about people who have submitted pretty close to ZERO > > patches to GCC. You can give a claim that a person $foo would contribute > > if being paid to do it. I'll buy that claim if you're talking about people > > like > > Nathan Sidwell and Iain Sandoe from the time before they became active > > contributors again, now that they've been hired to do that. I will not > > buy that claim about people who haven't been GCC contributors before. > > There are many users of gcc who are more qualified to know what is needed > in gcc, than developers. That does not mean than I want to diminish their > authority for gcc. But that authority was still conferred to them by the > the Gnu Project - which demands responsibility to carry out the assigned > tasks to the best of their ability, not to excoriate their obligation towards > the project itself. > > The ultimate authority is the final responsibility of the Gnu Project, > not only that of gcc. Free Software means there is no ultimate authority. In Free Software, leadership of the development process is by the "consent of the governed". If there is sufficient objection to the existing leadership, developers can change it, either by negotiation for changes with the current leadership or by forking. The EGCS fork happened because a critical mass of developers gave up on the GNU GCC2 leadership model. The reconciliation happened because GNU agreed to accept the EGCS development model as GNU GCC. I hope to resolve the current crisis by leadership adjustments something along the lines of Ville's proposal, rather than forking. Jason
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 9:09 PM Eric S. Raymond wrote: > > 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. I just don't see it. Maybe occasionally. But in general you see someone acting badly, and you think "I don't want to associate with that person." Preferring to work with people who treat others decently is not about infantilizing others. > > 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. I'm not saying either option is a deal killer, I'm saying you have to make a choice. And more generally a project has to make a choice. > > 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. Yes. > 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. OK, you got it. Not sure it's relevant to what I'm saying, though. Ian
Re: A suggestion for going forward from the RMS/FSF debate
From reading most of this thread, it is clear to me that - The authority of the FSF, GNU and RMS over GCC is and has been a fiction for decades, - This fiction has been erased from the official web page of the project, - It would be usefull to clarify with the FSF and GNU what the actual relations are, - This can certainly be done in a polite way without all sorts of rant, and arguments with no relation with Free Software, in particular attacks ad persona. The power is and has always been in the hands of the people doing the job (the developpers/maintainers). But those who have the power would be wise to pay attention to the opinions of the many afficionados of GCC, GNU and Free Software in general, even those who aren't contributors. These people aren't trolls; they speak up because they are concerned about the project. -- Didier
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 9:08 PM Frosku wrote: > > 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 do live in California, but I don't know what the "California cultural standard" is. It's a big place, and it's full of people who behave in all kinds of different ways. Harvey Weinstein and brogrammer culture are California cultures. You presumably have something in mind, but I'm not sure it's a real thing. > 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. How did we get to accepting an entire political doctrine? What I have in mind is treating people with respect. For example, I'm involved with the Go programming language. The Go community has a code of conduct: https://golang.org/conduct. The key elements are: - Be friendly and welcoming - Be patient Remember that people have varying communication styles and that not everyone is using their native language. (Meaning and tone can be lost in translation.) - Be thoughtful Productive communication requires effort. Think about how your words will be interpreted. Remember that sometimes it is best to refrain entirely from commenting. - Be respectful In particular, respect differences of opinion. - Be charitable Interpret the arguments of others in good faith, do not seek to disagree. When we do disagree, try to understand why. Avoid destructive behavior: Derailing: stay on topic; if you want to talk about something else, start a new conversation. Unconstructive criticism: don't merely decry the current state of affairs; offer—or at least solicit—suggestions as to how things may be improved. Snarking (pithy, unproductive, sniping comments) Discussing potentially offensive or sensitive issues; this all too often leads to unnecessary conflict. Microaggressions: brief and commonplace verbal, behavioral and environmental indignities that communicate hostile, derogatory or negative slights and insults to a person or group. That is what I would aim for. And in general that is how the GCC community behaves. I don't know whether that is "California culture" or not. And I have to note that I have seen very few people here saying "RMS must never participate in GCC in any way." What I see most people saying is "RMS should not be in a position of leading the GCC project and telling people what to do." Ian
Re: A suggestion for going forward from the RMS/FSF debate
> The authority of the FSF, GNU and RMS over GCC is and has been a > fiction for decades, For the most part, I agree. > It would be usefull to clarify with the FSF and GNU what the > actual relations are, Why? What would that gain? I go back to my analogy of the British Queen. What would be gained by "clarifying" that if she actually intervenes non-trivially in the government of any Commonwealth nation, she'd lose that power?
Re: A suggestion for going forward from the RMS/FSF debate
On 4/16/2021 9:57 AM, Thomas Koenig via Gcc wrote: Hello world, realising that my e-mails may have done more harm than good, I will now unsubscribe from the gcc mailing list, so please don't expect a reply unless you copy me in. I don't think your emails have done any harm. I find them quite valuable, so I'm sad to see you dropping yourself from the gcc@ list. jeff
Re: removing toxic emailers
On Thu, Apr 15, 2021, 23:42 Iain Sandoe via Gcc wrote: > it is essential (IMO) that review of code is carried out on a fair and > technical basis without personal attack or harrassment (or > unwelcome unrelated attention). > Is this not the case on gcc-patches? >
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, Apr 16, 2021 at 7:23 AM Ville Voutilainen via Gcc wrote: > On the first part, other people have touched on it already, > but the fear of a dreaded non-free software vendor co-opting > GCC as a library to a non-free project has resulted in GCC > being unsuitable to be used as a library in free software > projects. This approach alone made sure that the meteoric > rise of LLVM happened; there are recorded statements > from LLVM developers trying to talk about this to RMS, > and the answer, as they phrased it, "wasn't useful", because > RMS decided that GCC shouldn't be a library to make it > harder to use it in conjunction with non-free programs. > > Congratulations, it remains hard to use in conjunction > with free programs, and everybody who wants to do something > like that looks at LLVM first. RMS made a lofty attempt to > promote copyleft software for such purposes, and failed > miserably, leading us into a situation where such problems > are not solved with copyleft software, but with LLVM instead. I was under the (likely incorrect, please enlighten me) impression that the meteoric rise of LLVM had more to do with the license allowing corporate contributors to ship derived works in binary form without sharing proprietary code. Intel, IBM, nVidia, etc. are migrating towards LLVM for this purpose. To do so using GCC would (I believe; again, please correct me) require that they share more source code than they would have to under LLVM. This licensing model makes working on LLVM more attractive to companies that wish to keep proprietary code hidden, and thus LLVM garners a lot of corporate backing. It seems to me that technical differences (easier porting, or early claims of better diagnostics, for instance) and culture differences (let's just say that LLVM developers are more friendly, although I've never encountered a mean GCC developer) are not the driving force behind such strong support. As usual in the world, follow the money. If the idea is that GCC-as-a-Library would enable Intel, for example, to use GCC for their ICX OneAPI compiler the way they are now using LLVM, with significant portions of it hidden from the user, it seems to me that not supporting this is a very consistent GNU view. Allowing derived works that don't publish the full source code seems to be against the very spirit of GNU. If the GCC project opts to distance itself from various three letter acronyms, as a user, I have to wonder what that means in the future regarding the strict adherence to software freedoms that GCC has had for a long time now. I don't think I would suggest that there would be an immediate knee jerk reaction to change everything. Instead, it seems that https://en.wikipedia.org/wiki/Creeping_normality would take place to slowly change the "Freedom first" ideology over time. Maybe I'm jaded by the recent changes to CentOS, where RedHat applied a Microsoft tactic to embrace, extend, and extinguish it (at least in the form we previously knew). That took about ten years, but I can easily see how the same thing could happen over a long period of time to GCC (note that often when this has happened in history, including outside of the computing world, it was difficult or impossible to predict how it could end poorly. Padme's "thunderous applause" cheats, in that we saw the sequels first :) ) It would be good, therefore, to address upfront how the software freedoms of GCC users would be as consistently guaranteed in the future as they are now. Would a future GCC be committed to universally blocking any hypothetical positive technical improvement that also reduced user freedom?
Re: A suggestion for going forward from the RMS/FSF debate
> On Apr 16, 2021, at 2:41 PM, NightStrike via Gcc wrote: > >> ... > > I was under the (likely incorrect, please enlighten me) impression > that the meteoric rise of LLVM had more to do with the license > allowing corporate contributors to ship derived works in binary form > without sharing proprietary code. My impression is a variation on this: that LLVM is in substantial part motivated by a desire to avoid GPL V3. And that there wasn't such a push when GPL V2 was the version in general use. paul
gcc-9-20210416 is now available
Snapshot gcc-9-20210416 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210416/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision c09606e71d71320e4a0663fe5f825359ba92ce16 You'll find: gcc-9-20210416.tar.xzComplete GCC SHA256=433bf39412d078f0679219cf4441c407ef836ad03e36831a12188f8d269984d8 SHA1=fbba58c17ec5591a93ff474bb8a574cb943e6ce6 Diffs from 9-20210409 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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 Fri Apr 16, 2021 at 5:28 PM BST, Ian Lance Taylor wrote:
> On Thu, Apr 15, 2021 at 9:08 PM Frosku wrote:
> >
> > 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 do live in California, but I don't know what the "California
> cultural standard" is. It's a big place, and it's full of people who
> behave in all kinds of different ways. Harvey Weinstein and
> brogrammer culture are California cultures. You presumably have
> something in mind, but I'm not sure it's a real thing.
There isn't a real name for any given culture because culture is such an organic
thing. When I think of codes of conduct I come back to i.e. Linus giving people
a hard time in code reviews, or Coraline Ada Ehmke's critiques of meritocracy.
Neither of these beliefs about what culture should be (Linus' or Coraline's) are
objectively right or objectively wrong, but both are likely to attract different
people, and result in different outcomes.
When I refer to a 'California cultural standard', that's not prescriptive. It's
just a reference to the fact that a *lot* of the SC live in California, and any
culture prescribed by the steering committee will be overly influenced by that
commonality. You will have ideas about what is welcoming, what is polite, etc
which are shaped by your upbringing just as I or anyone else does. These are
not objective truths, or internationally accepted as such.
> > 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.
>
> How did we get to accepting an entire political doctrine?
>
> What I have in mind is treating people with respect. For example, I'm
> involved with the Go programming language. The Go community has a
> code of conduct: https://golang.org/conduct. The key elements are:
>
> - Be friendly and welcoming
> - Be patient
> Remember that people have varying communication styles and that not
> everyone is using their native language. (Meaning and tone can be lost
> in translation.)
> - Be thoughtful
> Productive communication requires effort. Think about how your words
> will be interpreted.
> Remember that sometimes it is best to refrain entirely from commenting.
> - Be respectful
> In particular, respect differences of opinion.
> - Be charitable
> Interpret the arguments of others in good faith, do not seek to
> disagree.
> When we do disagree, try to understand why.
>
> Avoid destructive behavior:
>
> Derailing: stay on topic; if you want to talk about something else,
> start a new conversation.
> Unconstructive criticism: don't merely decry the current state of
> affairs; offer—or at least solicit—suggestions as to how things may
> be
> improved.
> Snarking (pithy, unproductive, sniping comments)
> Discussing potentially offensive or sensitive issues; this all too
> often leads to unnecessary conflict.
> Microaggressions: brief and commonplace verbal, behavioral and
> environmental indignities that communicate hostile, derogatory or
> negative slights and insults to a person or group.
I certainly prefer it to the Contributor Covenant, however the last
point ('microaggressions') is an example of 'California culture'. In
most of the world, we do not have any such concept. The examples I've
seen online for what counts as a microaggression include asking questions
like "where are you from?"
I'm assuming this is considered offensive because there's a trend of using
it to imply that someone "isn't welcome" in the local area, but in most of
the world this isn't considered an offensive question. As someone who
spends the vast majority of my time in countries that aren't my birthplace,
it's one of the questions I hear the most.
I'm not sure that most of us who live outside of cultures where "micro-
-aggressions" are a commonly referenced 'thing' would know if we're making
one or just being friendly. As an aside, would this be applied to
communication in GCC spaces or to all off-list communications i.e. Twitter
/ Weibo postings, e-mails, things said at unrelated conferences?
> And I have to note that I have seen very few people here saying "RMS
> must never participate in GCC in any way." What I see most people
> saying is "RMS should not be in a position of leading the GCC project
> and telling people what to do."
My concern here is that if not RMS/GNU -- an institution which most free
software user
Re: removing toxic emailers
> Sent: Saturday, April 17, 2021 at 11:15 AM > From: "Frosku" > To: "Ian Lance Taylor" > Cc: "GCC Development" > Subject: Re: removing toxic emailers > > On Fri Apr 16, 2021 at 5:28 PM BST, Ian Lance Taylor wrote: > > On Thu, Apr 15, 2021 at 9:08 PM Frosku wrote: > > > > > > 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 do live in California, but I don't know what the "California > > cultural standard" is. It's a big place, and it's full of people who > > behave in all kinds of different ways. Harvey Weinstein and > > brogrammer culture are California cultures. You presumably have > > something in mind, but I'm not sure it's a real thing. > > There isn't a real name for any given culture because culture is such an > organic > thing. When I think of codes of conduct I come back to i.e. Linus giving > people > a hard time in code reviews, or Coraline Ada Ehmke's critiques of meritocracy. > Neither of these beliefs about what culture should be (Linus' or Coraline's) > are > objectively right or objectively wrong, but both are likely to attract > different > people, and result in different outcomes. We will certainly have to adapt to the recognition that the human race is in great danger because of our politics going crazy and nationalism being a serious treat. Our world must turn itself into a new set of people that is unlike the generation that brought us in free software - just one corner of the western world. In 2016, Cosmologist Stephen Hawking warned us to stop reaching out to aliens before it's too late. His assessment was that distant alien civilisations might view us as inferior, weak, and perfect to conquer. We barely averted nuclear annihilation in the later half of last century. The problem is that we have not adapted ourselves to control all the power we already have. Science and technology has empowered us too much. After destroying much of the vegetal and animal species on Earth, we have started destroying ourselves, like other civilisations have destroyed themselves in the past. But this time, the collapse may be global. Good luck with death! > When I refer to a 'California cultural standard', that's not prescriptive. > It's > just a reference to the fact that a *lot* of the SC live in California, and > any > culture prescribed by the steering committee will be overly influenced by that > commonality. You will have ideas about what is welcoming, what is polite, etc > which are shaped by your upbringing just as I or anyone else does. These are > not objective truths, or internationally accepted as such. > > > > 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. > > > > How did we get to accepting an entire political doctrine? > > > > What I have in mind is treating people with respect. For example, I'm > > involved with the Go programming language. The Go community has a > > code of conduct: https://golang.org/conduct. The key elements are: > > > > - Be friendly and welcoming > > - Be patient > > Remember that people have varying communication styles and that not > > everyone is using their native language. (Meaning and tone can be lost > > in translation.) > > - Be thoughtful > > Productive communication requires effort. Think about how your words > > will be interpreted. > > Remember that sometimes it is best to refrain entirely from commenting. > > - Be respectful > > In particular, respect differences of opinion. > > - Be charitable > > Interpret the arguments of others in good faith, do not seek to > > disagree. > > When we do disagree, try to understand why. > > > > Avoid destructive behavior: > > > > Derailing: stay on topic; if you want to talk about something else, > > start a new conversation. > > Unconstructive criticism: don't merely decry the current state of > > affairs; offer—or at least solicit—suggestions as to how things may > > be > > improved. > > Snarking (pithy, unproductive, sniping comments) > > Discussing potentially offensive or sensitive issues; this all too > > often leads to unnecessary conflict. > > Microaggressions: brief and commonplace verbal, behavioral and > > environmental indignities that communicate hostile, derogatory or > > negative slights and insults to a pe
Re: removing toxic emailers
On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote: > > When I refer to a 'California cultural standard', that's not prescriptive. > It's > just a reference to the fact that a *lot* of the SC live in California, and > any > culture prescribed by the steering committee will be overly influenced by that > commonality. To the best of my knowledge, 2 of the 13 members of the GCC steering committee live in California. Ian
Re: removing toxic emailers
On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote:
> On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote:
> >
> > When I refer to a 'California cultural standard', that's not prescriptive.
> > It's
> > just a reference to the fact that a *lot* of the SC live in California, and
> > any
> > culture prescribed by the steering committee will be overly influenced by
> > that
> > commonality.
>
> To the best of my knowledge, 2 of the 13 members of the GCC steering
> committee live in California.
>
> Ian
And the rest of the west coast United States / New England?
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Fri, Apr 16, 2021 at 9:56 PM Frosku wrote:
>
> On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote:
> > On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote:
> > >
> > > When I refer to a 'California cultural standard', that's not
> > > prescriptive. It's
> > > just a reference to the fact that a *lot* of the SC live in California,
> > > and any
> > > culture prescribed by the steering committee will be overly influenced by
> > > that
> > > commonality.
> >
> > To the best of my knowledge, 2 of the 13 members of the GCC steering
> > committee live in California.
> >
> > Ian
>
> And the rest of the west coast United States / New England?
I count 5 which are not in the United States or Canada.
Thanks,
Andrew Pinski
>
> >>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On 4/16/2021 10:08 PM, Frosku wrote: On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote: On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote: When I refer to a 'California cultural standard', that's not prescriptive. It's just a reference to the fact that a *lot* of the SC live in California, and any culture prescribed by the steering committee will be overly influenced by that commonality. To the best of my knowledge, 2 of the 13 members of the GCC steering committee live in California. Ian And the rest of the west coast United States / New England? I'm not aware of anywhere in the US that is a monoculture in the way you seem to be implying. And if you really believe there are those kinds of monocultures , then you're showing a high degree of ignorance. FTR, I've never resided on the west coast of the US or in the traditionally defined New England states. Jeff
