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 CF8513858438 for ; Tue, 27 Sep 2022 11:02:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CF8513858438 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 tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id A0CB03000462; Tue, 27 Sep 2022 13:02:01 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 261D5413CD0E; Tue, 27 Sep 2022 13:02:01 +0200 (CEST) Message-ID: Subject: Re: Sourceware / GNU Toolchain at Cauldron From: Mark Wielaard To: Overseers mailing list Cc: Carlos O'Donell Date: Tue, 27 Sep 2022 13:02:00 +0200 In-Reply-To: <2db869b5-5724-18c0-e356-9e5df8f7cb4d@redhat.com> References: <20220918162733.GB27812@gnu.wildebeest.org> <20220918213842.GC27812@gnu.wildebeest.org> <2db869b5-5724-18c0-e356-9e5df8f7cb4d@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-3033.6 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 Carlos, Thanks for joining the public discussion. On Mon, 2022-09-26 at 18:04 -0400, Carlos O'Donell via Overseers wrote: > - There is the "hardening" concern of separating unix user > > accounts > > for separate services like running git hooks. This is one of the > > things that the buildbot service offers. We could also adopt > > something like gitolite. >=20 > ... and run them on a distinct machine (which requires machine resources,= and admin > time, etc). >=20 > Adopting gitolite is also a great step in the direction of not having rea= l accounts > for users of a services. Lets add gitolite to the roadmap, I think it is a great idea to offer it to projects. I am running it personally for code.wildebeest.org, it is packaged and I know it is practically zero-maintenance to run. We can even run it inside a project specific container or vm to have more isolation. > Technically speaking, I think the Linux Foundation IT, with their existin= g work with > public-inbox (ahead of its time), b4, patatt, and more, means they are gl= obally the > best positioned to keep solving these problems and supporting the develop= ment of > these FOSS tools for the linux kernel and others. Even more so for a dist= ributed > development model that we use for the GNU Toolchain. I agree they do some nice work supporting those upstream tools and services. And I have been really happy that we now have our own public- inbox instance at https://inbox.sourceware.org/ There is a bit more background about using it with b4 including a discussion on patch attestation in the original BoF discussion presentation: https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide14 Press 'p' for presentation notes for some additional background/questions. Or see the raw markdown presentation: https://gnu.wildebeest.org/~mark/sourceware/sourceware.md b4 console session:=20 https://gnu.wildebeest.org/~mark/sourceware/b4.session.txt Cheers, Mark