public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Giacomo Tesio <giacomo@tesio.it>
To: Gabriel Ravier <gabravier@gmail.com>
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 16:22:07 +0200	[thread overview]
Message-ID: <B07501E4-29B1-4553-B070-82D616E97864@tesio.it> (raw)
In-Reply-To: <8feed312-8129-7fed-0885-1aee018a9a99@gmail.com>

Hi Gabriel,

On June 9, 2021 12:41:09 PM UTC, Gabriel Ravier <gabravier@gmail.com>
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 play
between the FSF and the US companies that sponsor GCC development since
the very beginning.

BUT to be honest I was suprised that they didn't at least defer such
major change to the 12 series.

I mean they are not noobs.

They should know better.
We are talking about people from IBM, RedHat, Google...

This change IS going to cause legal issues to some users.
There was such a huge rush for this power grab?

> 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).

Indeed.

RMS/FSF accepted the EGCS (former name of the FORK of GCC) as the
official version of GCC and left the project full indipendence.

Such indipendence was still true today, thus all this mess has been
created for no reason at all (as far as we can say... thanks to SC).


But note: as you say, back then the decision was taken by FSF/GNU. 
Also note: back then people who wanted to "declare their independence"
forked the project AND changed the name of their indipendent project.

Why today they cannot do the same?
Why they cannot even wait for the 12+ series?


Giacomo

[1] see https://gcc.gnu.org/steering.html

[2] see https://gcc.gnu.org/pipermail/gcc/2021-March/235183.html

  reply	other threads:[~2021-06-09 14:22 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
2021-06-09 14:22           ` Giacomo Tesio [this message]
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=B07501E4-29B1-4553-B070-82D616E97864@tesio.it \
    --to=giacomo@tesio.it \
    --cc=gabravier@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --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).