From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 9E3E83858D20 for ; Wed, 30 Aug 2023 17:19:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9E3E83858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org Received: from linux-libre.fsfla.org ([2001:470:142:5::54] helo=free.home) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbOr2-0001Ha-QO; Wed, 30 Aug 2023 13:19:45 -0400 Received: from libre (libre-to-gw.home [172.31.160.161]) by free.home (8.15.2/8.15.2) with ESMTPS id 37UHJL7a1027215 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 30 Aug 2023 14:19:23 -0300 From: Alexandre Oliva To: "Carlos O'Donell" Cc: Joseph Myers , "Ryan S. Arnold" , Paul Eggert , Maxim Kuvyrkov , Jakub Jelinek , Andreas Schwab , libc-alpha Subject: Re: [Action Required] glibc decision to use CTI services. In-Reply-To: (Carlos O'Donell's message of "Tue, 29 Aug 2023 18:02:22 -0400") Organization: Free thinker, not speaking for the GNU Project References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Errors-To: aoliva@lxoliva.fsfla.org Date: Wed, 30 Aug 2023 14:19:20 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: [adding libc-alpha, where GNU libc discussions are held] On Aug 29, 2023, "Carlos O'Donell" wrote: > I propose the glibc project migrate to services provided by the > Core Toolchain Infrastructure (CTI) project, particularly services > provided by the Linux Foundation IT team. Nay. I do not perceive any benefits to GNU's values in becoming technologically dependent on an organization that never shared GNU's values, that has constantly pretended GNU didn't exist, persistently claimed our work to itself, and promotes and operates under values that conflict deeply with those that GNU stands for. It would amount to shooting itself in the paws. I acknowledge that the present supplier of equivalent services also started in a hostile manner, but at this point it's the devil we know. The plan should IMHO be to mitigate that dependency, not introduce another or replace one with a worse one. As I suggested back when this idea was first raised (and AFAICT there have been no attempts to dispute that this would be a better path to pursue), I'd be happy to accept this sort of contribution to GNU *iff* the services were *actively* *replicated* among two or three separate suppliers, so as to reduce the risk of dependency and of corrupting pressure on us. Even then, this would IMHO be a move for GNU to decide, or at the very least be consulted on, according to its own values and priorities, something that all mantainers appointed by GNU, myself included, committed ourselves to observe, prioritize and uphold as maintainers of GNU packages. I encourage other maintainers to justify their responses based on GNU's values and priorities, as they understand them. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Think Assange & Stallman. The empires strike back