public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: overseers@sourceware.org
Subject: Re: The GNU Toolchain Infrastructure Project
Date: Wed, 19 Oct 2022 01:47:36 -0400	[thread overview]
Message-ID: <3d75e761-ad7c-8b79-9587-51903378e189@redhat.com> (raw)
In-Reply-To: <87v8p6i6ht.fsf@meer.lwn.net>

On 9/29/22 10:45, Jonathan Corbet wrote:
> carlos@redhat.com (Carlos O'Donell) writes:
> 
>> During the Sourceware / Infrastructure BoF sessions at GNU Cauldron, the GNU
>> Toolchain community in collaboration with the Linux Foundation and OpenSSF,
>> announced the GNU Toolchain Infrastructure project (GTI).
> 
> Thanks for making more information available.
> 
> Just for the record, it is still my feeling that the LF's infrastructure
> management has been a good thing for the kernel community.  Whether it
> would be suitable for the toolchain community is not something I'm in a
> position to have an opinion on.  If anybody is curious about how
> interactions with that group work, there is a current discussion on
> bugzilla that might be interesting:
> 
>   https://lwn.net/ml/ksummit-discuss/05d149a0-e3de-8b09-ecc0-3ea73e080be3@leemhuis.info/
> 
> Konstantin's response to the idea of moving everything to a Gitlab
> instance is the sort of thing I find reassuring.
>
> I do, though, have a few questions.
> 
> - Why not dispense with the governing board and have the TAC be the
>   decision-making body?  That would help ensure ongoing community
>   control over this infrastructure.  It would also be a clear statement
>   from the sponsors that they trust the community and do not intend to
>   force changes in how development is done.

The GNU Toolchain leadership, and GTI TAC are always free to seek new funding
if the governing board does not support a specific spend.

A separation of the fiscal responsibility and technical responsibility is a standard
model in most organizations. Any organization that provides fiscal sponsorship
ultimately imposes some fiscal control, even if it is not stated explicitly. 
The separation of responsibilities also helps to avoid conflicts of interest and
insider deals.  With the transparency instituted for the GTI TAC and governing board,
the FOSS community can see and respond to any inappropriate pressure or influence. 
We don't expect the FOSS community to suddenly become timid about these concerns.

After 35+ years of negotiating the various challenges of guiding the GNU Toolchain
interactions with software ecosystems, IHVs, ISVs, the GNU Project and the FSF, the
GNU Toolchain leadership and the GTI TAC have the experience and mandate to advocate
for the GNU Toolchain projects when working with a governing board.

> - How were the members of the TAC chosen, and what will be the process
>   for choosing members in the future?

The GTI TAC was bootstrapped by engaging community contributors with direct experience
in GNU Toolchain infrastructure and the technical requirements of the GNU Toolchain
developers. This includes members from gcc, glibc, gdb and binutils communities along
with members of overseers. These invited members were asked to suggest additional
members to the TAC.

We expect the next set of TAC members will be determined with input from the community
and with the assistance of the current TAC.
 
> - During the Cauldron discussion it was said that $400,000 in annual
>   funding has been committed to GTI.  You must have a rough budget for
>   how those funds will be spent that you can share?

When we approached the Linux Foundation as part of developing the proposal we worked
with the LF IT team to consider a TAC proposal where all services offered by Sourceware
were provided by the LF IT team. This was designed as an exercise to scope costs if all
the projects decided they wished to adopt a proposal to move to managed services at the
LF.

I don't want to quote out-dated numbers. The budget needs to be revised as the GTI TAC
works through the current proposal with the community.

The rough number listed above are part of the OpenSSF's sponsorship to help support
infrastructure for the GNU Toolchain in keeping with the OpenSSFs mission to improve
open source security. The initial scoped cost I mentioned earlier was less than the
$400K/yr and included non-recurring costs for migration along with ongoing costs
required to deliver services for gitolite, mail, mailing lists, public-inbox,
patchwork/patchwork-bot, git hooks, wikis, and websites. These services are listed
and discussed in the last GTI TAC meeting: https://gti.gotplt.org/tac/

The rough budget was focused heavily on FOSS infrastructure and IT support costs to
ensure security and quality for the service provided to the projects.

Some costs were not fully scoped, like websites for example, because they involve
more complex requirements from the projects.

> - Keeping that money stream going will surely require ongoing
>   fundraising efforts; who will be responsible for that?  What happens
>   if, say, tech companies start getting nervous about dark economic
>   clouds on the horizon and stop funding the project?

The Linux Foundation has ongoing fund raising discussions with its membership, and
they would play a key part in working with GTI to find funding for the project.
Many current corporate sponsors of the GNU Toolchain are also members of the
Linux Foundation.

The GNU Toolchain and the FSF have been around for 35+ years. The Linux Foundation
has been around for 20+ years. These organizations have weathered many storms, and
continued to support their core projects.

Lastly, the use of FOSS-based distributed development models allow us the most 
freedom if we need to move or change hosting for any reason.

-- 
Cheers,
Carlos.


  parent reply	other threads:[~2022-10-19  5:47 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-27 19:59 Carlos O'Donell
2022-09-28 14:06 ` Frank Ch. Eigler
2022-09-29  9:51 ` Mark Wielaard
2022-09-29 14:45 ` Jonathan Corbet
2022-09-29 17:13   ` Joseph Myers
2022-09-29 18:40     ` Elena Zannoni
2022-09-29 18:54     ` Andrew Pinski
2022-10-19  5:47   ` Carlos O'Donell [this message]
2022-09-29 21:13 ` Andrew Pinski
2022-09-30 14:35   ` Siddhesh Poyarekar
2022-09-30 15:05     ` Andrew Pinski
2022-09-30 15:51       ` Siddhesh Poyarekar
2022-10-02 21:56         ` Mark Wielaard
2022-09-30 15:22     ` Christopher Faylor
2022-09-30 15:34       ` Siddhesh Poyarekar
2022-10-02 21:38   ` Mark Wielaard
2022-10-02 22:19 ` Mark Wielaard
     [not found] <d9cb6cf9-89f5-87bb-933b-a03240479e71@redhat.com>
     [not found] ` <a9396df3-5699-46ef-0b33-6c7589274654@redhat.com>
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
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
     [not found] <b00dc0aa-31a6-a004-a430-099af3d0f6d1@redhat.com>
     [not found] ` <558996ac-e4a0-cf77-48b9-f7d0e13862e8@redhat.com>
2022-10-02 20:54   ` Mark Wielaard
2022-10-03 19:24   ` Carlos O'Donell

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=3d75e761-ad7c-8b79-9587-51903378e189@redhat.com \
    --to=carlos@redhat.com \
    --cc=corbet@lwn.net \
    --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).