Re: The GNU Toolchain Infrastructure Project

[Mark Wielaard <mark@klomp.org>]

Hi Andrew,

On Thu, Sep 29, 2022 at 02:13:29PM -0700, Andrew Pinski via Overseers wrote:
> "If ever" this seems too vague here and plus it seems like this was
> planned without being in the open. And it gives off this is my project
> and I want to control it only.

Thanks for expressing your worries so clearly. I don't think I can
easily take those away. But I do like to discuss some of the
infrastructure points you are making:

> There are a few other issues I want to raise about infrastructure
> projects going forward here:
> * supply chain security
> ** This seems to push out the small developers and even developers who
> don't want to do public key signing (I am included here).
> ** I get where corporations want to do this because they can track
> where things come from. But this is very much anti-open/free source
> ideals and very much anti-small developers

I wish we had had some time to discuss this at the Cauldron. We now
have the infrastructure in place, not just for git commit signing, but
also for patch attestation through our public-inbox instance, on
sourceware. This does indeed raise the question whether projects
should require it:

https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide17

The slide simply say:

  Patch attestation

  Either:

  - Awesome way to "close" the secure software supply chain
  - Security "theater" that will exclude people and reduce code reviews
    to "has the submitter jumped through code signing hoops"

  [Example showed DKIM verification, but this can also be done for gpg
   signed email messages or special patchatt "signed" patch emails.]

My personal feeling is that we should make it possible, but not
require it.  This is also what the kernel does btw. Some commits or
patches are signed, but most are not.

> * bug tracking
> ** as I mentioned in my other email, bugzilla right now is the best
> and only bug tracking system which statisfies the issue tracking for
> GCC because of the fields/meta data
> ** Providing funding to folks working on (and releasing) bugzilla
> might be a good resource for donations to go towards

I agree with this. I think the only real issue is that it is not easy
to replicate/mirror. I'll open a sourceware infrastructure bug for
that.

> * automated builds
> ** I see the sourceware folks have been getting a good automated build
> system up and running

https://builder.sourceware.org/ which provides pre-commit, CI and
full builders, putting results into bunsun at
https://builder.sourceware.org/testruns/ and in a git repo.

The infrastructure itself seems pretty solid now (doing more than
10.000 builds a month), although we can of course always use more
compute resources. But it really is up to the projects now to take
advantage of it and have some policies around test results and
analysis.

https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide5

> * Dejagnu improvements
> ** This would be another area where funding could go into and is very
> much lacking
> ** There has been some effects in years past to improve there but
> things have stalled or just died.

That is an interesting topic. Maybe not directly infrastructure
related though. But there are indeed various projects on sourceware
using dejagnu. To be honest I don't really know how/what to improve
here.

> * Patch mangement
> ** this has always been a hot topic but many of the patch mangement
> tools don't work with email systems
> ** Many new ones don't even touch emails and require people to use git
> or a web page directly

We do have patchwork.sourceware.org and inbox.sourceware.org. There
were some discussions at Cauldron about how to use patchwork
effectively. You really need someone to act as patchwork queue
maintainer. With public-inbox and newer b4 you can also integrate with
patchwork. But it is an aqcuired taste.

Also patchwork could use some upstream help for new features to better
integrate it with our CI platform.

> ** This could be an area where funding should go into
> * Sourceware maintaince/security enchements
> ** hot topic: there seems like there are some decent plans proposed
> already so I am not going to rehash them
> * New ways of doing communication besides email and IRC

Could you expand on this a bit? What kind of communication would you
like to see? Or just a way to have a quick video chat with other
developers?

> ** BBB: seems like there are some decent plans proposed there so I am
> not going to rehash them

This is already being tracked in
https://sourceware.org/bugzilla/show_bug.cgi?id=29590

> I think in summary; "Where's the beef?" is all I can think of when I
> read the GTI proposal. And how this was done in the private and in a
> very anti-democratic way.

Lets fix that. The infrastructure points you brought up are important
and deserve to be discussed in public so they can be added to the
sourceware roadmap.

Cheers,

Mark