GCC Mission Statement
Hi. The Mission Statement of the GCC project recently changed without any announcement. I am not a contributor to GCC, merely a user. However, I'd like to understand more, especially about the transparency of the project. The GCC Steering Committee is supposed to follow the mission statement as a guide for its decision. Who changes the mission statement, and for what reason? How can a modification of the statement be guided by the mission statement? How were users and contributors informed of this? Thank you in advance for your response. Best regards. For reference: - The GCC homepage states the SC is "guided by the mission statement": https://gcc.gnu.org/ - The mission statement before the update: https://web.archive.org/web/20210331192925/https://gcc.gnu.org/gccmission.html
GCC Mission Statement
> Sent: Thursday, June 10, 2021 at 3:26 AM > From: "Giacomo Tesio" > To: "Richard Biener" > Cc: "gcc@gcc.gnu.org" , "Valentino Giudice" > > Subject: Re: GCC Mission Statement > > Sure Richard, I know. > > On June 9, 2021 2:32:22 PM UTC, Richard Biener wrote: > > > > You are free to create "DCO-free" branches for the GCC 11 series > > (and older), reverting any DCO "incumbered" backports that reach > > the official GCC branches for those series. > > I could. > > Like all other people affected by the change. > If they know they should. > > But isn't this a responsibility inversion? > > > I wonder: is this how you treat your users? > > "Go fuck yourself" but politely stated? > > To be honest, this comes to me as a great surprise. > > > That's what one would expect by the random guy on github, not by employees > of RedHat or Google serving as the Steering Committee of GCC. > > > Giacomo We could start all over again. We have already done it once with just one man. And he shocked the world!
Re: GCC Mission Statement
On 6/9/21 10:13 AM, Valentino Giudice via Gcc wrote: Hi. The Mission Statement of the GCC project recently changed without any announcement. Well there was an announcement; the changes in the mission statement reflect the new reality introduced by that announcement: https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html Siddhesh
Re: GCC Mission Statement
Thank you. > Well there was an announcement; the changes in the mission statement reflect > the new reality introduced by that announcement: > > https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html > > Siddhesh I was aware of that announcement, but it doesn't mention the mission statement at all. It appears that the decision in question was, at the time, in contrast with the mission statement (rather than guided by it). If the Steering Committee updates the mission statement, it may appear that the mission statement follows the decisions of the steering committee (in place of the contrary). In that case, what would be the purpose of a mission statement? The mission statement was also updated beyond simply making it consistent with the change: in "Supporting the goals of the GNU project, as defined by the FSF" the reference to the FSF was removed. Was there any announcement about the update of the mission statement itself? On what basis does the Steering Committee change the mission statement?
Re: GCC Mission Statement
On 6/9/21 10:39 AM, Valentino Giudice wrote: I was aware of that announcement, but it doesn't mention the mission statement at all. It appears that the decision in question was, at the time, in contrast with the mission statement (rather than guided by it). If the Steering Committee updates the mission statement, it may appear that the mission statement follows the decisions of the steering committee (in place of the contrary). In that case, what would be the purpose of a mission statement? The mission statement was also updated beyond simply making it consistent with the change: in "Supporting the goals of the GNU project, as defined by the FSF" the reference to the FSF was removed. Quite a few projects under the GNU project[1] have dissociated themselves from the FSF, so "as defined by the FSF" perhaps doesn't apply as consistently as it did before. That is my understanding anyway; maybe there's more context that others may be able to add. Siddhesh [1] https://gnu.tools/en/software/
Re: GCC Mission Statement
Le 09/06/2021 à 07:09, Valentino Giudice via Gcc a écrit : > If the Steering Committee updates the mission statement, it may appear > that the mission statement follows the decisions of the steering > committee (in place of the contrary). In that case, what would be the > purpose of a mission statement? A chicken and egg question, hey (~: -- Didier
Re: GCC Mission Statement
On 6/9/21 7:09 AM, Valentino Giudice via Gcc wrote: If the Steering Committee updates the mission statement, it may appear that the mission statement follows the decisions of the steering committee (in place of the contrary). In that case, what would be the purpose of a mission statement? In essence, a mission statement is just that, a statement of the mission that the SC aims to follow. If the SC wishes to change that mission, it follows that the statement should be adjusted to adapt. The statement serves as any other statement serves: it gives information to others. Of course, the mission statement is also binding on the SC itself, in a more social way: If it does not wish to lose faith of the GCC community, it should not go against the mission statement nor should it change it recklessly. Speaking on the "change it recklessly" issue, I would personally say that SC has indeed arguably done this: I believe there should have been discussion of this change in the mailing list before it occurred, as essentially the only discussion on the mailing list that could have implied something like this would happen was the discussion from a while back about RMS and the FSF where some people threatened to pull away from GCC entirely if it remained tied to the FSF. I personally happen to agree with the change (which seems to have especially avoided what would have been a painful split that could have had disastrous consequences for GCC as a whole), but find it rather disconcerting that such changes with potentially major consequences were done without any direct discussion of them with the community whatsoever.
Re: GCC Mission Statement
Hi Gabriel, On Wed, 9 Jun 2021 11:44:10 +0200 Gabriel Ravier via Gcc wrote: > Speaking on the "change it recklessly" issue, I would personally say > that SC has indeed arguably done this [...] > some people threatened to pull away from GCC entirely if it remained > tied to the FSF. I personally happen to agree with the change (which > seems to have especially avoided what would have been a painful split > that could have had disastrous consequences for GCC as a whole), but > find it rather disconcerting that such changes with potentially major > consequences were done without any direct discussion of them with the > community whatsoever. Did you consider that, in fact, the lack of transparency of the Steering Committee has shown since then (or even just the lack of professionalism, when it comes to explicit intruduce major changes in major versions) is a "disastrous consequence for GCC as a whole"? Unilateral undiscussed changes by the Steering Committe is the new norm. And such Steering Committee is in no way representing the interests of the worldwide users of GCC, first because its members do not know them (the vast majority is from the US, work for US corporations or both) and second because they do not listen to any objection / request that does not comes from their own circle / social group. Are you sure that an explicit fork with two projects with different names and governance would had been worse than what GCC has become? Giacomo
Re: GCC Mission Statement
On 6/9/21 12:11 PM, Giacomo Tesio wrote: Hi Gabriel, On Wed, 9 Jun 2021 11:44:10 +0200 Gabriel Ravier via Gcc wrote: Speaking on the "change it recklessly" issue, I would personally say that SC has indeed arguably done this [...] some people threatened to pull away from GCC entirely if it remained tied to the FSF. I personally happen to agree with the change (which seems to have especially avoided what would have been a painful split that could have had disastrous consequences for GCC as a whole), but find it rather disconcerting that such changes with potentially major consequences were done without any direct discussion of them with the community whatsoever. Did you consider that, in fact, the lack of transparency of the Steering Committee has shown since then (or even just the lack of professionalism, when it comes to explicit intruduce major changes in major versions) is a "disastrous consequence for GCC as a whole"? I do consider that a lack of transparency is pretty bad, and that discussions on subjects like this should be done in public, but I wouldn't say it's just as bad as the potential risk that a fork would incur. As for a lack of professionalism, I think it's pretty clear that GCC 11 is the cutoff point here, and although there might be some problems with licensing bug fixes to old versions (which could not be reasonably avoided unless GCC made no major releases until GCC 11.5 is out), there isn't much reason to make a major version just for this when there was a major version a month ago. Note that releases are done ~1 time per year, so there isn't much FSF-copyrighted work "lost" with this. Unilateral undiscussed changes by the Steering Committe is the new norm. And such Steering Committee is in no way representing the interests of the worldwide users of GCC, first because its members do not know them (the vast majority is from the US, work for US corporations or both) and second because they do not listen to any objection / request that does not comes from their own circle / social group. From what I know on this subject, the SC is meant to represent the GCC community (those that actively participate in GCC development, at least), and they are composed of well-recognized members of that community. Adding in random unknown people to represent the "worldwide users" of GCC would certainly not be taken well by the community and would heavily hurt the credibility of the SC in the eyes of everyone involved in working on GCC, which would consequently hurt the project. You might have your own views on the subject, but I would prefer having a credible SC that might not represent everyone in the world well than have an SC representing everyone in the world that isn't trusted by the people involved with the project (which could then result in the SC becoming trusted... by the few people who remain after all those that don't trust it leave). Are you sure that an explicit fork with two projects with different names and governance would had been worse than what GCC has become? To be clear: From what I can see, the GCC project has effectively declared their independence (which they already pretty much had, they've just made it publicly clear) from the FSF in terms of who is at the helm of the project. It is their right to do so, and they certainly had the power to do so when the only power the FSF could exert over them was very minor, with as the only leverage some minor reputation loss from the loss of association with GNU and the DNS records for gcc.gnu.org. If RMS wants to try to do anything, the most he can do is expel the SC as the maintainers of the "GNU Compiler Collection", take the DNS records for gcc.gnu.org and make a fork that would most certainly be considered by everybody to be "FSF GCC" or something like that to distinguish it from what would most certainly be the GCC basically everyone uses. The only result of this would be that basically everyone would move over to gcc-compiler.org or something like that, and the situation would be functionally unchanged from what it is now. Note: GCC as it has been for the past 2 decades was already a fork of the original GCC: RMS just decided to accept EGCS (former name of the current GCC) as the official version of GCC endorsed by GNU (this is why it was already effectively independent). Giacomo
Re: GCC Mission Statement
Hi Gabriel, On June 9, 2021 12:41:09 PM UTC, Gabriel Ravier wrote: > > I do consider that a lack of transparency is pretty bad, and that > discussions on subjects like this should be done in public, but I > wouldn't say it's just as bad as the potential risk that a fork would > incur. I really wonder what kind of risks are you thinking about. Really, I could not see anyone. Two organizations with different goals and values that explore different ways to implement a compiler collection cannot cause any harm. > As for a lack of professionalism, I think it's pretty clear that GCC > 11 is the cutoff point here May you point me to the line in the GCC 11.1's Changelog that document this? I cannot find anything! Please give it a look: https://gcc.gnu.org/gcc-11/changes.html > and although there might be some problems with > licensing bug fixes to old versions (which could not be reasonably > avoided unless GCC made no major releases until GCC 11.5 is out), > there isn't much reason to make a major version just for this when > there was a major version a month ago. GCC 11.1 is the first release of the 11 series. In a professional environment more respectful of downstream users, such major change would have been announced for the 12 series and applied only to it an successive ones. It would be very easy to achieve, allowing people around the world to properly assess and handle the subtle legal risk introduced. I mean: are we talking about GCC or a random hobby compiler on github? > Note that releases are done ~1 time per year, > so there isn't much FSF-copyrighted work "lost" with this. To be honest, I do not see the change as an issue for FSF. The new legal risks affect users. > > Unilateral undiscussed changes by the Steering Committe is the new > norm. > > > > And such Steering Committee is in no way representing the interests > > of the worldwide users of GCC, first because its members do not know > > them (the vast majority is from the US, work for US corporations or > > both) and second because they do not listen to any objection / > > request that does not comes from their own circle / social group. > > From what I know on this subject, the SC is meant to represent the GCC The steering committee was founded in 1998 with the intent of preventing any particular individual, group or organization from getting control over the project [1]. But as Juvenal wrote "Quis custodiet ipsos custodes?" I argued that FSF had such role (through RMS [2]), but now the members of Steering Committee itself are "getting control over the project". > community (those that actively participate in GCC development, at > least), and they are composed of well-recognized members of that > community. Adding in random unknown people to represent the > "world wideusers" of GCC would Strawman: nobody ever suggested this. You could radically increase SC diversity very easily, by removing people who comes from the same corporation and adding people who are well respected but do NOT share the exact same demographics and interests of the other SC members. Do you really think that ONLY white men working for a US tech company or another ought to be "well-recognized members of that community"? If not, they need not to be "random unknown people". > certainly not be taken well by the community and > would heavily hurt the credibility of the SC in the eyes of everyone > involved in working on GCC, which would consequently hurt the project. I always love how diversity completely stop being important when called on the right group of good ol' well-respected US-centric white men! :-D > You might have your own views on the subject, but I would prefer > having a credible SC that might not represent everyone in the world > well than have an SC representing everyone in the world that isn't > trusted by the people involved with the project This is a false dilemma. GCC could have a diverse AND trustworthy Steering Committee. The current one is not diverse at all. And if it was trustworthy they would have had no issue in discussing this major change BEFORE applying it. > > Are you sure that an explicit fork with two projects with different > > names and governance would had been worse than what GCC has become? > > To be clear: From what I can see, the GCC project has effectively > declared their independence (which they already pretty much had, > they've just made it publicly clear) from the FSF in terms of who is > at the helm of the project. It is their right to do so Sure! It's called "forking" and usually comes with a clear change in name. GNU Compiler Collection is... uhm... a GNU project. > they certainly had the power to do so when the only power the FSF > could exert over them was very minor, with as the only leverage some > minor reputation loss from the loss of association with GNU and the > DNS records for gcc.gnu.org. Well, you are right, it's plain clear: all of this has been a power p
Re: GCC Mission Statement
On Wed, Jun 9, 2021 at 4:22 PM Giacomo Tesio wrote: > > Hi Gabriel, > > On June 9, 2021 12:41:09 PM UTC, Gabriel Ravier > wrote: > > > > I do consider that a lack of transparency is pretty bad, and that > > discussions on subjects like this should be done in public, but I > > wouldn't say it's just as bad as the potential risk that a fork would > > incur. > > I really wonder what kind of risks are you thinking about. > > Really, I could not see anyone. > > Two organizations with different goals and values that explore > different ways to implement a compiler collection cannot cause any harm. > > > > As for a lack of professionalism, I think it's pretty clear that GCC > > 11 is the cutoff point here > > May you point me to the line in the GCC 11.1's Changelog that > document this? > > I cannot find anything! Because GCC 11.1 was not affected by this change though GCC 11.1.1+ will. You are free to create "DCO-free" branches for the GCC 11 series (and older), reverting any DCO "incumbered" backports that reach the official GCC branches for those series. git should make that easy up to the first major conflict / dependence issue. Richard.
Re: GCC Mission Statement
Sure Richard, I know. On June 9, 2021 2:32:22 PM UTC, Richard Biener wrote: > > You are free to create "DCO-free" branches for the GCC 11 series > (and older), reverting any DCO "incumbered" backports that reach > the official GCC branches for those series. I could. Like all other people affected by the change. If they know they should. But isn't this a responsibility inversion? I wonder: is this how you treat your users? "Go fuck yourself" but politely stated? To be honest, this comes to me as a great surprise. That's what one would expect by the random guy on github, not by employees of RedHat or Google serving as the Steering Committee of GCC. Giacomo
Re: GCC Mission Statement
> Quite a few projects under the GNU project[1] have dissociated themselves from the FSF, so "as defined by the FSF" perhaps doesn't apply as consistently as it did before. That doesn't really answer any of my questions, though.
Re: GCC Mission Statement
I am glad this email created some discussion. Some users seem to think the change was either reckless or nontransparent. This includes one user who replied me off list: > Please continue until they tell the truth. Given the additional context provided by the answers, I agree with that opinion. I therefore call for the Steering Committee to reconsider the decision and, at minimum, discuss it openly and transparently both on this mailing list (seeking for consensus) and the FSF (especially given its strong role in the previous mission statement). I think the SC is accountable to the users as well, given that it being guided by the mission statement is plainly stated on the GCC homepage. But of course, it is also accountable to the people directly involved. I think the SC needs to clarify whether it gets to do whatever it wants and change the mission of the project at will, for any reason whatsoever. I personally believe a positive answer is in contradiction with what the SC is meant to be: > The primary purpose of the steering committee is to make major decisions in > the best interests of the GCC project and to ensure that the project adheres to its fundamental principles found in the project's mission statement. https://gcc.gnu.org/steering.html
The GCC Mission Statement says nothing about conforming to international standards!?
I just read the GCC Mission Statement and I see nothing there about conforming to international standards for programming languages. Why does the GCC Mission Statement not include conforming to internationally accepted standards? Its very counterproductive not to use standards. -John Burak
The GCC Mission Statement says nothing about conforming to international standards!?
I guess I could have worded my email a bit better. Of course I don't assume that the GCC developers are ignoring standards. Nor do I think any of us are unaware of GCC's ability to support a standard and have extensions to it that go beyond the standard. So I simply want to suggest to the proper people (who hopefully are reading this ;) that perhaps the mission statement should include something about the GCC project efforts to encompass programming language standards and then go beyond them whenever necessary in order to make the compiler even more useful. -John
Re: The GCC Mission Statement says nothing about conforming to international standards!?
icrashedtheinternet wrote: I just read the GCC Mission Statement and I see nothing there about conforming to international standards for programming languages. Why does the GCC Mission Statement not include conforming to internationally accepted standards? Its very counterproductive not to use standards. Of course not including it in the mission statement does not mean that it is not a requirement, so the last sentence is a bit of a non-sequitur. To me, implementing C means implementing the standard, and I think that this is the general approach of gcc, so it is not entirely clear it should be explicit in the mission statement. Ultimately the more important goal is to implement a widely useable compiler, to the extent that includes following the standard, that's what will happen. -John Burak
Re: The GCC Mission Statement says nothing about conforming to international standards!?
On Sat, Feb 03, 2007 at 01:42:06AM -0700, icrashedtheinternet wrote: > I just read the GCC Mission Statement and I see nothing there about > conforming to international standards for programming languages. Why > does the GCC Mission Statement not include conforming to > internationally accepted standards? Its very counterproductive not to > use standards. You incorrectly assume that the mission statement is an exhaustive list of every GCC priority. It isn't. Many GCC contributors are active members of the appropriate standards committees, and GCC tries to conform to appropriate standards and to document known areas of non-compliance. Standards conformance is a goal, but it is not the #1 goal. For example (to risk reviving a recent debate), it appears that almost every large C program in existence assumes, deliberately or accidentally, that int overflow wraps around in a two's complement manner, but a compiler that rigorously enforced conformance to internationally accepted standards could happily break all of that code (e.g. by trapping on every overflow). The result is that GCC explicitly rejects something that you might have been taught in compiler class, that the standard is a contract between the compiler developer and the users and that the compiler can do anything it wants with any code that does not rigorously meet what is defined in the standard. Standard-conforming code should work, but the issue of what to do with technically incorrect, but commonly occurring code is something that we'll continue to struggle with. In some cases, serving the users might require going beyond the standard, in other cases, the cost in lost opportunities for optimization might be too high.
Re: The GCC Mission Statement says nothing about conforming to international standards!?
Joe Buck wrote: The result is that GCC explicitly rejects something that you might have been taught in compiler class, that the standard is a contract between the compiler developer and the users and that the compiler can do anything it wants with any code that does not rigorously meet what is defined in the standard. Standard-conforming code should work, but the issue of what to do with technically incorrect, but commonly occurring code is something that we'll continue to struggle with. In some cases, serving the users might require going beyond the standard, in other cases, the cost in lost opportunities for optimization might be too high. Indeed ... Of course it would be more controversial to depart from the standard on the basis of making the compiler more useable, and it is hard to see such a case, though I cam imagine a case where we decide the standard is plain wrong, and we won't conform to it pending it being fixed. The fundamental goal here is to generate an effectively useable compiler, conforming to the standard is a means to this end, not an end in itself. I actually think that in these cases that Joe alludes to above, concentrating *too* much on standards compliance can be the wrong emphasis, since it can lead to a position of "if it isn't in the standard, we are not interested!" which is not quite the right attitude for dealing on a case by case basis with situations where expected behavior goes beyond what is required by the standard. So putting conforming to the standards in the mission statement is not only unnecessary for me, it is probably a bad idea.
Re: The GCC Mission Statement says nothing about conforming to international standards!?
icrashedtheinternet wrote: I guess I could have worded my email a bit better. Of course I don't assume that the GCC developers are ignoring standards. Nor do I think any of us are unaware of GCC's ability to support a standard and have extensions to it that go beyond the standard. So I simply want to suggest to the proper people (who hopefully are reading this ;) that perhaps the mission statement should include something about the GCC project efforts to encompass programming language standards and then go beyond them whenever necessary in order to make the compiler even more useful. Why? (Or, to be less gnomic: Why do you feel that this should be included in the mission statement? You're proposing the idea, but you're not giving any reasons for it at all. If it were obvious why it should be in there, it would already be there, presumably.) - Brooks
