Re: GCC association with the FSF
41;344;0cOn Sun, Apr 11, 2021 at 07:30:13PM -0300, Adhemerval Zanella via Gcc wrote: And there was no hate (at least not from my side) only *disappointment* that you used your status to do it even though most of senior developers and maintainers said explicitly you shouldn’t do it. In GNU, there are no "senior" (or junior) developers/maintainers. Maintainers have some specific responsibilities, with which developers are not emcumbered. In almost all projects, the maintainers are also developers, but this need not be the case. But all maintainers are equal, and all developers are equal. J'
Re: GCC association with the FSF
Hi Alexandre and Jonathan, On Sun, 11 Apr 2021 23:49:54 -0300 Alexandre Oliva via Gcc wrote: > > - RMS ensures GCC stays honest (implying the rest of us can't be > > trusted or don't *really* believe in FOSS, I don't think it's true > > and don't see this as an advantage) > > Trust is not rational indeed In fact, trust has been fundamental to the evolution human race and is still foundational to both market economy (as Adam Smith wrote in 1776) and democracy. Trust CAN be naive when granted to people or organizations with either a track record of misbehaviour or misaligned incentives with the trustee. But trust is really irrational only when it cannot be easily reclaimed: when it's sticky (for any reason) it turns to political Power that tends to produce more issues than it used to solve as trust. Anyway, it's important to note that the point has never been "RMS is trustworthy while you are not", but "the FSF and the GNU project are credibly committed to protect Free Softare in the long run, the other members of the Steering Committee might or might not". Also looking at their affiliations and with all respect for their own personal integrity, too many things can go wrong to be ignored. People changes, group changes... shits happen. But if you have certain interests and demographics overly over-represented in the leadership of an organization, certain shits will happen way more than others and pass unnoticed. That's why I asked to fix the Steering Committee and NOT to reinstall Stallman: even if I rationally trust his consistency on Free Software, I'm not sure anymore his oversight really worked. > - this is unfair, RMS is being subjected to a witch hunt It might be irrelevant to your question (and for you personally), but it's not irrelevant to a movement that consider software as a form of expression like any other and explicitly refer to Free Software as Free Speech. In fact, all of the alligations against RMS are so solid that the harassers themeselves had to retract most them: https://rms-open-letter.github.io/appendix But it's not matter of fairness or inclusiveness: it's just politics. People here are exploiting the mob lynching Stallman to remove FSF oversight over the project without being questioned too closely from the rest of the world. But having said that, I'd really like to see Jonathan going forward with his fork if he can take with him most of US-corporate interests. Which doesn't mean that US-corporations should be forbidden here, just that they should have NOT such an overwhelming and unbalanced influence on the leadership of the project. My (hopefully last :-D) two cents. Giacomo
Re: GCC association with the FSF
On 4/12/21 12:55 PM, John Darrington wrote: In GNU, there are no "senior" (or junior) developers/maintainers. Maintainers have some specific responsibilities, with which developers are not emcumbered. In almost all projects, the maintainers are also developers, but this need not be the case. But all maintainers are equal, and all developers are equal. Those are terms we tend to use in the glibc developer community to loosely indicate the amount of time and resources individuals have spent in the glibc project as developers, testers, release managers, etc. In fact, 'maintainer' in glibc is not the same as 'maintainer' in GNU because they're not GNU maintainers. We call GNU maintainers "FSF stewards" in glibc to disambiguate that. It doesn't matter what these roles are called in GNU because they're not the names we use in the glibc community on a day to day basis. That said, we can have a conversation about glibc on the glibc mailing list. The gcc mailing list is not the place for it. In the interest of keeping the thread relevant, this is my last email on this topic on the gcc mailing list. Siddhesh
Re: GCC association with the FSF
On Sun, Apr 11, 2021 at 7:22 PM Jonathan Wakely via Gcc wrote: > > On Sun, 11 Apr 2021, 16:56 David Brown, wrote: > > > > > The big problem with a fork, rather than an amiable split (where FSF/GNU > > accepts that gcc wants to be a separate project) is the name. If the > > FSF keep their own "gcc" project, then calling the new fork "gcc" as > > well would cause confusion. > > > Packagers for Linux distros and BSD ports collections (and similar like > MinGW distros) are unlikely to be confused for long. > > The GNU project can have the "GNU C Compiler" name, as far as I'm > concerned. The "GNU Compiler Collection" name dates from the time when EGCS > replaced the original GCC so I would argue that the FSF couldn't claim > ownership of a new twist on it like "GCC Compiler Collection". > > And Apple already got away with shipping clang as the "gcc" and "g++" > executables (albeit causing much confusion) so even if the project changed > name, the shipped products wouldn't need to. > > Your point is valid, but I've been thinking about the practicalities a lot. > I still think losing the gcc.gnu.org DNS records would be the biggest > drawback. > > > And calling it something else would also > > confuse people - many would use the FSF gcc because of its name, not > > realising that there is a better fork. You can see that in the > > OpenOffice / LibreOffice split - I think a large proportion of people > > downloading OpenOffice do so without realising that LibreOffice exists > > and is way ahead of it on features. > > > > Only a small minority download GCC (we don't provide binaries for a start, > so most people use the binary package from their OS, or a semi-automated > build like portage or MacPorts). > > So I'm not terribly concerned about that problem. > > > > A fork may be unavoidable in the end, but a more diplomatic change of > > structure would have many advantages if it can be achieved. > > > > I would be very happy if the FSF took that view and let us walk away. If > not, I don't think it's a huge problem. Please people take a step back and let things cool down. While GCC might have little benefit from being associated with the FSF or GNU (I haven't made up my own mind on this yet) the benefits from disassociating itself from the FSF (or GNU) has just as many (little) benefits on its own as it has (possible) downsides. Certainly this whole discussion makes neither the GCC nor the FSF/GNU side appear in any positive way. Please concentrate on the important things, we're supposed to get a release of GCC 11 out of the door. Thanks, Richard.
Re: GCC association with the FSF
On Mon, 12 Apr 2021 at 03:12, Chris Punches via Gcc wrote: > 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. > The whole controversy is *because* many of the allegations are well founded. Some of the current SC members in this thread make it sound as if they were made up, but they never attempted as much as put the first few points (ones which matter to me the most, as a father) in any doubt from https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html B.
Re: GCC association with the FSF
On 12.04.21 11:32, Richard Biener via Gcc wrote: Please concentrate on the important things, we're supposed to get a release of GCC 11 out of the door. Amen.
Re: GCC association with the FSF
On Mon, 12 Apr 2021 at 11:24, Bronek Kozicki wrote: > On Mon, 12 Apr 2021 at 03:12, Chris Punches via Gcc > wrote: > >> 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. >> > > > The whole controversy is *because* many of the allegations are well > founded. Some of the current SC members in this thread make it sound as if > they were made up, but they never attempted as much as put the first few > points (ones which matter to me the most, as a father) in any doubt from > https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html > My sincere apologies to SC members, it was pointed out to me privately (thank you!) that the defenders of the person in question are not actually in SC. B. -- Bronek Kozicki b...@incorrekt.com
Re: GCC association with the FSF
David Brown writes: > > So why /do/ people use it? I suspect that one of the biggest reason is > > "it's the only compiler that will do the job". For a lot of important > > software, such as Linux kernel, it is gcc or nothing. Another big > > reason is that gcc comes with their system, which is commonly the case > > for Linux systems. In the embedded development world (where I work), > > the normal practice for getting a toolchain for a microcontroller is to > > download an IDE and toolchain from the manufacturer - and these days it > > is more often gcc than not. You use gcc because that is the standard, > > not from choice. > > > > For those that actively /choose/ gcc, why do they do so? I'd guess > > being convenient, well-known and free (as in beer) come a lot higher > > than the details of the licence, or the difference between "free > > software" and "open source software". (For me, a major reason is that > > the same compiler supports a wide range of targets. That, and that gcc > > is technically a better compiler for my needs than any alternatives.) > > To summarize, following are the reasons: > > 1. It compiles complex projects like Linux kernel[1]. > 2. It comes bundled with system > 3. Bundled with IDE toolchains for embedded programming > 4. Free (as in beer) > 5. Supports wide range of targets > 6. GCC is technically better compiler for specific needs > > I agree with all of the things. And I agree that a minority of the GCC > users and developers care about “Free Software” (as in freedom). What I > want to emphasize is that, once LLVM catches up on the above 6 points, > it will be only those who care about “freedom” that will stick to the > project. For users, the license will not matter much and the above reasons will most likely cover their needs. For developers, I think the GPL matters very much. It introduces fairness in the contribution process - companies and individuals can contribute code knowing that it can't be taken away and locked up, to be modified, sold and distributed as binary packages (eg. Nvidia). If ever there is something like a Libre Toolchain Foundation or similar in the future, stressing and advertising how the GPL protects code contributions can make a difference, IMHO.
Re: GCC association with the FSF
> For developers, I think the GPL matters very much. It introduces > fairness in the contribution process - companies and individuals > can contribute code knowing that it can't be taken away and locked > up, to be modified, sold and distributed as binary packages > (eg. Nvidia). Note that this discussion (part of which occurred off-list) didn't resolve the question of whether Nvidia did or didn't do that: nobody's been able to figure out what the Nvidia package in question does.
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
On Sun, 2021-04-11 at 17:06 +0530, Saloni Garg wrote: > On Sun, Apr 11, 2021 at 12:14 AM David Malcolm > wrote: > > > On Sat, 2021-04-10 at 21:18 +0530, Saloni Garg wrote: > > > On Thu, Apr 8, 2021 at 8:19 AM David Malcolm > > > > > > wrote: > > > > > > > On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote: > > > > [...] > > > > > > Looking at: > > > > https://gcc.gnu.org/wiki/SummerOfCode#Application > > > > we don't have a specific format to be followed. > > > > > > > > That said, I saw this > > > > > > > > https://google.github.io/gsocguides/student/writing-a-proposal > > > > which seems to have useful advice to prospective GSoC > > > > students. In > > > > particular, the "Elements of a Quality Proposal" lists various > > > > things > > > > that in your current draft are missing, and which would > > > > strengthen > > > > your > > > > proposal. So I'd recommend that you (and other prospective > > > > GSoC > > > > candidates) have a look at that. > > > > > > > Added some new sections. Tried to explain them as well. There are > > > some > > > things I am not clear about, so explicitly mentioned them and > > > will > > > add the > > > relevant explanations and present them in the later reports. > > > Please > > > let me > > > know if this sounds good to you and provide feedback as well. > > > > The updated version looks a lot stronger. > > > Hi, Thanks for the quick feedback. > > > > > That said, you haven't given details of your programming expertise > > - in > > particular this project will require proficiency with C++, so a > > good > > application would give evidence to the reader that you're already > > up- > > to-speed on writing and debugging C++ (see the "Biographical > > Information" section in the guide I linked to above for more info). > > > Apologies, but I am a beginner in this area of compilers and static > analysis. I already know some C++ coding which I have used mostly in > Competitive coding competitions. I have been following this( > https://www.cse.iitk.ac.in/users/karkare/Courses/cs618/) course to > understand the nuances of the static analysis. I am confident that I > can > write the C++ code that is required here and know how to use tools > like > GDB, Valgrind to debug the C++ codes, Your proposal would benefit from including something like the above. We're not expecting Bjarne Stroustrup levels of competence in C++, especially considering that you are all students - but we need some ability in C++... which you may already have, it's hard for me to tell as the current draft proposal is written. Part of the point of GSoC is to learn, but to learn about the specifics of the FLOSS project you apply to [1], rather than the implementation language. > but I don't have any good projects to > prove that right now. My college got stopped due to COVID-19 and > hasn't > started yet properly, so I have been trying to learn most of the > things > online only. > I hope you understand. Indeed. Hope this is helpful; good luck (the deadline to apply is fast approaching) Dave [1] and to learn about what "real" programming is like (for some definition of "real"), as opposed to the rather artifical programming that university coursework tends to be like. For example, GCC has 30+ years of legacy code to maintain, full of weird specialcases and dark corners, with dozens of target configurations - we can't just rewrite it all, or at least, not quickly :)
Re: GCC association with the FSF
On Mon, 12 Apr 2021 at 03:13, Chris Punches via Gcc wrote: > 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, > +1 I find some of the behaviour and and actions of developers afforded positions of authority in the project highly unprofessional, and irresponsible. I would seriously question their motives, and why they are involved in the project at all. > -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 > >
Re: GCC association with the FSF
On Apr 12, 2021, Adhemerval Zanella wrote: > No, you are insinuating that the glibc community both as maintainer > and contributors acted in a hateful way regarding the 'joke' > removal. Sorry, but this is not true; Easy to say for someone who hasn't been the target of hate, but it's just that it was there right then, it's *remains* there. Not exclusive among glibc maintainers, and certainly not unanimous among them, but there. I may even have earned it myself. But the one that Richard got over incorrect assumptions that he commanded the reversal, that's just another false piece of evidence often used to support the hate campaign. > The main idea, which I was vocal about and shared with some glibc > developers and maintainers, was that the "joke" has no place in a > technical manual. I understand there is consensus about that now, but back then there were too many unsettled policy issues to make that call consensually among all relevant parties. The main disagreement was not over the issue proper, though. It was about procedure, and then it was about whose opinions as much as counted. It was a really trivial issue, but sufficiently hot-button and triggering enough underlying issues that it got to be exploited politically in several ugly ways. It can't really be understood without looking into broader contexts that had long been mounting, and that again quite explicit in this list too. But I hope we can all agree that it was a horrible mess. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
Re: GCC association with the FSF
On 12/04/2021 14:52, Alexandre Oliva wrote: > On Apr 12, 2021, Adhemerval Zanella wrote: > >> No, you are insinuating that the glibc community both as maintainer >> and contributors acted in a hateful way regarding the 'joke' >> removal. Sorry, but this is not true; > > Easy to say for someone who hasn't been the target of hate, but it's > just that it was there right then, it's *remains* there. Not exclusive > among glibc maintainers, and certainly not unanimous among them, but > there. I may even have earned it myself. But the one that Richard got > over incorrect assumptions that he commanded the reversal, that's just > another false piece of evidence often used to support the hate campaign. There were no "hate" campaign from glibc developers and maintainers, keep stating it does not make it true. Since libc-alpha is non moderated list, there were a lot of unfriendly message from undisclosed or non-representative people. What happened is some glibc developers were *really* annoyed in the way *you* acted, not RMS; and they vocalized it. And you, instead of work toward to create consensus by making some concession (as the currently we try to run the glibc community), keep arguing to exhaustion that you acted in the benefit or the project. So the aforementioned 'hate' is just because we did not agreed in the way *you* acted, which caused a lot of distress. > >> The main idea, which I was vocal about and shared with some glibc >> developers and maintainers, was that the "joke" has no place in a >> technical manual. > > I understand there is consensus about that now, but back then there were > too many unsettled policy issues to make that call consensually among > all relevant parties. > > The main disagreement was not over the issue proper, though. It was > about procedure, and then it was about whose opinions as much as > counted. No, the disagreement is the way *you* did it. I haven't seen such contention and disarray you started since I have started to work on the project, about a decade ago. So, please stop put the blame of that episode on the glibc community as a whole. > > > It was a really trivial issue, but sufficiently hot-button and > triggering enough underlying issues that it got to be exploited > politically in several ugly ways. > > It can't really be understood without looking into broader contexts that > had long been mounting, and that again quite explicit in this list too. > > > But I hope we can all agree that it was a horrible mess. >
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
On Mon, Apr 12, 2021 at 7:35 PM David Malcolm wrote: > On Sun, 2021-04-11 at 17:06 +0530, Saloni Garg wrote: > > On Sun, Apr 11, 2021 at 12:14 AM David Malcolm > > wrote: > > > > > On Sat, 2021-04-10 at 21:18 +0530, Saloni Garg wrote: > > > > On Thu, Apr 8, 2021 at 8:19 AM David Malcolm > > > > > > > > wrote: > > > > > > > > > On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote: > > > > > > [...] > > > > > > > > Looking at: > > > > > https://gcc.gnu.org/wiki/SummerOfCode#Application > > > > > we don't have a specific format to be followed. > > > > > > > > > > That said, I saw this > > > > > > > > > > https://google.github.io/gsocguides/student/writing-a-proposal > > > > > which seems to have useful advice to prospective GSoC > > > > > students. In > > > > > particular, the "Elements of a Quality Proposal" lists various > > > > > things > > > > > that in your current draft are missing, and which would > > > > > strengthen > > > > > your > > > > > proposal. So I'd recommend that you (and other prospective > > > > > GSoC > > > > > candidates) have a look at that. > > > > > > > > > Added some new sections. Tried to explain them as well. There are > > > > some > > > > things I am not clear about, so explicitly mentioned them and > > > > will > > > > add the > > > > relevant explanations and present them in the later reports. > > > > Please > > > > let me > > > > know if this sounds good to you and provide feedback as well. > > > > > > The updated version looks a lot stronger. > > > > > Hi, Thanks for the quick feedback. > > > > > > > > That said, you haven't given details of your programming expertise > > > - in > > > particular this project will require proficiency with C++, so a > > > good > > > application would give evidence to the reader that you're already > > > up- > > > to-speed on writing and debugging C++ (see the "Biographical > > > Information" section in the guide I linked to above for more info). > > > > > Apologies, but I am a beginner in this area of compilers and static > > analysis. I already know some C++ coding which I have used mostly in > > Competitive coding competitions. I have been following this( > > https://www.cse.iitk.ac.in/users/karkare/Courses/cs618/) course to > > understand the nuances of the static analysis. I am confident that I > > can > > write the C++ code that is required here and know how to use tools > > like > > GDB, Valgrind to debug the C++ codes, > > Your proposal would benefit from including something like the above. > > We're not expecting Bjarne Stroustrup levels of competence in C++, > especially considering that you are all students - but we need some > ability in C++... which you may already have, it's hard for me to tell > as the current draft proposal is written. Part of the point of GSoC is > to learn, but to learn about the specifics of the FLOSS project you > apply to [1], rather than the implementation language. > Yes, I have added the details related to C++ in the document. > > > but I don't have any good projects to > > prove that right now. My college got stopped due to COVID-19 and > > hasn't > > started yet properly, so I have been trying to learn most of the > > things > > online only. > > I hope you understand. > > Indeed. > > > Hope this is helpful; good luck (the deadline to apply is fast > approaching) > Thanks, I have submitted the final proposal. Now switching on to the coding part. - Saloni > [...snip...]
Re: GCC association with the FSF
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 -- Nathan Sidwell
Re: GCC association with the FSF
On 4/12/21 5:32 AM, Richard Biener via Gcc wrote: Please concentrate on the important things, we're supposed to get a release of GCC 11 out of the door. Then it is important this is resolved. nathan -- Nathan Sidwell
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
"but muh freedum license re" "haha quality compiler suite go brrr" On Mon, Apr 12, 2021, 8:25 PM Chris Punches via Gcc wrote: > 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 > > > > > >
GSoC 2021 Proposal - Improve diagnostic messages for Rust-GCC
Hello everyone. I'll work on improving diagnostic messages for GCC's Rust front-end in Google Summer of Code. Here is the proposal: https://docs.google.com/document/d/1ZPRKu-PKPdZVOAZyYRq7YfSfA0eo7wyX3IL9KJoULnA/edit?usp=sharing Feel free to leave any comments or suggestions here. Ruihan Li
Re: GCC association with the FSF
On Mon, Apr 12, 2021 at 11:24 PM Nathan Sidwell wrote: > > On 4/12/21 5:32 AM, Richard Biener via Gcc wrote: > > > > > Please concentrate on the important things, we're supposed to get a > > release of GCC 11 out of the door. > > Then it is important this is resolved. Maybe - but it is very apparent that the current "discussion" will lead nowhere. Richard. > nathan > > -- > Nathan Sidwell
