public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Ian Kelling <iank@fsf.org>,
	Overseers mailing list <overseers@sourceware.org>
Cc: Mark Wielaard <mark@klomp.org>,
	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 09:27:26 -0400	[thread overview]
Message-ID: <230909ee-fb2c-cca0-abbe-fd7d6434efab@gotplt.org> (raw)
In-Reply-To: <87zgdmyg30.fsf@fsf.org>

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 <overseers@sourceware.org> 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

  reply	other threads:[~2022-10-23 13:27 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12 16:43 Carlos O'Donell
2022-10-12 18:13 ` Andrew Pinski
2022-10-13 18:25 ` Christopher Faylor
2022-10-14 12:33   ` Siddhesh Poyarekar
2022-10-17 15:10   ` Mark Wielaard
2022-10-17 16:11     ` Siddhesh Poyarekar
2022-10-18  9:50       ` Mark Wielaard
2022-10-18 15:17         ` Siddhesh Poyarekar
2022-10-18 16:42           ` Christopher Faylor
2022-10-18 18:13             ` Siddhesh Poyarekar
2022-10-18 18:14               ` Siddhesh Poyarekar
2022-10-18 18:47                 ` Paul Smith
2022-10-21  0:33               ` Alexandre Oliva
2022-10-23  8:59           ` Ian Kelling
2022-10-23 13:27             ` Siddhesh Poyarekar [this message]
2022-10-23 15:16               ` Frank Ch. Eigler
2022-10-23 16:07                 ` Siddhesh Poyarekar
2022-10-23 16:32                   ` Siddhesh Poyarekar
2022-10-23 17:01                   ` Jeff Law
2022-10-23 22:35                     ` Christopher Faylor
2022-10-23 17:09                   ` Frank Ch. Eigler
2022-10-23 17:38                     ` Jeff Law
2022-10-24  1:51                     ` Siddhesh Poyarekar
2022-10-24 12:40                   ` Corinna Vinschen
2022-10-23 20:57               ` Christopher Faylor
2022-10-23 21:17                 ` Siddhesh Poyarekar
2022-10-23 21:59                   ` Christopher Faylor
2022-10-24  1:29                     ` Siddhesh Poyarekar
2022-10-23 11:33       ` Ian Kelling
2022-10-23 16:17         ` Siddhesh Poyarekar
2022-10-23 18:56           ` Konstantin Ryabitsev
2022-10-23 21:19 ` Alexandre Oliva
2022-10-23 22:07   ` Christopher Faylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=230909ee-fb2c-cca0-abbe-fd7d6434efab@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    --cc=iank@fsf.org \
    --cc=libc-alpha@sourceware.org \
    --cc=mark@klomp.org \
    --cc=overseers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).