public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Overseers mailing list <overseers@sourceware.org>
Cc: Mark Wielaard <mark@klomp.org>,
	Christopher Faylor
	<cgf-use-the-mailinglist-please@sourceware.org>
Subject: Re: Moving sourceware to the Linux Foundation? No thanks.
Date: Mon, 26 Sep 2022 18:21:38 -0400	[thread overview]
Message-ID: <6dc88e78-1de6-7430-8fd6-a36997d69632@redhat.com> (raw)
In-Reply-To: <YzDW3fJaw8NHFUwV@wildebeest.org>

On 9/25/22 18:31, Mark Wielaard via Overseers wrote:
> Hi Chris,
> 
> On Sun, Sep 18, 2022 at 03:42:38PM -0400, Christopher Faylor via Overseers wrote:
>> The LF proposal, on the other hand, is for a wholesale move of the
>> sourceware domain and services to a system wholly owned and controlled
>> by Linux Foundation IT.
> 
> We talked a bit at the Cauldron about it and agreed to continue the
> conversation on this list. There is somewhat of an overview of the
> plan in this lwn article:
> https://lwn.net/SubscriberLink/908638/567de0001d86662c/
> 
> I hope they will post the whole proposal to this list, but I think it
> really is a couple of separate proposals. Each proposal is connected
> to the LF or a subsidiary which makes it sound like it is one big LF
> takeover. It was kind of presented as a package deal, but I think we
> can mix and match the separate proposals once we better understand the
> separate parts. Also different parts seem to have the same or similar
> names "GTI", which sometimes seem to stand for GNU Toolchain
> Initiative or GNU Toolchain Infrastructure. I'll try to explain as far
> as I understand it.

GTI stands for GNU Toolchain Infrastructure.

I agree that there is some mixing-and-matching that we can do, and that we already
do today to a certain degree.

> First there is a proposal from the LF/OpenSSF to provide money to help
> with solving certain cybersecurity requirements. Some of these seem to
> be related to actual infrastructure requirements, others seem to be
> related to project policies around using signed commits and patch
> attestation and following things like https://slsa.dev/

Correct, along with that the OpenSSF has as a technical vision, making secure development
practices the norm.

> It wasn't really clear which security issue was really an
> infrastructure issue. I tried to separate some concerns in this email:
> https://sourceware.org/pipermail/overseers/2022q3/018849.html

I've responded to your post there to discuss a few more points.

> The LF/OpenSSF has a ten point plan:
> https://openssf.org/oss-security-mobilization-plan/
> 
> Some of which do seem interesting, but will need a lot of work to turn
> into concrete things we can do with the infrastructure and policies to
> adapt for the projects.
> 
> I think for concrete infrastructure related ideas the Conservancy
> could accept the money and we can decide how to use it to implement
> them.
> 
> Secondly they would like to setup a fund at the Linux Foundation which
> would collect money from sponsors. This is (also) called GTI. These
> sponsors then decide how to spend their money to best help the GNU
> Toolchain (which seems to extend to all Sourceware projects).
> 
> This LF/GTI would then hire the LF/IT to provide some managed services
> for some sourceware projects.
> 
> Another idea was to use the fund to setup a BBB server. It wasn't
> clear whether the LF/IT would then also be asked to set that up.
> 
> Finally they would setup an advisory board, which advises the LF/IT
> how to run the managed services and which would also have one seat on
> the LF/GTI for spending money on other initiatives.
> 
> It isn't completely clear yet how all this mixes-and-matches with
> Sourceware being a Conservancy member project. But I think we should
> be able to figure out how to combine the best parts of the community
> driven approach with the corporate sponsor approach once more details
> become clear.

Two proposals.

The first is that we would seek fiscal sponsorship from the OpenSSF at the Linux
Foundation because they are specifically looking to solve secure supply chain
issues and many of us would like to see that improved for the core GNU Toolchain
and other projects. This involves setting up project, the GNU Toolchain Infrastructure
project, and discussing with sponsors to support the project. There is a structure
to GTI which we can discuss in another thread (board, TAC, community etc.)

The second is that we would migrate to managed services at the Linux Foundation IT.
I've highlighted in the other thread why I think this is the best technical choice, but
I'll copy it here:
~~~
Technically speaking, I think the Linux Foundation IT, with their existing work with
public-inbox (ahead of its time), b4, patatt, and more, means they are globally the
best positioned to keep solving these problems and supporting the development of
these FOSS tools for the linux kernel and others. Even more so for a distributed
development model that we use for the GNU Toolchain.
~~~

>> If you're satisfied in the way sourceware has been run and are confident
>> that the people running it know what they're doing, and have your best
>> interests at heart, then please speak up.  If you don't really know
>> what's going on here and don't want to take my word for it that
>> something smells fishy then *please* listen carefully to to the proposal
>> if/when this is finally publicly announced.  I would not be surprised if
>> alarms start going off in your head when you hear what's being proposed
>> - like they did for me.
>>
>> For those who don't know, I've been helping keep sourceware running
>> since I was at Cygnus (and then Red Hat) starting in 1999.  I've
>> continued to offer my volunteer services since I left Red Hat in 2003.
> 
> I am really sorry your huge influence on Sourceware wasn't more
> prominently mentioned during the BoF.

I also really appreciate Chris' efforts and support.

Thank you again Chris.

-- 
Cheers,
Carlos.


      parent reply	other threads:[~2022-09-26 22:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Yw5aTCLyYx8qqN3W@wildebeest.org>
2022-08-31 22:19 ` Proposing Sourceware as SFC member project Jose E. Marchesi
2022-09-01  8:28   ` Mark Wielaard
2022-09-02 18:51     ` Daniel Pono Takamori
2022-09-03 14:07       ` Karen M. Sandler
2022-09-03 16:38         ` Mark Wielaard
2022-09-18 19:42         ` Moving sourceware to the Linux Foundation? No thanks Christopher Faylor
2022-09-25 22:31           ` Mark Wielaard
2022-09-26 14:07             ` Ian Lance Taylor
2022-09-26 17:05               ` Christopher Faylor
2022-09-26 19:57               ` Frank Ch. Eigler
2022-09-27 13:03                 ` Carlos O'Donell
2022-09-28  8:53                   ` Ian Kelling
2022-10-02 21:15                     ` Mark Wielaard
2022-09-28  8:33                 ` Ian Kelling
2022-09-28 10:08                   ` Frank Ch. Eigler
2022-09-26 21:53               ` Moving sourceware into the future Mark Wielaard
2022-09-27 17:12                 ` Daniel Pono Takamori
2022-09-26 22:21             ` Carlos O'Donell [this message]

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=6dc88e78-1de6-7430-8fd6-a36997d69632@redhat.com \
    --to=carlos@redhat.com \
    --cc=cgf-use-the-mailinglist-please@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).