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
next prev parent reply other threads:[~2022-10-17 16:11 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 [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-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=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).