public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Mark Wielaard <mark@klomp.org>,
	Overseers mailing list <overseers@sourceware.org>
Cc: gdb@sourceware.org, libc-alpha@sourceware.org,
	binutils@sourceware.org, gcc@gcc.gnu.org
Subject: Re: The GNU Toolchain Infrastructure Project
Date: Thu, 6 Oct 2022 17:07:02 -0400	[thread overview]
Message-ID: <f9025462-4a41-3991-22fd-7b4da598d922@gotplt.org> (raw)
In-Reply-To: <Yz80S+pOotPlSS4k@wildebeest.org>

On 2022-10-06 16:02, Mark Wielaard wrote:
>> I had in fact missed the websites mention, sorry I overreacted to your
>> comment.  In that case, I don't know if the GNU websites are actually part
>> of this proposal.
> 
> No worries. It seems everybody is somewhat unclear on the details of
> this proposal. Making it hard for people not to speculate a
> little. And it seems the scope changed between when various "key
> stakeholders" were informed, the LF/IT presentation, the Cauldron talk
> and what eventually got posted.

I had not noticed the mention of websites in the proposal, which is why 
I was taken aback by its mention here.  That oversight is my fault, 
nothing to do with the proposal itself.

Could you clarify in what way you think the *scope* got changed between 
the private communications and the proposal that actually got posted? 
The technical details (which is different from scope) were never meant 
to be baked in, that's for the TAC to agree upon.  In that sense, the 
proposal details being open-ended is by design.

> That is why we are trying to collect all details and file sourceware
> infrastructure bugs to track the various technical needs from a

Fair enough.

> community perspective. But it would be really nice to hear directly
> from the Linux Foundation and the OpenSSF about what exactly they are
> proposing, which parts of the proposal are mandatory, which can be
> mixed and matched, and how they see this working together with
> Sourceware becoming a Software Freedom Conservancy member
> project.

You and others have been repeating "sourceware as a project" in a 
community owned sense as a truth for a while now but it really isn't. 
It is Red Hat owned infrastructure that is maintained by volunteers.  It 
is unquestioningly a community (and I'm proud part of it as someone who 
maintains the patchwork instance), but that's not the same thing as 
being an independent project that can do agreements and sign up for 
memberships.

Maybe Red Hat could spin off a sourceware project in some form that is 
actually capable of becoming a SFC member?  Or alternatively, 
"sourceware overseers" could become a body that maintains sourceware and 
is able to get funding through SFC for its activities?

Thanks,
Sid

  parent reply	other threads:[~2022-10-06 21:07 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-27 20:08 Carlos O'Donell
2022-09-28 22:38 ` Carlos O'Donell
2022-10-02 20:47   ` Mark Wielaard
2022-10-04 13:46     ` Siddhesh Poyarekar
2022-10-04 14:01       ` Frank Ch. Eigler
2022-10-04 14:13         ` Siddhesh Poyarekar
2022-10-04 14:19           ` Frank Ch. Eigler
2022-10-04 14:33             ` Siddhesh Poyarekar
2022-10-04 14:41               ` Frank Ch. Eigler
2022-10-04 14:55                 ` Siddhesh Poyarekar
2022-10-04 15:07                   ` Frank Ch. Eigler
2022-10-06 21:42             ` Alexandre Oliva
2022-10-04 17:10       ` Christopher Faylor
2022-10-04 17:17         ` Siddhesh Poyarekar
2022-10-04 18:42           ` Christopher Faylor
2022-10-04 19:05           ` Mark Wielaard
2022-10-04 19:10             ` Siddhesh Poyarekar
2022-10-06 20:02               ` Mark Wielaard
2022-10-06 20:12                 ` Christopher Faylor
2022-10-06 21:37                   ` Siddhesh Poyarekar
2022-10-07 13:39                     ` Mark Wielaard
2022-10-06 21:07                 ` Siddhesh Poyarekar [this message]
2022-10-06 21:36                   ` Frank Ch. Eigler
2022-10-06 21:44                     ` Siddhesh Poyarekar
2022-10-06 22:57                       ` Frank Ch. Eigler
2022-10-11 13:02                         ` Siddhesh Poyarekar
2022-10-07  8:57                   ` Mark Wielaard
2022-10-11 13:24                     ` Siddhesh Poyarekar
2022-10-11 14:23                       ` Frank Ch. Eigler
2022-10-11 15:58                     ` Alexandre Oliva
2022-10-11 17:14                       ` David Edelsohn
2022-10-11 18:12                         ` Frank Ch. Eigler
2022-10-12  8:00                         ` Mark Wielaard
2022-10-12 13:18                           ` Florian Weimer
2022-10-12 21:23                             ` Mark Wielaard
2022-10-12 15:15                           ` Jonathan Corbet
2022-10-12 10:55                         ` Alexandre Oliva

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=f9025462-4a41-3991-22fd-7b4da598d922@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    --cc=libc-alpha@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).