From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.fsf.org (mail.fsf.org [IPv6:2001:470:142::13]) by sourceware.org (Postfix) with ESMTPS id D5B5B3858D39; Sun, 23 Oct 2022 10:44:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D5B5B3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=fsf.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fsf.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsf.org; s=mail-fsf-org; h=MIME-Version:In-reply-to:Date:Subject:To:From:References; bh=P4bSSghxzGbIj1EQUhdzzM28610v/mkxkZKdJbHMq5Q=; b=XVJSgcNKtT6XqqYM7az4AmkiP 4G42uoEyLtgOUyxX5phTGOTMx/CaQaebdTXtoQGJZ6pH/4QZiiiLu/78Fpz7tASos7WVxp2wadaPc Pvdm0ofNTYvU0oHGaudKzgp3KbnZDEJDnQDfa3qPa8SoqysE3ZGZAXwZL4DwVNc70XcbbOUCkldqw F6K9eBGRpiIEBCIgf68RvYGIHuGOTVo0llmK+RTPUIlNn3+y2JjNDBG5oLTIha7qqtdL4RZw2Yzkn 0idC3kul+HasRjQx33+A7JFeDh118MpG/n+BYJqPK5WUMPFWO/VacFq//xNYub0U93u3QqUKnGqIh nVGIWOy9Q==; References: <2513b668-9ebd-9e78-7263-dc24f4a9558a@redhat.com> <20221013182529.sm76fysq37sv754x@cgf.cx> <9c0a9111-07b1-3617-c5c8-4b12e616f985@gotplt.org> <7abeb179-2c05-eee9-bd68-3b5f8a11bd32@gotplt.org> User-agent: mu4e 1.9.0; emacs 29.0.50 From: Ian Kelling To: Overseers mailing list Cc: Mark Wielaard , Siddhesh Poyarekar , gdb@sourceware.org, libc-alpha@sourceware.org, binutils@sourceware.org, gcc@gcc.gnu.org Subject: Re: Toolchain Infrastructure project statement of support Date: Sun, 23 Oct 2022 04:59:53 -0400 In-reply-to: <7abeb179-2c05-eee9-bd68-3b5f8a11bd32@gotplt.org> Message-ID: <87zgdmyg30.fsf@fsf.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Siddhesh Poyarekar via Overseers writes: >> what >> alternatives we have, etc. > For projects the alternatives they have are: > > 1. Migrate to LF IT infrastructure > 2. Have a presence on sourceware as well as LF IT, contingent to Red > Hat's decision on the hardware infrastructure > 3. Stay fully on sourceware > > For sourceware as infrastructure the alternatives are: > > 1. Migrate to LF IT infrastructure > 2. Stay as it currently is > > For sourceware overseers, the choices are contingent on what projects > decide and what Red Hat decides w.r.t. sourceware. > > All of the above has been clear all along. Maybe the problem here is > that you're not happy with the alternatives? No, I don't think that was ever clear. I've just read this message, but I've been keeping up with everything public since Cauldron. All your options assume that any specific service is 100% managed by LF IT, or 100% managed by sourceware. That is a bad assumption. They could do it together, or another group could help. So, you said you wanted "dedicated ops management", and I assume sourceware is not currently equipped for that. But there is no reason that an ops team from LF IT or FSF could not provide dedicated ops management for existing sourceware services in collaboration with sourceware. Another notable ops team is OSU, https://osuosl.org/. For example, at FSF tech team (where I work), we jointly maintain services with many volunteers that volunteer for specific projects. They are mainly: KDE, Linux Libre, Emacs, Savannah, Guix, GNU debbugs, replicant, h-node.org, planet.gnu.org, and Trisquel. The FSF tech team keeps a 24 hour on call rotation, so the services have a dedicated ops team to fix issues and respond to alerts, but the day to day management of the services those groups want, eg: upgrading them, configuring, modifying, etc is mostly done by volunteers. To give some very specific examples: a group of volunteer sysadmins for emacs decided they wanted a new build service for Emacs, so they jumped in a meeting with FSF tech team (I'm part of it) to discuss all the technical details and requirements. We decided the volunteers would do the primary installation and management of a gitlab that was only configured to use the build server, and FSF tech team would setup alerts, create the VM and the DNS. We agree on what kind of uptime is expected and what kind of alerts the tech team will respond to in off hours. The volunteer's ssh keys sit alongside the FSF tech team's keys on that VM. Alternatively, for Trisquel, Trisquel orders hardware and we go install it to the data center, and the Trisquel sysadmins spin up their own virtual machines or whatever they want to run, we just go into the data center with spare parts and fix things if the hardware breaks down. For any service we are going to support, we learn enough about the service to fix things things. Anyways, basically, having a dedicated ops team does not imply removing the sourceware's role, it could simply mean: adding a dedicated ops team to sourceware. To provide dedicated ops for the physical servers would require moving the servers or into servers in a data center near the ops team, or outsourcing the hardware management to one of many companies (usually by renting a physical server), but that is all totally feasible and not a big cost. Siddhesh Poyarekar via Overseers writes: > I want us to migrate > services to infrastructure with better funding (that's not just limited > to services), What do you want to fund specifically? "Infrastructure" and "not limited to services" is not specific enough to understand. > and an actually scalable future. What does "an actually scalable future" mean? That is very vague. -- Ian Kelling | Senior Systems Administrator, Free Software Foundation GPG Key: B125 F60B 7B28 7FF6 A2B7 DF8F 170A F0E2 9542 95DF https://fsf.org | https://gnu.org