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 121DA3858D39 for ; Sat, 2 Sep 2023 18:25:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 121DA3858D39 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 B3E4F306C58F; Sat, 2 Sep 2023 20:25:03 +0200 (CEST) Date: Sat, 2 Sep 2023 20:25:03 +0200 From: Mark Wielaard To: Sam James Cc: Paul Eggert , Jakub Jelinek , libc-alpha@sourceware.org, Andreas Schwab , Joseph Myers , Maxim Kuvyrkov Subject: Re: [Action Required] glibc decision to use CTI services. Message-ID: <20230902182503.GB25918@gnu.wildebeest.org> References: <15af1715-3530-7c29-7595-5abe48c18e8b@cs.ucla.edu> <87ledqe8ej.fsf@gentoo.org> <43743bb5-e79e-f915-9528-4b3556de1c5c@gotplt.org> <87sf7yc4py.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sf7yc4py.fsf@gentoo.org> 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,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 Sam, On Fri, Sep 01, 2023 at 04:01:02PM +0100, Sam James wrote: > >>> As I'm new to this (I just read yesterday that a decision is wanted by > >>> today) I'll vote NAY until I see something more binding about this > >>> important issue. > >>> > >> It's still unclear to me what problems this will solve compared to > >> using sourceware. > >> As far as I've seen, the sourceware overseers handle requests > >> promptly. Is there something we've asked them to do which they've > >> been unable to fulfill? > > > > There was a fairly long thread here and on overseers list last year on > > the motivation for moving to LFIT, if that's what you're asking > > about. > > Thanks - I did read that at the time, but I wasn't very specific here, > sorry. I guess I meant I don't really understand the transition plan > if it goes ahead. > > While we know they handle kernel.org fine, I'm a bit nervous > about it being an unknown entity wrt glibc - and also whether > it needs to be all or nothing. > > Could they not provide services in addition to sourceware, > at least initially? Do we need to move all the eggs? > > Or, to put it another way: it just seems like a leap into the unknown > and I don't really get why it's worth it yet. As others said there is no transition plan, just a list of services Sourceware currently provides, some of which LF IT might also be able to provide. There are also (less detailed) Sourceware services lists at https://sourceware.org/mission.html#services and per project at https://sourceware.org/projects.html There doesn't need to be a transition (plan) if people are ok with staying with Sourceware. There is a roadmap and people dedicated to maintaining and expanding the services together with various hardware and services partners. https://sourceware.org/mission.html#organization https://sourceware.org/sourceware-25-roadmap.html And of course before creating any transition plan there is the question of the governance of this proposed new organization. Does it give the same guarantees of money being used for Software Freedom and community focus as the Sourceware/SFC setup? https://sourceware.org/mission.html#plc https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/ > Have we actually hit scaling issues? The only real thing we need to > scale up is our testing AFAIK - which we have builder.sourceware.org > for now and it's growing. > > I can see the advantage in dedicated devops and service isolation - > although I don't know if sw has given an opinion on whether they can > do service isolation. I am sure the Sourceware project can. As you say we have been scaling builder.sourceware.org very nicely so it is doing 15.000+ builds a month across 28 bare metal, VMs and container workers. And we have multiple hardware and service partners now. https://sourceware.org/mission.html#sponsors Next to the two servers Red Hat provides we also have three from OSUOSL. So some of the new services are already running on separate machines in different datacenters. Other services have been setup so they can be easily migrated to VMs or separate servers. We also have good working relationships with the FSF tech-team, which already runs various services for the GNU projects, and the OSUOSL, which we have asked to run services, like the mattermost server, where they have more expertise. Both have paid staff to look after servers and services. We have monthly Open Office hours to learn from the community about any (scaling) issues and then the Sourceware Project Leadership Committee meets to discuss any issues, set priorities and decide how to spend any funds and/or negotiate with hardware and service partners to resolve them together with the Software Freedom Conservancy staff. Cheers, Mark