From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id CD3FF3858D32 for ; Sun, 2 Oct 2022 21:38:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CD3FF3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x0b.wildebeest.org [172.31.17.141]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 93A683021EAC; Sun, 2 Oct 2022 23:38:14 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id 1D3352E8336E; Sun, 2 Oct 2022 23:38:14 +0200 (CEST) Date: Sun, 2 Oct 2022 23:38:14 +0200 From: Mark Wielaard To: Overseers mailing list Cc: Andrew Pinski Subject: Re: The GNU Toolchain Infrastructure Project Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3033.4 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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