public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Overseers <overseers@sourceware.org>
Subject: Re: Sourceware / GNU Toolchain at Cauldron
Date: Sun, 18 Sep 2022 23:38:42 +0200	[thread overview]
Message-ID: <20220918213842.GC27812@gnu.wildebeest.org> (raw)
In-Reply-To: <20220918162733.GB27812@gnu.wildebeest.org>

Hi all,

On Sun, Sep 18, 2022 at 06:27:33PM +0200, Mark Wielaard via Overseers wrote:
> But the discussion at Cauldron seemed really chaotic, I
> have trouble trying to summarize it. I posted my original discussion
> notes and first impressions here:
> https://gnu.wildebeest.org/blog/mjw/2022/09/18/sourceware-infrastructure-conservancy-gnu-toolchain-at-cauldron/
> 
> We agreed to continue the discussion on this mailinglist. Hopefully
> that will be a little more productive and structured.

I tried to write up some notes from the discussion at Cauldron on my
flight back to the Netherlands.

It is somewhat unfortunate that there were so many interruptions and
that apparently some people had missed some parts of the public
discussions we have had on this list and in the public chats with the
SFC. I thought we had over-communicated, but apparently we still
missed to include people in the conversation. I honestly believed we
had explicitly invited them earlier.

These are somewhat random since I was a bit too flabergasted about
what happened that I didn't make real notes. Please feel free to
correct any misinterpretations.

- Apparently our message of "everything is fine, we don't have any
  funding needs at this time, we are just thinking about the future"
  made some people think they couldn't sponsor at all. But I am happy
  people are so eager to sponsor. I wonder how we can adjust our
  messaging to be clear that financial contributions are of course
  always welcome. It is certainly not a bad thing to have some backup
  money in case of emergency.

- Somewhat similarly there seemed to be the concern that when we do
  formulate some technical goals that we could use funding for that
  the Conservancy would be unable to help with fundraising events. But
  from our discussions with the SFC this is precisely one of the
  services the Conservancy offers.

- As far as I understand there is no reason not to try to also raise
  funds through the Linux Foundation if that is easier for some
  companies. The Conservancy already does help projects that get some
  funding through the Linux Foundation.

- There were several different kind of "security concerns" which would
  be good to untangle:
  
  - There is the concern of he security of the sourceware server
    itself. We discussed that in one of the public chats with the SFC
    and the recommendation was to see if we could maybe hire a
    penetration testing firm to see if we missed anything.

  - 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.

  - There is the secure software supply chain idea. This is one of the
    things I wanted to discuss now that we have services like
    public-inbox and tools like b4 for patch attestation. Sourceware
    offers the services for that, but it really is a policy question
    for the guest projects whether they use that (and for example
    whether to use signed git commits).

- Although it is true that there is a GNU Toolchain with the FSF as
  fiscal sponsor and that the separate GNU projects work together
  using that name, it wasn't clear to me when in this discussion we
  were talking about the gdb, binutils, glibc and gcc projects
  collectively. From other discussions during Cauldron it was very
  clear that although each project is hosted on sourceware and using
  some of the same services, each one has its own policies which make
  sense for their separate communities.

- I wasn't really sure what to make of this LF/GTI proposal. It seemed
  to conflate separate concerns that we were explicitly trying to
  avoid with our Sourceware as Conservancy member proposal. It seemed
  to mix explicit fundraising with advocating for a certain "managed
  services at the LF/IT" technical proposal for using those funds. And
  setting up yet another fiscal sponsor?

Cheers,

Mark

  reply	other threads:[~2022-09-18 21:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-16 20:57 Zoë Kooyman
2022-09-16 21:10 ` Ian Kelling
2022-09-18 16:27 ` Mark Wielaard
2022-09-18 21:38   ` Mark Wielaard [this message]
2022-09-19 21:09     ` Mark Wielaard
2022-09-26 22:04     ` Carlos O'Donell
2022-09-27  1:31       ` Alexandre Oliva
2022-09-27 11:02       ` Mark Wielaard
2022-09-28 11:14       ` Frank Ch. Eigler
2022-09-30 13:38         ` Carlos O'Donell
2022-10-02 14:55           ` Frank Ch. Eigler
2022-10-03 13:26             ` Siddhesh Poyarekar
2022-10-03 13:53               ` Frank Ch. Eigler
2022-10-03 19:16                 ` Mark Wielaard
2022-10-03 15:55               ` Christopher Faylor

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=20220918213842.GC27812@gnu.wildebeest.org \
    --to=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).