public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gabriel Ravier <gabravier@gmail.com>
To: Giacomo Tesio <giacomo@tesio.it>
Cc: Valentino Giudice <valentino.giudice96@gmail.com>,
	Siddhesh Poyarekar <siddhesh@gotplt.org>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: GCC Mission Statement
Date: Wed, 9 Jun 2021 14:41:09 +0200	[thread overview]
Message-ID: <8feed312-8129-7fed-0885-1aee018a9a99@gmail.com> (raw)
In-Reply-To: <20210609121128.0000240f@tesio.it>

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

  reply	other threads:[~2021-06-09 12:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09  4:43 Valentino Giudice
2021-06-09  4:56 ` Siddhesh Poyarekar
2021-06-09  5:09   ` Valentino Giudice
2021-06-09  5:32     ` Siddhesh Poyarekar
2021-06-11  4:42       ` Valentino Giudice
2021-06-09  6:31     ` Didier Kryn
2021-06-09  9:44     ` Gabriel Ravier
2021-06-09 10:11       ` Giacomo Tesio
2021-06-09 12:41         ` Gabriel Ravier [this message]
2021-06-09 14:22           ` Giacomo Tesio
2021-06-09 14:32             ` Richard Biener
2021-06-09 15:26               ` Giacomo Tesio
2021-06-09 15:34                 ` Christopher Dimech
2021-06-09 13:48   ` Christopher Dimech
2021-06-09 14:02     ` Aaron Gyes
     [not found]     ` <01624AC3-781E-4AAC-A469-87A777AD50DA@icloud.com>
     [not found]       ` <trinity-d5e4b50f-600c-41dd-a628-e2c1d0103604-1623252603196@3c-app-mailcom-bs05>
2021-06-09 15:49         ` Aaron Gyes
2021-06-09 20:49           ` Christopher Dimech
2021-06-09 21:07             ` Aaron Gyes
2021-06-10  3:10               ` Christopher Dimech
2021-06-11  4:58 ` GCC " Valentino Giudice

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8feed312-8129-7fed-0885-1aee018a9a99@gmail.com \
    --to=gabravier@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=giacomo@tesio.it \
    --cc=siddhesh@gotplt.org \
    --cc=valentino.giudice96@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).