From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 99F733858D37 for ; Thu, 31 Aug 2023 08:37:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 99F733858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 99480303A800; Thu, 31 Aug 2023 10:37:49 +0200 (CEST) Date: Thu, 31 Aug 2023 10:37:49 +0200 From: Mark Wielaard To: Alexandre Oliva Cc: Jakub Jelinek , libc-alpha , Andreas Schwab , Joseph Myers , Maxim Kuvyrkov Subject: Re: [Action Required] glibc decision to use CTI services. Message-ID: <20230831083749.GA12940@gnu.wildebeest.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3028.9 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Alex, On Wed, Aug 30, 2023 at 02:19:20PM -0300, Alexandre Oliva via Libc-alpha wrote: > [adding libc-alpha, where GNU libc discussions are held] Thanks. I am just a small contributor to glibc, but I do help out with some of the infrastructure we use. So I am happy we are having this discussion with all contributors. I can only answer your concerns for the Sourceware project. I wasn't included in this Linux Foundation CTI proposal. > 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. I assume you are referring to when egcs/sourceware were started. I wasn't around then. But I note that these days we have a good working relation with the FSF tech-team, Ian Kelling is one of the Sourceware PLC members, and we talked through our plans to setup a non-profit home for Sourceware as SFC member project with the FSF director, Zoë Kooyman. > The plan should IMHO be to mitigate that dependency, not introduce > another or replace one with a worse one. We also worked to diversify our hardware and services partners so we are less reliant on just corporate sponsors. See https://sourceware.org/sourceware-25-roadmap.html for the various efforts. > 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. I know this doesn't go far enough for you, but we have always provided rsync services to make it easy to replicate the data needed for various services. All the source code repositories are now actively mirrored at the Software Heritage projects and the active git repositories are also available at https://sr.ht/~sourceware/ With public-inbox all public mailinglists are also easy to replicate and access through various protocols. For the main servers we do have "hot backups". Currently at the same provider, but we are planning to have something similar at OSUOSL and/or the FSF. > 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. For Sourceware we have the Sourceware Project Leadership committee which includes various GNU Maintainers/Stewards. I hope the community trusts them to uphold the values and priorities. You can find the current members at https://sourceware.org/mission.html#plc which also lists the legal agreements and conflict of interest policy. Cheers, Mark