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
Re: removing toxic emailers
I think (if it matters to anyone what I think) that would be great to see as long as there was some social/cultural incentive to not elect "gatekeeper" types. I see alot of folks with very thin skin misusing the authority they are trusted with in open source communities, it's just never over any of these socially charged reasons that get communities so hyped up so things just get weird for a while when it happens. -C On Wed, 2021-04-14 at 20:13 -0400, Paul Koning via Gcc wrote: > > On Apr 14, 2021, at 5:38 PM, Ian Lance Taylor > > wrote: > > > > On Wed, Apr 14, 2021 at 1:49 PM Paul Koning > > wrote: > > > > ... > > > > > > This is why I asked the question "who decides?" Given a > > > disagreement in which the proposed remedy is to ostracise a > > > participant, it is necessary to inquire for what reason this > > > should be done (and, perhaps, who is pushing for it to be > > > done). My suggestion is that this judgment can be made by the > > > community (via secret ballot), unless it is decided to delegate > > > that power to a smaller body, considered as trustees, or whatever > > > you choose to call them. > > > > Personally, I think that voting is unworkable in practice. I think > > decisions can be reasonably delegated to a small group of trusted > > people. A fairly common name for that group is "moderators". It > > might be appropriate to use voting of some sort when selecting > > moderators. > > Yes, that seems reasonable. I think the NetBSD project is an example > of this, where the membership votes for the trustees, and the > trustees are responsible for a number of project aspects including > correcting bad behavior such as we're discussing here. > > The SC was mentioned earlier in this thread, though that's not quite > so natural given how that is appointed. > > paul >
Re: GCC association with the FSF
That will never make it appropriate. I would encourage you to reflect more carefully on the meaning of the words you are reading and using. These arguments are paper thin, and full of lofty rhetoric; none of them will expand the expectation of anyone here to include integrating their poltical beliefs into the GCC project roadmap beyond its technical and licensing goals. I would encourage anyone reading this to start treating this discussion as off-topic disruption for the GCC SC. -C On Mon, 2021-04-12 at 17:22 -0400, Nathan Sidwell wrote: > On 4/11/21 9:34 PM, Chris Punches via Gcc wrote: > > > It is not appropriate to discuss the removal of someone based on > > innuendo, provenly false smearing, and other types of political > > maneuvering at the behest of corporations desiring the destruction > > of > > the very projects they are sponsoring. > > Good job that's not what is happening then. > > > It is not appropriate to even suggest to blackmail sponsor or non- > > sponsor organizations by cutting ties with them to force someone > > that a > > couple corporates in your group don't like out of their > > organization. > > I call on those of you who argued this to restore credibility and > > integrity to this discussion. > > People, and companies can chose to support whatever organizations > they desire, > and they can chose to withdraw such support. For what ever reasons > they may have. > > nathan > >
Re: GCC association with the FSF
Hello, I've been reading quietly on how the GCC SC handles this and generally only lurk here so that I can stay informed on GCC changes. I am nobody you would probably care about, but, maybe I will be one day. No one ever really knows. I thought you'd like to know what "nobody" thinks, because, if I am paying enough attention to know that some here are not, perhaps people who are not "nobody" will have similar observations. It is not appropriate to discuss the removal of someone based on innuendo, provenly false smearing, and other types of political maneuvering at the behest of corporations desiring the destruction of the very projects they are sponsoring. It is not appropriate to even suggest to blackmail sponsor or non- sponsor organizations by cutting ties with them to force someone that a couple corporates in your group don't like out of their organization. I call on those of you who argued this to restore credibility and integrity to this discussion. This kind of thinking has defaced this project. What are you thinking? We don't care about your political views. We don't care about GCC's participation in activism-- in fact, many would view it as a marker of instability of the project. We care about the stable maintenance of GCC into perpetuity. No one who cares about these projects wants these kinds of politics driving such a technical and fundamental project. You have been infected. Please restore the compasses and carry on. I salute you, -C On Sun, 2021-04-11 at 21:03 -0400, David Edelsohn via Gcc wrote: > On Sun, Apr 11, 2021 at 8:40 PM Ian Lance Taylor via Gcc > wrote: > > On Sat, Apr 10, 2021 at 4:36 AM Pankaj Jangid < > > pan...@codeisgreat.org> wrote: > > > I think, it would be great help if someone can document what the > > > SC > > > does. > > > > I don't know whether anybody actually tried to answer this. > > > > The main job of the GCC steering committee is to confirm GCC > > maintainers: the people who have the right to approve changes to > > specific parts of GCC, and the people who have the right to make > > changes to specific parts of GCC without requiring approval from > > anybody else. These people are listed in the MAINTAINERS file in > > the > > gcc repository (currently > > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=MAINTAINERS;h=db25583b37b917102b001c0025d90ee0bc12800f;hb=HEAD), > > from the start of the file down to the list of "Write After > > Approval" > > people. > > > > A secondary job of the GCC steering committee is to approve new > > additions to GCC that are not under the GPL for one reason or > > another. > > This happens rarely. > > > > A tertiary job of the GCC steering committee is to decide disputes > > between maintainers that the maintainers are unable to resolve. I > > can't recall this ever happening. > > > > The GCC steering committee is in principle a place to make > > decisions > > that affect the entire project. There are very few such decisions. > > One was the decision to change the implementation language of GCC > > from > > C to C++, a decision made in 2010. Another was the decision to > > allow > > GCC plugins. As a counter-example, moving GCC from Subversion to > > git > > was supported by the steering committee members, but there was no > > formal decision by the steering committee to approve the move. > > > > More generally, the GCC steering committee has historically served > > as > > a point of contact between the FSF and the GCC developers. In my > > opinion this has not amounted to much over the years that I've been > > on > > the committee (since 2014). > > Also, because the FSF considers the GCC SC the "package maintainers" > of GCC, the Steering Committee also receives and answers questions > and > requests from RMS and the FSF. > > And, as I mentioned in another thread, I believe that the role of the > GCC SC is to perform some of the duties of a good technical manager: > remove real or potential roadblocks so that the developers can focus > on being productive. > > Some of us have initiated other activities and alliances to support > and promote GCC and the GNU Toolchain, although it is not an official > responsibility of the GCC SC. > > Thanks, David
