public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Pinski <pinskia@gmail.com>
To: Overseers mailing list <overseers@sourceware.org>
Cc: "Carlos O'Donell" <carlos@redhat.com>
Subject: Re: The GNU Toolchain Infrastructure Project
Date: Thu, 29 Sep 2022 14:13:29 -0700	[thread overview]
Message-ID: <CA+=Sn1m9jaj2TciLpivXqZErajOp3c=SVtkb8RbkaWWvVHTqTQ@mail.gmail.com> (raw)
In-Reply-To: <ef140a6b-c72d-bd63-b94c-bceeb365b32a@redhat.com>

I think the whole GTI was revealed to the world is lost of trust from

On Tue, Sep 27, 2022 at 12:59 PM Carlos O'Donell via Overseers
<overseers@sourceware.org> wrote:
>
> The GNU Toolchain is a critical foundation of trust for the GNU/Linux ecosystem
> and the demands on its infrastructure, services, and security requirements have
> grown over time. The trend of increasing complexity to support its development
> and associated financial demands will not abate. Different projects have
> different risk tolerances and the GNU Toolchain must meet more stringent
> expectations to maintain the trust of the ecosystem. It is with this context in
> mind that the following proposal has been developed.
>
> 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).

The way this announcement was handled was done in a bogus way and
loses trust of many smaller/independent developers.
It makes many folks feel like this was done in a hosital way and even
more is LF and OpenSSF the correct groups to collaborate with here?
I feel like LF and OpenSSF is actually not the right folks to get
involved with sourceware and even more with the compiler.
LF is very much Linux centric and while the GNU Toolchain and other
projects on sourceware are not even related at all to the Linux and
even more there are many embedded developers who like not to even to
be associated with Linux. GitHub sits on the board of OpenSSF which
seems to run counter to what GTI is trying to do.
I get the feeling also there is too many corporations trying to push
the way forward with this proposal rather than a true open source
community.

> The collaboration
> includes a fund for infrastructure and software supply chain security, which
> will allow us to utilize the respected Linux Foundation IT (LF IT) services
> that host kernel.org and to fund other important projects.

> The key
> stakeholders of the GNU Toolchain community have been proactively briefed and
No they were not and I have a problem with the word "key" here because
I was not briefed at all.
I get the feeling what you define as key is not the same as myself.

> included in community conversations during the process of developing this
> proposal with incorporation of their feedback. The key stakeholders consulted
> include GNU Toolchain project leadership, GNU Toolchain project release
> managers, GNU Toolchain project core developers, major vendors, active
> Sourceware / Overseers administrators, and both John Sullivan and Zoë Kooyman
> of the Free Software Foundation.

I see when people say major vendors in this list, I get the vibe that
this is a corporate take over and pushing out the community and small
developers in general. Rather than having open discussions about this,
everything was done in private.

>
> The GNU Toolchain Infrastructure project includes a Governing Board and a
> Technical Advisory Council[1].  The Governing Board is composed of
> representatives of the major donors and a representative from the GTI Technical
> Advisory Council.

I think the governing board should NOT have major donors at all. That
is bad just like a way to buy a seat to shut down other
converstations. That is very anti-democratic and very much
anti-open/free source ideals.
This has been a huge problem in politics in general so why extend it
to open source?
Also what is the definition of major donors? Since it is not given
here. Is it 1% of the total donated or is it 10k USD donated?

> The board will have fiscal accountability for spending, as
> other, similar foundations are organized.  The Technical Advisory Council will
> provide technical guidance and recommendations, and set the technical direction
> for the infrastructure project, in consultation with the GNU Toolchain
> community.  All meetings of the Governing Board and the Technical Advisory
> Council are open to non-member observers.  GTI welcomes all donors whose vision
> for GTI aligns with the GNU Toolchain and its role in the Free Software
> ecosystem.  The leadership and governance of the GNU Toolchain projects are not
> affected by the creation of GTI.

But both projects have a relationship and even overlap in goveernance.
That overlap and relationship is not even described on how it will
work.


>
> The Linux Foundation IT services have a long and respected history of hosting
> kernel.org for the Linux community with a robust set of infrastructure.  The
> GNU Toolchain serves a similar, critical role and has similar requirements to
> ensure its resiliency.  The Linux Foundation IT team has the experience and
> infrastructure to efficiently provide those services, and the Linux Foundation
> has graciously offered its assistance.
>
> Linux Foundation IT services plans for the GNU Toolchain include Git
> repositories, mailing lists, issue tracking, web sites, and CI/CD, implemented
> with strong authentication, attestation, and security posture.

I don't doubt LF technical experience. I am just thinking back to the
hack of kernel.org back in 2011 and how it was the IT folks who got
hacked rather than the developers ....
I wonder if LF and kernel.org learned their leasons from that hack.

> Utilizing the
> experience and infrastructure of the LF IT team that is already used by the
> Linux kernel community will provide the most effective solution and best
> experience for the GNU Toolchain developer community. By utilizing the same
> infrastructure, the resources of donors who support Free Software can be
> targeted at projects that provide unique value to the Free Software community.

The problem with LF is it is more controlled by corporations who do
the donatations rather than the community.
The governorance of LF is still pushed by donation controls rather
than folks on the ground.

> The GNU Toolchain projects are currently hosted on sourceware.org, funded and
> maintained by Red Hat, for which we are grateful.

Actually it is not maintained by RH at all. This is wrong describtion
of sourceware really.
In fact this is a huge disservice to the folks who have been
maintaining sourceware. Most have not been Redhat employees for years
now.

> Sourceware.org includes the
> core GNU Toolchain projects (GCC, GLIBC, GDB, and Binutils) as well as many
> other active and inactive projects.  The other projects hosted on
> sourceware.org are welcome to join the proposed services at LF IT, in whole or
> in part as would best suit their needs
>
> As with kernel.org, GTI has requested from the Linux Foundation IT that all
> software implementing the infrastructure for the GNU Toolchain projects must be
> Free Software.  If Free Software versions of necessary security tools are
> missing, GTI will work with Free Software supporters to develop Free Software
> alternatives.
>
> If ever the GNU Toolchain leadership determines that GTI and LF IT are not the
> appropriate partners for the project, the Linux Foundation has agreed that the
> GNU Toolchain is free to seek alternative financial support and/or
> infrastructure services, taking all assets with it.

"If ever" this seems too vague here and plus it seems like this was
planned without being in the open. And it gives off this is my project
and I want to control it only.

There are a few other issues I want to raise about infrastructure
projects going forward here:
* supply chain security
** This seems to push out the small developers and even developers who
don't want to do public key signing (I am included here).
** I get where corporations want to do this because they can track
where things come from. But this is very much anti-open/free source
ideals and very much anti-small developers
* bug tracking
** as I mentioned in my other email, bugzilla right now is the best
and only bug tracking system which statisfies the issue tracking for
GCC because of the fields/meta data
** Providing funding to folks working on (and releasing) bugzilla
might be a good resource for donations to go towards
* automated builds
** I see the sourceware folks have been getting a good automated build
system up and running
* Dejagnu improvements
** This would be another area where funding could go into and is very
much lacking
** There has been some effects in years past to improve there but
things have stalled or just died.
* Patch mangement
** this has always been a hot topic but many of the patch mangement
tools don't work with email systems
** Many new ones don't even touch emails and require people to use git
or a web page directly
** This could be an area where funding should go into
* Sourceware maintaince/security enchements
** hot topic: there seems like there are some decent plans proposed
already so I am not going to rehash them
* New ways of doing communication besides email and IRC
** BBB: seems like there are some decent plans proposed there so I am
not going to rehash them

I think in summary; "Where's the beef?" is all I can think of when I
read the GTI proposal. And how this was done in the private and in a
very anti-democratic way.

Thanks,
Andrew Pinski

PS I am not representing Marvell here at all and these are all of my
own thoughts.


>
> The GNU Toolchain Infrastructure project welcomes cooperation with other
> efforts to fund and improve the GNU Toolchain infrastructure.
>
> This proposal is an exciting opportunity for the GNU Toolchain and helps to
> ensure its continued vitality.
>
> Happy Hacking!
>
> Carlos O’Donell
> David Edelsohn
>
> [1] Current GTI TAC members are:
> Joel Brobecker
> Nick Clifton
> David Edelsohn
> Frank Ch. Eigler
> Jeff Law
> Martin Liška
> Jose Marchesi
> Simon Marchi
> Joseph Myers
> Carlos O'Donell
> Siddhesh Poyarekar
>

  parent reply	other threads:[~2022-09-29 21:13 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
2022-09-29 21:13 ` Andrew Pinski [this message]
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='CA+=Sn1m9jaj2TciLpivXqZErajOp3c=SVtkb8RbkaWWvVHTqTQ@mail.gmail.com' \
    --to=pinskia@gmail.com \
    --cc=carlos@redhat.com \
    --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).