public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Mark Wielaard <mark@klomp.org>
Cc: Overseers mailing list <overseers@sourceware.org>,
	gdb@sourceware.org, libc-alpha@sourceware.org,
	binutils@sourceware.org, gcc@gcc.gnu.org
Subject: Re: Toolchain Infrastructure project statement of support
Date: Tue, 18 Oct 2022 11:17:15 -0400	[thread overview]
Message-ID: <7abeb179-2c05-eee9-bd68-3b5f8a11bd32@gotplt.org> (raw)
In-Reply-To: <Y0523Fe692vOAbtn@wildebeest.org>

On 2022-10-18 05:50, Mark Wielaard wrote:
> Hi Siddhesh,
> 
> On Mon, Oct 17, 2022 at 12:11:53PM -0400, Siddhesh Poyarekar wrote:
>> There seems to be little to discuss from the GNU toolchain perspective IMO;
> 
> Yes, it is clear you don't want any discussion or answer any questions
> about the proposals, 

That is not true, Mark.  Your objections and questions have been 
answered at every stage, privately as well as publicly.  What *is* clear 
is that we have been talking past each other because despite our common 
high level intentions, we appear to have little common ground for our 
goals.  You want to retain the current sourceware infrastructure and try 
and see what we can do within that framework and I want us to migrate 
services to infrastructure with better funding (that's not just limited 
to services), dedicated ops management and an actually scalable future.

> how funds can be used,
Let me turn that around: how *would* you like funds to be used beyond 
what is currently proposed in the LF IT proposal?

> what the budget is, 

Around $400,000.

> what
> the requirements are, 

Your lack of clarity about requirements IMO have more to do with you 
wanting to fulfill those requirements within sourceware and not with 
their existence.  I and others have repeated them here and the overseers 
have either questioned their validity or noted them in bugzilla as 
possible things to explore in the current sourceware context.  With 
sourceware migration to LF IT off the table, there's little incentive 
for me personally to explore them.

> how the governance structure works, 

I think you know how it works, maybe you meant to say that you don't 
like it?

The governance structure and their workings have been described in the 
GTI introduction.  There are two key bodies that govern the project: the 
Technical Advisory Council (comprised of project community members) 
manages the technical details of the infrastructure and the governing 
board (comprised of representatives from funding companies) manages the 
funding for those technical details.

The current TAC comprises of people from the initial community 
stakeholders who were contacted and subsequently accepted the invitation 
to be part of TAC.  You, along with other overseers, were invited too 
but most of you declined.

> what
> alternatives we have, etc.
For projects the alternatives they have are:

1. Migrate to LF IT infrastructure
2. Have a presence on sourceware as well as LF IT, contingent to Red 
Hat's decision on the hardware infrastructure
3. Stay fully on sourceware

For sourceware as infrastructure the alternatives are:

1. Migrate to LF IT infrastructure
2. Stay as it currently is

For sourceware overseers, the choices are contingent on what projects 
decide and what Red Hat decides w.r.t. sourceware.

All of the above has been clear all along.  Maybe the problem here is 
that you're not happy with the alternatives?

> But personally I think it is healthy to have real discussions, doing
> resource analysis, creating public roadmaps, collecting infrastructure
> enahancement requests, discuss how to organize, argue about the needed
> budget and how to use funding most efficiently, etc. To make sure that
> sourceware keeps being a healthy and viable free software
> infrastructure project for the next 24 years, hopefully including the
> various GNU toolchain projects.

You want to talk about sourceware without including the LF IT proposal 
whereas I'd love to talk about sourceware as an LF IT maintained 
infrastructure.  There's a real disconnect that precludes any real 
discussions.

Sid

  reply	other threads:[~2022-10-18 15:17 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12 16:43 Carlos O'Donell
2022-10-12 18:13 ` Andrew Pinski
2022-10-13 18:25 ` Christopher Faylor
2022-10-14 12:33   ` Siddhesh Poyarekar
2022-10-17 15:10   ` Mark Wielaard
2022-10-17 16:11     ` Siddhesh Poyarekar
2022-10-18  9:50       ` Mark Wielaard
2022-10-18 15:17         ` Siddhesh Poyarekar [this message]
2022-10-18 16:42           ` Christopher Faylor
2022-10-18 18:13             ` Siddhesh Poyarekar
2022-10-18 18:14               ` Siddhesh Poyarekar
2022-10-18 18:47                 ` Paul Smith
2022-10-21  0:33               ` Alexandre Oliva
2022-10-23  8:59           ` Ian Kelling
2022-10-23 13:27             ` Siddhesh Poyarekar
2022-10-23 15:16               ` Frank Ch. Eigler
2022-10-23 16:07                 ` Siddhesh Poyarekar
2022-10-23 16:32                   ` Siddhesh Poyarekar
2022-10-23 17:01                   ` Jeff Law
2022-10-23 22:35                     ` Christopher Faylor
2022-10-23 17:09                   ` Frank Ch. Eigler
2022-10-23 17:38                     ` Jeff Law
2022-10-24  1:51                     ` Siddhesh Poyarekar
2022-10-24 12:40                   ` Corinna Vinschen
2022-10-23 20:57               ` Christopher Faylor
2022-10-23 21:17                 ` Siddhesh Poyarekar
2022-10-23 21:59                   ` Christopher Faylor
2022-10-24  1:29                     ` Siddhesh Poyarekar
2022-10-23 11:33       ` Ian Kelling
2022-10-23 16:17         ` Siddhesh Poyarekar
2022-10-23 18:56           ` Konstantin Ryabitsev
2022-10-23 21:19 ` Alexandre Oliva
2022-10-23 22:07   ` 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=7abeb179-2c05-eee9-bd68-3b5f8a11bd32@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).