From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) by sourceware.org (Postfix) with ESMTPS id 506ED38582AA; Sun, 23 Oct 2022 13:27:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 506ED38582AA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6F993141284; Sun, 23 Oct 2022 13:27:29 +0000 (UTC) Received: from pdx1-sub0-mail-a304 (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BBD75141376; Sun, 23 Oct 2022 13:27:28 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1666531648; a=rsa-sha256; cv=none; b=SHSfl/wKlPkM/3tSYMZDIpu8ecHoOVyuxNoQ9tS20N60xL81UJvkgCHfqXSkevDWkYfwFp WQ//ppcXSLNE5lYV5CeE3hhZHgOTRwN2B+JAy0FijpMDQP8XBh1YowQKK3AHSXe0NG/5Fh eiQ6y2UY0vtCS+VOKrz3PgHqtwCMAuik0flLTTlFCZCunBlnSwtGsEC74tA1DxsE35Hr4m MBeu8UKOcBsTNuBT78lhEh6R2FhsWFfUgKpdTQzXNjECNs6i9UhrYCgo2hoSaO5b3LXMgT cC5b7tZCd8f14ahBTCFW0v+in3uFfkI4cycHRM09rO8wHJpfl9PwDKathXQRng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1666531648; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=U5PZlzX5ubfQdNzsmRcyDi+kkKu8a1FQQgVRztqCeco=; b=dtx0hRqGa0RSZ8XVtX/0kJ3NyzqPVQ6gxAd7SUSv4KvHkyzx76ZE5EegSTKUo2GcMdUddO cLz68pwjoUTaMpNQgIucD8QrotIjgXBRAT35WmkrSSKXDnB0+VsBfCRuf0P0qSi/gBh/5R qbFPXsHLkHElliS7MdvqXoB0MSorX+dXnxbjUQjDsIBiLXSZ7Ymiw3ndad/Bzl9mZ3BnGx 7lf/bPw0SwtCqvPR/JnXObrqRU51rbyp48xl5GSzKrlq9SuQ9/Iaer3O5Yf6iGDX5ONgob Zxq1cwTCF+DHETNxQXIJSX8bL634z9y89fHFRbd4BV36qHNwU3wnKHyAO7+9iw== ARC-Authentication-Results: i=1; rspamd-7fb88f4dd5-m2mzz; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Suffer-Trail: 1e38c6791df135c5_1666531649244_3174488140 X-MC-Loop-Signature: 1666531649244:2938499526 X-MC-Ingress-Time: 1666531649244 Received: from pdx1-sub0-mail-a304 (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.122.72.98 (trex/6.7.1); Sun, 23 Oct 2022 13:27:29 +0000 Received: from [192.168.0.182] (bras-vprn-toroon4834w-lp130-05-174-93-41-34.dsl.bell.ca [174.93.41.34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a304 (Postfix) with ESMTPSA id 4MwJsW6mKzz2b; Sun, 23 Oct 2022 06:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1666531648; bh=U5PZlzX5ubfQdNzsmRcyDi+kkKu8a1FQQgVRztqCeco=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=YI7Y7s6xEkIvQ52WGr/PDs+tmObL2NoTZw88znMyY1j8DtY2/cyvTkn75C7Auv2Qz cLip1ALv+A1dsaTbGcKLTOzG5/cOZ9LC0L8yIueYpCmFGGgOf3G+sHMZgthjLIRXXR iX73h5nfty1RaE3jYLPaI4GiBfH0RVzU/eUr73q/ZzZZx97DNJGfmNnO/akqVmN4Mm yZitsrgFs7gCmkldv3fiZqCfWmJWKDCWNGReyL//NkvSAtQqhq5Un80qw+Fm604PtO ftPW383HlBqVr/KkAqFZLwUQR8l98GxC4RTkltYwzpI1gaDeteT74IGeGVK/3GokVa Nv3KWI0MKqaTw== Message-ID: <230909ee-fb2c-cca0-abbe-fd7d6434efab@gotplt.org> Date: Sun, 23 Oct 2022 09:27:26 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: Toolchain Infrastructure project statement of support Content-Language: en-US To: Ian Kelling , Overseers mailing list Cc: Mark Wielaard , gdb@sourceware.org, libc-alpha@sourceware.org, binutils@sourceware.org, gcc@gcc.gnu.org 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> <87zgdmyg30.fsf@fsf.org> From: Siddhesh Poyarekar In-Reply-To: <87zgdmyg30.fsf@fsf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1011.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,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: On 2022-10-23 04:59, Ian Kelling wrote: > 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/. Hybrid administration isn't part of the GTI proposal, why would that be considered an option? Is this something you'd like to propose to the TAC, i.e. give named members from the community access to infrastructure administration? We can bring that up in our discussion with the LF IT. > 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. Given that the current sourceware admins have decided to block migration of all sourceware assets to the LF IT, I don't have a stake on how they'd like to handle this for sourceware. I could however, as a member of TAC (and as member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc), discuss with others the possibility of specific community volunteers being given some amount of access to manage infrastructure. > 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. Both of those point to scaling hardware in addition to services, having things like physical isolation of services. Scaling volunteers (which hasn't happened in the last 20-soemthing years; it has scaled *down*, if anything) and money to pay for dedicated ops isn't going to mostly pointless if we can't pay for hardware, which is owned by Red Hat. That, and FSF not being able to add resources for the GNU toolchain was in fact why we had to look elsewhere for funding. I suggest you wait a day for the FSF hosted call so that the background is clearer. Sid