From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 8.mo69.mail-out.ovh.net (8.mo69.mail-out.ovh.net [46.105.56.233]) by sourceware.org (Postfix) with ESMTPS id 2AFCC3848420 for ; Wed, 9 Jun 2021 14:22:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2AFCC3848420 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tesio.it Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tesio.it Received: from player728.ha.ovh.net (unknown [10.108.16.176]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id DA8E5BD925 for ; Wed, 9 Jun 2021 16:22:14 +0200 (CEST) Received: from tesio.it (93-41-149-224.ip82.fastwebnet.it [93.41.149.224]) (Authenticated sender: giacomo@tesio.it) by player728.ha.ovh.net (Postfix) with ESMTPSA id 9ED4A1EE77A8A; Wed, 9 Jun 2021 14:22:10 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-96R00108fc33ff-4a30-475a-98b6-31d28ec9f8c7, 6CE41D23C9698AD425AA4AF6A3DE613FE0CD067A) smtp.auth=giacomo@tesio.it X-OVh-ClientIp: 93.41.149.224 Date: Wed, 9 Jun 2021 16:22:07 +0200 From: Giacomo Tesio To: Gabriel Ravier Cc: Valentino Giudice , Siddhesh Poyarekar , "gcc@gcc.gnu.org" Subject: Re: GCC Mission Statement Message-ID: In-Reply-To: <8feed312-8129-7fed-0885-1aee018a9a99@gmail.com> References: <5ed046a2-a2f1-f5e3-7399-dbf31808b8ef@gotplt.org> <736215d3-72b8-b2e2-f406-80d3d38688e0@gmail.com> <20210609121128.0000240f@tesio.it> <8feed312-8129-7fed-0885-1aee018a9a99@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 14886085619387395594 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfeduuddgjeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfgjfhggtgfgsehtjehmtddttddvnecuhfhrohhmpefiihgrtghomhhoucfvvghsihhouceoghhirggtohhmohesthgvshhiohdrihhtqeenucggtffrrghtthgvrhhnpeelueduteekhfeghffftdettdelhfdtueevleeukeeiieetueelteeiudfhvdelieenucffohhmrghinhepghhnuhdrohhrghenucfkpheptddrtddrtddrtddpleefrdeguddrudegledrvddvgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejvdekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepghhirggtohhmohesthgvshhiohdrihhtpdhrtghpthhtohepghgttgesghgttgdrghhnuhdrohhrgh X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 14:22:18 -0000 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 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