Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

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.  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.

> 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 :)

>> 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.  The overseers 
archives too AFAICT were made public only recently and I only happened 
to discover it last week.

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.

> * 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.

Sid