public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: 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: Mon, 17 Oct 2022 12:11:53 -0400	[thread overview]
Message-ID: <9c0a9111-07b1-3617-c5c8-4b12e616f985@gotplt.org> (raw)
In-Reply-To: <caa3f145c9ce9a4083864501fad9f2b27ac7ef77.camel@klomp.org>

On 2022-10-17 11:10, Mark Wielaard via Overseers wrote:
<snip>
> In the last year we did some really nice work for the sourceware
> infrastructure. We setup the shared buildbot, got various companies and

I feel like you're taking this personally as an overseer; the proposal 
to transition to LF IT is not a value judgment on your work.  It is a 
proposal to scale far beyond what our current resources can afford.  I 
personally am grateful for all that work and have participated in some 
of it too but I don't think that it's a scalable approach for gcc or to 
a lesser extent, glibc.

> organisations to provide compute resources, workers for various
> architectures. We now have CI, Try and Full builders for various
> projects and doing 10.000+ builds a month. With a bunsen analysis
> database with all those test-results. Did a resource analysis and wrote
> up this public roadmap to make the email/git based workflow that
> sourceware projects rely on more fun, secure and productive by
> automating contribution tracking and testing. We now also have the
> sourcehut mirror and the public-inbox instance to make the email
> workflow nicer and support things like patch attestation. We are
> working on better integration between patchwork and buildbot for pre-
> commit checking. And we got the Software Freedom Conservancy to accept
> sourceware as a member project to act as a fiscal sponsor. They are now

Fiscal sponsor for the *sourceware overseers*.  There's no way for SFC 
to be a fiscal sponsor for sourceware, which is infrastructure owned by 
Red Hat.

> helping us with the future roadmap, setting up a organization,
> budgeting, etc. And the FSF also is supportive of this.

The FSF has little stake in sourceware beyond the GNU toolchain, so FSF 
being supportive of sourceware overseers seeking funding has about the 
same relevance as the FSF being supportive of my decision to move to a 
different country.

They do have a significant stake in infrastructure for the GNU toolchain 
project and they've been part of discussions since the idea for GTI 
germinated.

> And now you again seem to not want to discuss any details on how to
> work together. After Cauldron I thought we agreed we would discuss
> goals on overseers and create sourceware infrastructure bugs. So we
> could see what the community priorities were, write an updated
> sourceware roadmap, setup a budget, etc.

On multiple occasions I've been told on this list that sourceware 
administration being transitioned to LF IT is out of question, so I 
don't see the point of having these discussions.  I don't see a 
retention plan that's viable for the next 5, 10 or 20 years.

I personally do not think the current sourceware infrastructure, even 
with the roadmap it promises is a viable alternative to what LF IT can 
provide.  There is a significant resource gap (e.g. service isolation to 
different machines and/or containers, full time administrators with 
global presence for FTS support, established security and administration 
practices, traffic acceleration, to name a few) that we seem to disagree 
about.

There seems to be little to discuss from the GNU toolchain perspective 
IMO; the overseers think that the LF IT proposal and the additional 
funding and infrastructure it brings in are not necessary and we think 
it is.

> I was really happy to see the discussions about setting up a video chat
> system for projects, the FSF tech-team offering to setup mirrors,
> backups and help coordinate secure release uploads. And I had hoped to
> see some discussion on how the LF and potential sponsors could help,
> working together with the sourceware community and the SFC.
> 
> We really would love for gdb, glibc, binutils and gcc to keep being
> part of sourceware.

IMO the best way to make this happen is for us to transition sourceware 
administration to LF IT.  However since all projects hosted on 
sourceware don't seem to agree on this and the overseers also do not 
desire to give up control over the infrastructure, I don't see another 
way out of this.

Of course, like I said to Chris, it's likely going to be a while before 
we fully transition away from sourceware (it'll likely happen one 
service at a time, or something like that, we need to figure that out at 
some point) and we'll need continued help from the overseers to help 
manage the infrastructure in the near future.

Sid

  reply	other threads:[~2022-10-17 16:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2513b668-9ebd-9e78-7263-dc24f4a9558a@redhat.com>
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 [this message]
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
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-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
2022-10-12 17:40 Carlos O'Donell

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=9c0a9111-07b1-3617-c5c8-4b12e616f985@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.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).