Re: The GNU Toolchain Infrastructure Project

[Andrew Pinski <pinskia@gmail.com>]

On Fri, Sep 30, 2022 at 7:35 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 2022-09-29 17:13, Andrew Pinski via Overseers wrote:
> > 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.
>
> It's natural for GitHub and perhaps more other code hosting platforms to
> be on the OpenSSF board, it doesn't mean that they're on the advisory
> board for GTI or can influence its technical or ideological direction.
> I can't see why that should be a problem.
>
> > 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.
>
> It is a fact that most people on the steering committee, stewards, etc.
> are paid by corporations to work on the GNU toolchain.  Claiming that
> they're doing this for their company's interests rather than in the
> interest of the upstream project itself is unfair to them IMO.
>
> >> 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.
>
> AFAICT, "key" is overseers, gcc steering committee, fsf stewards and
> release managers.  You're a valuable member of the gcc community and if
> you think you should be included into one of these groups I'm sure it's
> something that the gcc steering committee can discuss.
>
> > 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 governing board influence is limited to fiscal discussions.
Then again "fiscal discussions" and discussions of where the money
goes is the same.
So this is the wrong argument to make.

> It is
> the responsibility of the TAC to mould the technical direction of the
> infrastructure.  We have the choice of moving away from LF if we feel
> that the governing board is unjustly blocking critical improvements to
> the technical direction without.

Again you think these two can be independent, Once a technical
decision is made, a monetarial one needs to be made which can be
stopped by the governing board. THIS IS A PROBLEM.
They cannot be independent. Because also at anytime the governing
board could just say fuck off. Unless there are bylaws in place which
have not been sent out anywhere; just this high level picture of what
will happen.
Again what is a "major" donor?

>
> > 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.
>
> That's just FUD :)

Again this was not FUD but rather pointing out what happened in the
past and trying to correct it. If LF/kernel.org folks didn't learn
about social engineering that well; then maybe they are not the best
people to do this.

>
> >> 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.
>
> AFAICT, all but one of the active overseers are Red Hat employees, I
> can't see the full list unfortunately, if one exists.

sourceware.org is registered by Ian, not a redhat employee.
There are at least 2 more which are not redhat employees too.
The HW is donated by RH yes. But majority of the folks are again not
RH employees still.

> The overseers
> archives too AFAICT were made public only recently and I only happened
> to discover it last week.

The archives have been public (or rather semi-public) for over 10
years now. It might not have been linked from anywhere but they have
existed for a long time now and have been public for that while too.
I am sorry you didn't know about the archives before; but that is on you.
Sounds like you have no idea how sourceware has function in general.

>
> The actual hardware is also owned and managed by Red Hat.
>
> > 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).
>
> It doesn't push out individual developers but I agree it will likely
> make it harder for developers who refuse to do public key signing.
>
> > ** 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
>
> I disagree.

Disagree all you want but it is the truth. Companies are pushing for
this because they want more control. I want less control and in the
hands of companies and more control in nobody really.

>
> > * 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
>
> FWIW, there are no viable alternatives to bugzilla at the moment and
> nothing's really intended to change here.

You didn't comment on funding parts but just saying bugzilla is it
because of no viable alternatives. This is funny because we want ways
of improving things and then you skip that point.

>
> Sid