Re: Toolchain Infrastructure project statement of support

Siddhesh Poyarekar
2022-10-17T16:13:15Z

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