public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
* The GNU Toolchain Infrastructure Project
@ 2022-09-27 19:59 Carlos O'Donell
  2022-09-28 14:06 ` Frank Ch. Eigler
                   ` (4 more replies)
  0 siblings, 5 replies; 53+ messages in thread
From: Carlos O'Donell @ 2022-09-27 19:59 UTC (permalink / raw)
  To: Overseers mailing list

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

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

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. 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 GNU Toolchain projects are currently hosted on sourceware.org, funded and
maintained by Red Hat, for which we are grateful.  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.

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


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-27 19:59 The GNU Toolchain Infrastructure Project Carlos O'Donell
@ 2022-09-28 14:06 ` Frank Ch. Eigler
  2022-09-29  9:51 ` Mark Wielaard
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 53+ messages in thread
From: Frank Ch. Eigler @ 2022-09-28 14:06 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Carlos O'Donell

Hi -


On Tue, Sep 27, 2022 at 03:59:32PM -0400, Carlos O'Donell via Overseers wrote:

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

We have heard from developers from some of the proposed-departing
projects that they assume that this would be a seamless change for
them.  (There may be a few unavoidable bits due to current uses of the
sourceware.org domain, but others can be solved by some combination of
redirection / mirroring.)  Is there an intent that every sourceware
service that these folks currently rely on would be duplicated?  Or
are there exceptions and/or infrastructure subsystem replacements
being proposed?


- FChE

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-27 19:59 The GNU Toolchain Infrastructure Project 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
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 53+ messages in thread
From: Mark Wielaard @ 2022-09-29  9:51 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Carlos O'Donell

Hi Carlos,

Thanks for describing your proposal publicly. It will take some time
to deconstruct it to see how we can mix-and-match the different
parts. But I really like our approach of creating a sourceware
infrastructure bug for each separate concern to see how we can resolve
it.

For now I just wanted to comment in this part which I think caused
some confusion and might have caused the impression some people were
working against each other.

On Tue, Sep 27, 2022 at 03:59:32PM -0400, Carlos O'Donell via Overseers wrote:
> The key stakeholders of the GNU Toolchain community have been
> proactively briefed and 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.

Now that I have talked to some of these people I think something went
wrong in the feedback loop. I think several people, me included,
didn't know what parts of their feedback was incorporated or not and
might have had a different understanding of how the proposal changed
over time and/or which parts of the proposals they had agreed to or
what others had been told. Or even if these proposals were still a
thing, because after initial contact there was no more communication.

Just speaking for myself when you contacted me at the start of the
year, I thought we agreed on the following feedback:

- We use the name GNU Toolchain Infrastructure because that is more
  popular and recognizable, but this really is about all of
  sourceware. Only later did I realize this is confusing and we should
  just talk about sourceware as a Free Software hosting project and
  not single out a few projects. This also helped when we started
  talking to the SFC and FSF because it made clear we didn't want to
  influence or control any of projects receiving infrastructure
  support.

- If we are going to seek additional funding for sourceware, which I
  didn't believe was really necessary at that point, we need a fiscal
  sponsor that is a 501(c)3 public charity to keep the community in
  control instead of any potential sponsors. That is why we are now in
  the process of becoming a SFC member project.

- This needs to be a public and open discussion with a public
  technical roadmap. Which is why we had those public roadmap
  discussions and why we now have builder.sourceware.org, upgraded
  patchwork.sourceware.org, inbox.sourceware.org, the
  sr.ht/~sourceware mirror, etc.

- It needs to be fully free software, I won't join a groups.io "list"
  or use google meet/docs or use github, etc. Which is why there is so
  much enthousiasm now for setting up a BBB server.

Hope that helps explain how we seemed to have ended up with different
sets of proposals for the future of sourceware which we now are trying
to combine again.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-27 19:59 The GNU Toolchain Infrastructure Project 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-10-19  5:47   ` Carlos O'Donell
  2022-09-29 21:13 ` Andrew Pinski
  2022-10-02 22:19 ` Mark Wielaard
  4 siblings, 2 replies; 53+ messages in thread
From: Jonathan Corbet @ 2022-09-29 14:45 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: overseers

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.

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

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

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

Thanks,

jon

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  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
  1 sibling, 2 replies; 53+ messages in thread
From: Joseph Myers @ 2022-09-29 17:13 UTC (permalink / raw)
  To: Jonathan Corbet via Overseers; +Cc: Carlos O'Donell, Jonathan Corbet

On Thu, 29 Sep 2022, Jonathan Corbet via Overseers wrote:

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

Regarding Bugzilla, also see the GTI TAC meeting (24 Aug 2022) recording 
at 23:37 to 25:44.  It's not clear what good solutions are right now for 
free software issue tracking, taking into account considerations such as:

* easy for anyone to submit and comment on bugs;

* protection against spam bug and comment submission (which is in tension 
with easy bug submission; we have restricted account creation, with people 
needing to email overseers to create an account on sourceware Bugzilla at 
all, or to email gcc-bugzilla-account-request to create an account on GCC 
Bugzilla from a large number of common email domains in which spammers can 
easily create accounts);

* configurability of the fields and values of those fields and other logic 
used in the bug tracker;

* ability to get a local copy of the tracker data (this is an area where 
Bugzilla is weak; you can probably do something with the REST API, but 
it's not designed to make it easy for someone to keep a local copy of all 
the data up to date the way git is);

* being an actively maintained project (that also being a concern for 
Bugzilla).

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-29 17:13   ` Joseph Myers
@ 2022-09-29 18:40     ` Elena Zannoni
  2022-09-29 18:54     ` Andrew Pinski
  1 sibling, 0 replies; 53+ messages in thread
From: Elena Zannoni @ 2022-09-29 18:40 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Joseph Myers, Jonathan Corbet

On 9/29/22 11:13 AM, Joseph Myers via Overseers wrote:
> On Thu, 29 Sep 2022, Jonathan Corbet via Overseers wrote:
> 
>> 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/
> 
> Regarding Bugzilla, also see the GTI TAC meeting (24 Aug 2022) recording 
> at 23:37 to 25:44.  It's not clear what good solutions are right now for 
> free software issue tracking, taking into account considerations such as:
> 
> * easy for anyone to submit and comment on bugs;
> 
> * protection against spam bug and comment submission (which is in tension 
> with easy bug submission; we have restricted account creation, with people 
> needing to email overseers to create an account on sourceware Bugzilla at 
> all, or to email gcc-bugzilla-account-request to create an account on GCC 
> Bugzilla from a large number of common email domains in which spammers can 
> easily create accounts);
> 
> * configurability of the fields and values of those fields and other logic 
> used in the bug tracker;
> 
> * ability to get a local copy of the tracker data (this is an area where 
> Bugzilla is weak; you can probably do something with the REST API, but 
> it's not designed to make it easy for someone to keep a local copy of all 
> the data up to date the way git is);
> 
> * being an actively maintained project (that also being a concern for 
> Bugzilla).
> 

BTW, I am just noticing an announcement to revive Bugzilla that came out
in the last month or so:

https://lists.bugzilla.org/pipermail/developers/2022-August/010231.html

elena


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-29 17:13   ` Joseph Myers
  2022-09-29 18:40     ` Elena Zannoni
@ 2022-09-29 18:54     ` Andrew Pinski
  1 sibling, 0 replies; 53+ messages in thread
From: Andrew Pinski @ 2022-09-29 18:54 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Joseph Myers, Jonathan Corbet

On Thu, Sep 29, 2022 at 10:13 AM Joseph Myers via Overseers
<overseers@sourceware.org> wrote:
>
> On Thu, 29 Sep 2022, Jonathan Corbet via Overseers wrote:
>
> > 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/
>
> Regarding Bugzilla, also see the GTI TAC meeting (24 Aug 2022) recording
> at 23:37 to 25:44.  It's not clear what good solutions are right now for
> free software issue tracking, taking into account considerations such as:
>
> * easy for anyone to submit and comment on bugs;
>
> * protection against spam bug and comment submission (which is in tension
> with easy bug submission; we have restricted account creation, with people
> needing to email overseers to create an account on sourceware Bugzilla at
> all, or to email gcc-bugzilla-account-request to create an account on GCC
> Bugzilla from a large number of common email domains in which spammers can
> easily create accounts);
>
> * configurability of the fields and values of those fields and other logic
> used in the bug tracker;

I don't think there is even a non-free bug tracking system which
conforms to these requirements which is not bugzilla.
github does not even support fields at all. It supports keywords but
they are not as powerful as the fields.
JIRA supports fields but searching requires you to know basically SQL.
gitlab issue tracking is similar to github but has some fields.

I looked into others and most don't have the (custom) fields support
and easy searchability.

I know the LLVM folks moved from bugzilla to github but that would be
backwards movement for GCC bug tracking. The LLVM folks are not as
active in their bug tracking system before as far as I could tell
unlike the way majority of the projects on sourceware have been.

Thanks,
Andrew Pinski

>
> * ability to get a local copy of the tracker data (this is an area where
> Bugzilla is weak; you can probably do something with the REST API, but
> it's not designed to make it easy for someone to keep a local copy of all
> the data up to date the way git is);
>
> * being an actively maintained project (that also being a concern for
> Bugzilla).
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-27 19:59 The GNU Toolchain Infrastructure Project Carlos O'Donell
                   ` (2 preceding siblings ...)
  2022-09-29 14:45 ` Jonathan Corbet
@ 2022-09-29 21:13 ` Andrew Pinski
  2022-09-30 14:35   ` Siddhesh Poyarekar
  2022-10-02 21:38   ` Mark Wielaard
  2022-10-02 22:19 ` Mark Wielaard
  4 siblings, 2 replies; 53+ messages in thread
From: Andrew Pinski @ 2022-09-29 21:13 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Carlos O'Donell

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
>

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  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:22     ` Christopher Faylor
  2022-10-02 21:38   ` Mark Wielaard
  1 sibling, 2 replies; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-09-30 14:35 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Andrew Pinski

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

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-30 14:35   ` Siddhesh Poyarekar
@ 2022-09-30 15:05     ` Andrew Pinski
  2022-09-30 15:51       ` Siddhesh Poyarekar
  2022-09-30 15:22     ` Christopher Faylor
  1 sibling, 1 reply; 53+ messages in thread
From: Andrew Pinski @ 2022-09-30 15:05 UTC (permalink / raw)
  To: Siddhesh Poyarekar; +Cc: Overseers mailing list

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

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-30 14:35   ` Siddhesh Poyarekar
  2022-09-30 15:05     ` Andrew Pinski
@ 2022-09-30 15:22     ` Christopher Faylor
  2022-09-30 15:34       ` Siddhesh Poyarekar
  1 sibling, 1 reply; 53+ messages in thread
From: Christopher Faylor @ 2022-09-30 15:22 UTC (permalink / raw)
  To: Siddhesh Poyarekar; +Cc: Overseers mailing list

On Fri, Sep 30, 2022 at 10:35:45AM -0400, Siddhesh Poyarekar wrote:
>>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.

Are the only corporations associated with the GTI those who have
employees working on the "GNU Toolchain"?  This argument only works,
IMO, if that is true.  Otherwise it could be construed as corporations
who have no direct stake in "GNU Toolchain" development influencing
development because they provide $$$.

cgf


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-30 15:22     ` Christopher Faylor
@ 2022-09-30 15:34       ` Siddhesh Poyarekar
  0 siblings, 0 replies; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-09-30 15:34 UTC (permalink / raw)
  To: Overseers mailing list

On 2022-09-30 11:22, Christopher Faylor wrote:
> On Fri, Sep 30, 2022 at 10:35:45AM -0400, Siddhesh Poyarekar wrote:
>>> 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.
> 
> Are the only corporations associated with the GTI those who have
> employees working on the "GNU Toolchain"?  This argument only works,
> IMO, if that is true.  Otherwise it could be construed as corporations
> who have no direct stake in "GNU Toolchain" development influencing
> development because they provide $$$.

The specific part I responded to referred to (AFAICT) the folks who have 
been working on the GTI proposal; they are all long time members of the 
GNU toolchain community.  Would sponsors have a similarly strong 
connection?  Likely not all of them, and IMO that's a good thing because 
it gives companies that are not comfortable (or don't have the means of) 
getting involved directly a way to contribute to the sustenance of a 
project.

It also gives them influence, but we have a considerable amount of 
control over that through the TAC, which is comprised of folks from the 
community.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-30 15:05     ` Andrew Pinski
@ 2022-09-30 15:51       ` Siddhesh Poyarekar
  2022-10-02 21:56         ` Mark Wielaard
  0 siblings, 1 reply; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-09-30 15:51 UTC (permalink / raw)
  To: Andrew Pinski; +Cc: Overseers mailing list

On 2022-09-30 11:05, Andrew Pinski wrote:
> 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.

Like I said, if there is an irresolvable conflict with the governing 
board, we can step away from the LF.

> Again what is a "major" donor?

I don't know, maybe someone else can answer this.

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

It's FUD because it's wild speculation and casting persistent doubt over 
someone based on a single past incident.  Unless you have credible 
reason to believe that they've not learned from the incident, you're 
only casting fear, uncertainty and doubt.

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

Funny that you call it semi-public (whatever that means) and then also 
say that it's on me that I didn't find the archives.  FWIW, I've 
deliberately looked for the archives in the past and not found it.  In 
any case, we digress.

> Sounds like you have no idea how sourceware has function in general.

Sounds like you're in a mood to make ridiculous comments.  Please 
consider being a bit more thoughtful in your responses.  Both you and I 
have been in this community for over a decade and statements like this 
are just immature.

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

Requiring signed commits does not have anything to do with software 
freedom.  In any case, that's a project-specific question.  You may 
discuss that within the gcc community whenever that question comes up there.

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

The GTI proposal talks about (1) sponsors and (2) an IT team that'll 
help us with maintenance and porting of what we currently have.  It's 
essentially an expansion of capacity.  In that context, bugzilla can 
move more or less unchanged.

Questions about funding improvements to bugzilla are things that we need 
to figure out as a community through TAC and it will compete for funding 
with anything else that we propose to do, e.g. improvements to 
patchwork, pre-commit CI, developer-triggered testing (e.g. 
build-many-glibcs), maybe even another patch review tool like gerrit or 
gitlab.  We're not there yet.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-29 21:13 ` Andrew Pinski
  2022-09-30 14:35   ` Siddhesh Poyarekar
@ 2022-10-02 21:38   ` Mark Wielaard
  1 sibling, 0 replies; 53+ messages in thread
From: Mark Wielaard @ 2022-10-02 21:38 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Andrew Pinski

Hi Andrew,

On Thu, Sep 29, 2022 at 02:13:29PM -0700, Andrew Pinski via Overseers wrote:
> "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.

Thanks for expressing your worries so clearly. I don't think I can
easily take those away. But I do like to discuss some of the
infrastructure points you are making:

> 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

I wish we had had some time to discuss this at the Cauldron. We now
have the infrastructure in place, not just for git commit signing, but
also for patch attestation through our public-inbox instance, on
sourceware. This does indeed raise the question whether projects
should require it:

https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide17

The slide simply say:

  Patch attestation

  Either:

  - Awesome way to "close" the secure software supply chain
  - Security "theater" that will exclude people and reduce code reviews
    to "has the submitter jumped through code signing hoops"

  [Example showed DKIM verification, but this can also be done for gpg
   signed email messages or special patchatt "signed" patch emails.]

My personal feeling is that we should make it possible, but not
require it.  This is also what the kernel does btw. Some commits or
patches are signed, but most are not.

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

I agree with this. I think the only real issue is that it is not easy
to replicate/mirror. I'll open a sourceware infrastructure bug for
that.

> * automated builds
> ** I see the sourceware folks have been getting a good automated build
> system up and running

https://builder.sourceware.org/ which provides pre-commit, CI and
full builders, putting results into bunsun at
https://builder.sourceware.org/testruns/ and in a git repo.

The infrastructure itself seems pretty solid now (doing more than
10.000 builds a month), although we can of course always use more
compute resources. But it really is up to the projects now to take
advantage of it and have some policies around test results and
analysis.

https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide5

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

That is an interesting topic. Maybe not directly infrastructure
related though. But there are indeed various projects on sourceware
using dejagnu. To be honest I don't really know how/what to improve
here.

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

We do have patchwork.sourceware.org and inbox.sourceware.org. There
were some discussions at Cauldron about how to use patchwork
effectively. You really need someone to act as patchwork queue
maintainer. With public-inbox and newer b4 you can also integrate with
patchwork. But it is an aqcuired taste.

Also patchwork could use some upstream help for new features to better
integrate it with our CI platform.

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

Could you expand on this a bit? What kind of communication would you
like to see? Or just a way to have a quick video chat with other
developers?

> ** BBB: seems like there are some decent plans proposed there so I am
> not going to rehash them

This is already being tracked in
https://sourceware.org/bugzilla/show_bug.cgi?id=29590

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

Lets fix that. The infrastructure points you brought up are important
and deserve to be discussed in public so they can be added to the
sourceware roadmap.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-30 15:51       ` Siddhesh Poyarekar
@ 2022-10-02 21:56         ` Mark Wielaard
  0 siblings, 0 replies; 53+ messages in thread
From: Mark Wielaard @ 2022-10-02 21:56 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Andrew Pinski, Siddhesh Poyarekar

Hi,

On Fri, Sep 30, 2022 at 11:51:03AM -0400, Siddhesh Poyarekar via Overseers wrote:
> On 2022-09-30 11:05, Andrew Pinski wrote:
> > > 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.
> 
> Funny that you call it semi-public (whatever that means) and then also say
> that it's on me that I didn't find the archives.  FWIW, I've deliberately
> looked for the archives in the past and not found it.  In any case, we
> digress.

You are both right. The overseers archives have always been publicly
archived (and go back to 1998), but till we setup public-inbox they
were not publicly advertised:
https://inbox.sourceware.org/overseers/YwJuV4e0I01sWxi0@wildebeest.org/

This was in part because we also handle account request on
overseers. It felt like a good idea to not make it easy for search
engines archive those. We now have a new (private, not archived)
account-requests list for that.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-27 19:59 The GNU Toolchain Infrastructure Project Carlos O'Donell
                   ` (3 preceding siblings ...)
  2022-09-29 21:13 ` Andrew Pinski
@ 2022-10-02 22:19 ` Mark Wielaard
  4 siblings, 0 replies; 53+ messages in thread
From: Mark Wielaard @ 2022-10-02 22:19 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Carlos O'Donell

Hi Carlos,

On Tue, Sep 27, 2022 at 03:59:32PM -0400, Carlos O'Donell via Overseers wrote:
> 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).

It would be really nice if there were representatives of the Linux
Foundation and OpenSSF on this list to discuss the details.

I saw Mike Dolan, SVP and GM of Projects of the Linux Foundation
comment on lwn: https://lwn.net/Articles/909726/

So I did respond there on how I hoped we could move forward with this:
https://lwn.net/Articles/909752/

And I saw that Zoë Kooyman, Executive Director of the Free Software
Foundation also replied to him: https://lwn.net/Articles/909765/

But it might be more efficient if we all just discussed directly with
each other on the overseers list.

I liked what Zoë said about transparency as to all the proposed
arrangements. It would be good if the actual proposed legal agreements
between LF, OpenSSF, sponsors and GTI [TAC] members were published.

Specifically so we can determine how various guarantees have been
made. For example the guarantee to only use the money to support Free
Software. To see what sponsors have been promised for their
donations. How this new governance structure exactly works. And how
GNU Toolchain leadership has been defined for purposes of determining
when/how assets can be transferred into some other financial
arrangement if we don't really like this arrangement after all.

Thanks,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-09-29 14:45 ` Jonathan Corbet
  2022-09-29 17:13   ` Joseph Myers
@ 2022-10-19  5:47   ` Carlos O'Donell
  1 sibling, 0 replies; 53+ messages in thread
From: Carlos O'Donell @ 2022-10-19  5:47 UTC (permalink / raw)
  To: Jonathan Corbet; +Cc: overseers

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.


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-12 13:18                           ` Florian Weimer
@ 2022-10-12 21:23                             ` Mark Wielaard
  0 siblings, 0 replies; 53+ messages in thread
From: Mark Wielaard @ 2022-10-12 21:23 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Mark Wielaard via Overseers, gcc, libc-alpha, gdb, binutils

Hi Florian,

On Wed, Oct 12, 2022 at 03:18:55PM +0200, Florian Weimer wrote:
> * Mark Wielaard via Overseers:
> > And it is a about having a public discussion.
> >
> > - Sourceware roadmap discussions
> >   https://sourceware.org/pipermail/overseers/2022q2/018453.html
> >   https://sourceware.org/pipermail/overseers/2022q2/018529.html
> >   https://sourceware.org/pipermail/overseers/2022q3/018636.html
> >   https://sourceware.org/pipermail/overseers/2022q3/018716.html
> 
> Overseers was a hidden list until recently:
> 
> <https://web.archive.org/web/20220826033101/https://sourceware.org/mailman/listinfo>

Right, it wasn't advertised, but it was public:
https://web.archive.org/web/20220826033101/https://sourceware.org/mailman/listinfo/overseers

There were a couple of lists that were public, but not advertised,
which changed when we setup our public-inbox instance:
https://inbox.sourceware.org/overseers/YwJuV4e0I01sWxi0@wildebeest.org/

This was in part because we also handle account request on
overseers. It felt like a good idea to not make it easy for search
engines archive those. We now have a new (private, not archived)
account-requests list for that.

> I'm pointing this out to show how difficult it is to build public
> consensus.  You might think you are doing it, but the view from the
> outside is probably quite different.

Yes, I certainly see your point. But we did also post to the 20 most
active sourceware project lists about some proposals. And some of the
posts about the roadmap and the discussion about joining the
conservancy even made it to new sites like lwn:

Sourceware – GNU Toolchain Infrastructure roadmap
https://lwn.net/Articles/898655/
Sourceware seeking support from the Software Freedom Conservancy
https://lwn.net/Articles/906502/

And as the archives show we did publicly discuss things and actually
answered any questions people had:

- Joining Software Freedom Conservancy as member project proposal
  https://sourceware.org/pipermail/overseers/2022q3/018802.html
- Full Sourceware SFC application text
  https://sourceware.org/pipermail/overseers/2022q3/018804.html
- Public SFC video chat meeting notes
  https://sourceware.org/pipermail/overseers/2022q3/018837.html
- Cauldron discussion notes and chat logs
  https://sourceware.org/pipermail/overseers/2022q3/018849.html

I really liked some of these discussions. Hopefully in the future we
can do quarterly sourceware BBB video chats about any infrastructure
issues people/projects have.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-12  8:00                         ` Mark Wielaard
  2022-10-12 13:18                           ` Florian Weimer
@ 2022-10-12 15:15                           ` Jonathan Corbet
  1 sibling, 0 replies; 53+ messages in thread
From: Jonathan Corbet @ 2022-10-12 15:15 UTC (permalink / raw)
  To: Mark Wielaard, David Edelsohn
  Cc: gcc, Overseers mailing list, libc-alpha, gdb, binutils

Mark Wielaard <mark@klomp.org> writes:

> Then lets just let the past be the past. Now that the proposal is
> public lets discuss it publicly. There have been various question
> about the details on the overseers list. Lets just discuss those and
> see how we can move forward.

Along those lines, I asked a few questions back in September:

  https://sourceware.org/pipermail/overseers/2022q3/018906.html

They seem relevant for anybody wanting to understand this proposal, and
the answers should be at the fingertips of the people putting it
together.  Any chance the rest of us could be enlightened?

Thanks,

jon

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  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
  1 sibling, 1 reply; 53+ messages in thread
From: Florian Weimer @ 2022-10-12 13:18 UTC (permalink / raw)
  To: Mark Wielaard via Overseers
  Cc: David Edelsohn, Mark Wielaard, gcc, libc-alpha, gdb, binutils

* Mark Wielaard via Overseers:

> Hi David,
>
> On Tue, Oct 11, 2022 at 01:14:50PM -0400, David Edelsohn wrote:
>> an alternative proposal? When were they allowed to participate in the
>> preparation of the "Sourceware" proposal, supposedly for their benefit?
>
> It wasn't really meant as an alternative proposal. And tt shouldn't be
> in conflict with finding alternative sources of funding, creating a
> technical advisory committee or having some managed services. And it
> is a about having a public discussion.
>
> - Sourceware roadmap discussions
>   https://sourceware.org/pipermail/overseers/2022q2/018453.html
>   https://sourceware.org/pipermail/overseers/2022q2/018529.html
>   https://sourceware.org/pipermail/overseers/2022q3/018636.html
>   https://sourceware.org/pipermail/overseers/2022q3/018716.html

Overseers was a hidden list until recently:

<https://web.archive.org/web/20220826033101/https://sourceware.org/mailman/listinfo>

I'm pointing this out to show how difficult it is to build public
consensus.  You might think you are doing it, but the view from the
outside is probably quite different.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
       [not found]                       ` <CAGWvnykKOF=A=LWJ=Rozqx03w3YoCaP+yZ3L8X5+9MFgJ3MO-g@mail.gmail.com>
  2022-10-11 18:12                         ` Frank Ch. Eigler
  2022-10-12  8:00                         ` Mark Wielaard
@ 2022-10-12 10:55                         ` Alexandre Oliva
  2 siblings, 0 replies; 53+ messages in thread
From: Alexandre Oliva @ 2022-10-12 10:55 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Mark Wielaard, gcc, Overseers mailing list, libc-alpha, gdb, binutils

On Oct 11, 2022, David Edelsohn <dje.gcc@gmail.com> wrote:

> open and available for conversations to clarify misunderstandings

Not useful when potential objectors are kept in the dark about the whole
thing.

> and have not used private conversations as public debating points nor for
> divisive purposes

The public claims of broad support used to put pressure for objectors to
give in seem to fit this pattern you deny, if not so much in seeding the
divide created by the then-secret proposal, but in bridging it.

The very purpose of private conversations was claimed by proponents of
the conversation as something to the effect of avoiding objections.

As for purporting key decisions as if in the hands of an advisory
committee, while the final decisions would rest in the hands of another
body whose members would be effectively buying the projects on the
cheap...

All of that, too, speaks for itself.


Anyway, this is all besides the point.  Whether or not there are
nefarious purposes behind it is besides the point.  The key point I
raise is that most people would support and accept something desirable
offered to them at no charge, but many might not upon finding that
there's a very steep price involved in the transaction.  There's no
evidence whatsoever that the costs have been conveyed along with the
dreams to the supposed supporters, so we'd better not take that alleged
support for granted.  The whole process was structured in a certain way,
explicitly for the purpose of sidelining objections.  That does not
inspire the very trust that would be required to agree to turn over
control over our infrastructure.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
       [not found]                       ` <CAGWvnykKOF=A=LWJ=Rozqx03w3YoCaP+yZ3L8X5+9MFgJ3MO-g@mail.gmail.com>
  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 15:15                           ` Jonathan Corbet
  2022-10-12 10:55                         ` Alexandre Oliva
  2 siblings, 2 replies; 53+ messages in thread
From: Mark Wielaard @ 2022-10-12  8:00 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Alexandre Oliva, gcc, Overseers mailing list, libc-alpha, gdb, binutils

Hi David,

On Tue, Oct 11, 2022 at 01:14:50PM -0400, David Edelsohn wrote:
> an alternative proposal? When were they allowed to participate in the
> preparation of the "Sourceware" proposal, supposedly for their benefit?

It wasn't really meant as an alternative proposal. And tt shouldn't be
in conflict with finding alternative sources of funding, creating a
technical advisory committee or having some managed services. And it
is a about having a public discussion.

- Sourceware roadmap discussions
  https://sourceware.org/pipermail/overseers/2022q2/018453.html
  https://sourceware.org/pipermail/overseers/2022q2/018529.html
  https://sourceware.org/pipermail/overseers/2022q3/018636.html
  https://sourceware.org/pipermail/overseers/2022q3/018716.html
- Joining Software Freedom Conservancy as member project proposal
  https://sourceware.org/pipermail/overseers/2022q3/018802.html
- Full Sourceware SFC application text
  https://sourceware.org/pipermail/overseers/2022q3/018804.html
- Public SFC video chat meeting notes
  https://sourceware.org/pipermail/overseers/2022q3/018837.html
- Cauldron discussion notes and chat logs
  https://sourceware.org/pipermail/overseers/2022q3/018849.html

> Those of us working on the GTI proposal have approached it with good
> intentions and engaged everyone in good faith.  We have not made statements
> maligning the motivations and intentions of those with different opinions,
> implying nefarious motives, nor making baseless accusations.  We have been
> open and available for conversations to clarify misunderstandings

Then lets just let the past be the past. Now that the proposal is
public lets discuss it publicly. There have been various question
about the details on the overseers list. Lets just discuss those and
see how we can move forward.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
       [not found]                       ` <CAGWvnykKOF=A=LWJ=Rozqx03w3YoCaP+yZ3L8X5+9MFgJ3MO-g@mail.gmail.com>
@ 2022-10-11 18:12                         ` Frank Ch. Eigler
  2022-10-12  8:00                         ` Mark Wielaard
  2022-10-12 10:55                         ` Alexandre Oliva
  2 siblings, 0 replies; 53+ messages in thread
From: Frank Ch. Eigler @ 2022-10-11 18:12 UTC (permalink / raw)
  To: Overseers mailing list
  Cc: Alexandre Oliva, David Edelsohn, gcc, libc-alpha, gdb,
	Mark Wielaard, binutils

Hi -

> [...] Where was a statement from key members of the GNU Toolchain
> projects -- the people who actually use the services and
> infrastructure on a day to day basis for their participation in the
> GNU Toolchain projects -- asking for an alternative proposal? When
> were they allowed to participate in the preparation of the
> "Sourceware" proposal, supposedly for their benefit?  [...]

This echoes a question asked during the Cauldron session.  I believe
it was during the second half, whose Zoom recording is for some reason
still not published.  Could you ask Jeremy to fix that please?

Anyway, to try to recount what I said then: the SFC proposal is
independent of the various guest projects.  It does not pretend to
speak for any of them.  It does not impose any changes on them.  All
the guests are just as welcome to come, stay, and leave, as they have
always been.  For this reason, it was not necessary to draw a
stakeholder map and conduct years-long negotiations behind the scenes.
Everyone has been invited to advise, in public, since August 30.


- FChE

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-07  8:57                   ` Mark Wielaard
  2022-10-11 13:24                     ` Siddhesh Poyarekar
@ 2022-10-11 15:58                     ` Alexandre Oliva
       [not found]                       ` <CAGWvnykKOF=A=LWJ=Rozqx03w3YoCaP+yZ3L8X5+9MFgJ3MO-g@mail.gmail.com>
  1 sibling, 1 reply; 53+ messages in thread
From: Alexandre Oliva @ 2022-10-11 15:58 UTC (permalink / raw)
  To: Mark Wielaard
  Cc: Siddhesh Poyarekar, Overseers mailing list, gdb, libc-alpha,
	binutils, gcc

On Oct  7, 2022, Mark Wielaard <mark@klomp.org> wrote:

> Hi Siddhesh,
> On Thu, 2022-10-06 at 17:07 -0400, Siddhesh Poyarekar wrote:
>> Could you clarify in what way you think the *scope* got changed
>> between 
>> the private communications and the proposal that actually got posted?

> Given that they were private I can only talk for myself:
> https://inbox.sourceware.org/overseers/Yz9dZWC9QIv+r4LH@elastic.org/T/#m22a52506bc116dbcb10c8cbfa8ed89510f4dc1b7
> But various people listed as "key stakeholders consulted" said they
> either didn't know anything about this, they were contacted but never
> got any details, or were only told about parts of it.

That makes me very concerned.

Negotiating a community agreement in secrecy is worrysome to boot, but
giving different stakeholders different views of what the agreement
supposedly amounts to is a political trick normally used to push an
agreement through that would have been rejected by a majority, even if
for different reasons.  By presenting different views to different
parties, and misrepresenting their support for those partial views as
support for the whole they didn't even know about, one might put enough
pressure to persuade other parties to drop their objections, if they
believe the claimed broad support.

Even I got presented two very different views of the proposal by two of
its lead proponents, with different motivations (which is reasonable)
but factually conflicting commitments (which is not).

This all taken together makes me conclude that the alleged support for
the proposal, claimed by its lead proponents, is not something that can
be counted on, or taken for granted.  It needs to be double-checked by
circulating publicly a proposal encompassing everything that the
proposal entails, and then seeing whether it's actually acceptable as a
whole.  Given the chosen strategy, I suspect it won't be.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-11 13:24                     ` Siddhesh Poyarekar
@ 2022-10-11 14:23                       ` Frank Ch. Eigler
  0 siblings, 0 replies; 53+ messages in thread
From: Frank Ch. Eigler @ 2022-10-11 14:23 UTC (permalink / raw)
  To: Overseers mailing list
  Cc: Mark Wielaard, Siddhesh Poyarekar, gdb, libc-alpha, binutils, gcc

Hi -

> [...]  As for the rest, it really is a question on whether all of
> sourceware will in the end be migrated over to LF, it's for the
> remaining projects to decide.  If we indeed have all projects on
> board [...]

"we" do not.  That option was taken off the table weeks ago.  For that
matter, I have not seen -any- project decisionmaking bodies formally
announce to/with their developer communities that they wished to move
away, only a few individuals who propose that this be done.

- FChE

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  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
  1 sibling, 1 reply; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-11 13:24 UTC (permalink / raw)
  To: Mark Wielaard, Overseers mailing list; +Cc: gdb, libc-alpha, binutils, gcc

On 2022-10-07 04:57, Mark Wielaard wrote:
> Given that they were private I can only talk for myself:
> https://inbox.sourceware.org/overseers/Yz9dZWC9QIv+r4LH@elastic.org/T/#m22a52506bc116dbcb10c8cbfa8ed89510f4dc1b7

I believe one of your concerns (alternatives for proprietary 
videoconferencing and list management for TAC) was acknowledged before 
you raised it in that email and is being worked on.

As for the rest, it really is a question on whether all of sourceware 
will in the end be migrated over to LF, it's for the remaining projects 
to decide.  If we indeed have all projects on board then I agree, 
perhaps we then need to ask Red Hat to hand sourceware over to the LF 
and call the project "Sourceware Infrastructure Project" or just Sourceware.

> But various people listed as "key stakeholders consulted" said they
> either didn't know anything about this, they were contacted but never
> got any details, or were only told about parts of it.

It would be nice to hear from these folks on what parts were withheld 
from them.

> That is precisely what we have been doing for the last couple of
> months. And we don't believe that is in conflict with finding
> alternative sources of funding, creating a technical advisory committee
> and/or possibly having some "managed services" where that makes sense.

That part is not in conflict, calling it the "Sourceware project" is.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-06 22:57                       ` Frank Ch. Eigler
@ 2022-10-11 13:02                         ` Siddhesh Poyarekar
  0 siblings, 0 replies; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-11 13:02 UTC (permalink / raw)
  To: Frank Ch. Eigler, Overseers mailing list
  Cc: Frank Ch. Eigler, gdb, Mark Wielaard, libc-alpha, binutils, gcc

On 2022-10-06 18:57, Frank Ch. Eigler wrote:
>> [...] so that we continue to have them involved in the technical
>> direction of GNU toolchain infrastructure?  [...]
> 
> "continue"?  If the nature & degree of involvement we had so far in
> the LF/GTI process is representative of the future, I'm not sure I can
> in good faith ask anyone to fund our time on that.  Given that you are
> listed as a TAC member, yet admitted being unclear on some details of
> the proposal itself, perhaps we're in the same boat.

Yes we are, in the sense that this is a proposal and the details are 
upon us (you're a listed member of TAC too) to help finalize.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-06 21:37                   ` Siddhesh Poyarekar
@ 2022-10-07 13:39                     ` Mark Wielaard
  0 siblings, 0 replies; 53+ messages in thread
From: Mark Wielaard @ 2022-10-07 13:39 UTC (permalink / raw)
  To: Siddhesh Poyarekar, Overseers mailing list, gcc, libc-alpha,
	binutils, gdb

Hi,

On Thu, 2022-10-06 at 17:37 -0400, Siddhesh Poyarekar wrote:
> Also as I responded to Mark, the technical details of the transition are 
> the responsibility of the GTI TAC (which you were invited to be member 
> of and you declined) and not the LF IT, although they'd be the ones 
> implementing and maintaining it.
> 
> We're at that stage at the moment where we look for consensus from the 
> project communities so that we understand if we can move all of 
> sourceware to LF IT or if we need both to coexist somehow.
> 
> Once we have a direction, we talk about what that transition would look 
> like and ask questions accordingly.  Are there services that you 
> absolutely cannot move to LF IT and why?  Why would you support (or 
> oppose) porting the wiki to something like readthedocs backed by a git repo?
> 
> I respect your outright rejection of the proposal because at least it is 
> clear that you don't have any stake in its fine tuning.

Lets try to make this a little less adversarial. This doesn't have to
be a clash of communities where there can be only one. Yes, the way
this was introduced caused things to become very contentious. But at
Cauldron we also agreed to bring this proposal to the overseers list
and discuss it together. Of course we can coexist. Lets do a reset. Now
that the plans are more public there will hopefully be less opportunity
for speculation and misunderstandings. But there are still some unclear
details and people have had various (unanswered) questions. It would be
good to get answers to the questions people asked on overseers. And it
would be great if the GTI TAC members discussed how they see the
technical details of various services on the overseers list. We can
then file specific sourceware infrastructure bugs to track the various
technical needs from a community perspective. And hopefully we can
then, as one community, take up shared responsibility of how to move
things forward together.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-06 21:07                 ` Siddhesh Poyarekar
  2022-10-06 21:36                   ` Frank Ch. Eigler
@ 2022-10-07  8:57                   ` Mark Wielaard
  2022-10-11 13:24                     ` Siddhesh Poyarekar
  2022-10-11 15:58                     ` Alexandre Oliva
  1 sibling, 2 replies; 53+ messages in thread
From: Mark Wielaard @ 2022-10-07  8:57 UTC (permalink / raw)
  To: Siddhesh Poyarekar, Overseers mailing list; +Cc: gdb, libc-alpha, binutils, gcc

Hi Siddhesh,

On Thu, 2022-10-06 at 17:07 -0400, Siddhesh Poyarekar wrote:
> Could you clarify in what way you think the *scope* got changed
> between 
> the private communications and the proposal that actually got posted?

Given that they were private I can only talk for myself:
https://inbox.sourceware.org/overseers/Yz9dZWC9QIv+r4LH@elastic.org/T/#m22a52506bc116dbcb10c8cbfa8ed89510f4dc1b7
But various people listed as "key stakeholders consulted" said they
either didn't know anything about this, they were contacted but never
got any details, or were only told about parts of it.

> the proposal details being open-ended is by design.
> 
> > That is why we are trying to collect all details and file sourceware
> > infrastructure bugs to track the various technical needs from a
> 
> Fair enough.
> 
> > community perspective. But it would be really nice to hear directly
> > from the Linux Foundation and the OpenSSF about what exactly they are
> > proposing, which parts of the proposal are mandatory, which can be
> > mixed and matched, and how they see this working together with
> > Sourceware becoming a Software Freedom Conservancy member
> > project.
> 
> You and others have been repeating "sourceware as a project" in a 
> community owned sense as a truth for a while now but it really isn't. 
> It is Red Hat owned infrastructure that is maintained by volunteers.  It 
> is unquestioningly a community (and I'm proud part of it as someone who 
> maintains the patchwork instance), but that's not the same thing as 
> being an independent project that can do agreements and sign up for 
> memberships.
> [...]
> "sourceware overseers" could become a body that maintains sourceware and 
> is able to get funding through SFC for its activities?

That is precisely what we have been doing for the last couple of
months. And we don't believe that is in conflict with finding
alternative sources of funding, creating a technical advisory committee
and/or possibly having some "managed services" where that makes sense.

Some more background:

- Sourceware roadmap discussions
  https://sourceware.org/pipermail/overseers/2022q2/018453.html
  https://sourceware.org/pipermail/overseers/2022q2/018529.html
  https://sourceware.org/pipermail/overseers/2022q3/018636.html
  https://sourceware.org/pipermail/overseers/2022q3/018716.html
- Joining Software Freedom Conservancy as member project proposal
  https://sourceware.org/pipermail/overseers/2022q3/018802.html
- Full Sourceware SFC application text
  https://sourceware.org/pipermail/overseers/2022q3/018804.html
- Public SFC video chat meeting notes
  https://sourceware.org/pipermail/overseers/2022q3/018837.html
- Cauldron discussion notes and chat logs
  https://sourceware.org/pipermail/overseers/2022q3/018849.html

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-06 21:44                     ` Siddhesh Poyarekar
@ 2022-10-06 22:57                       ` Frank Ch. Eigler
  2022-10-11 13:02                         ` Siddhesh Poyarekar
  0 siblings, 1 reply; 53+ messages in thread
From: Frank Ch. Eigler @ 2022-10-06 22:57 UTC (permalink / raw)
  To: Overseers mailing list
  Cc: Frank Ch. Eigler, Siddhesh Poyarekar, gdb, Mark Wielaard,
	libc-alpha, binutils, gcc

Hi -

> [...] so that we continue to have them involved in the technical
> direction of GNU toolchain infrastructure?  [...]

"continue"?  If the nature & degree of involvement we had so far in
the LF/GTI process is representative of the future, I'm not sure I can
in good faith ask anyone to fund our time on that.  Given that you are
listed as a TAC member, yet admitted being unclear on some details of
the proposal itself, perhaps we're in the same boat.

I cannot speak for the toolchain development community -- and have no
idea who honestly can -- but I suspect that some of the numerous
outstanding questions are material to their eventual decisionmaking on
moving their project to a new host - or staying.

- FChE

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-06 21:36                   ` Frank Ch. Eigler
@ 2022-10-06 21:44                     ` Siddhesh Poyarekar
  2022-10-06 22:57                       ` Frank Ch. Eigler
  0 siblings, 1 reply; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-06 21:44 UTC (permalink / raw)
  To: Frank Ch. Eigler, Overseers mailing list
  Cc: Mark Wielaard, gdb, libc-alpha, binutils, gcc

On 2022-10-06 17:36, Frank Ch. Eigler wrote:
>> [...] Or alternatively, "sourceware overseers" could become a body
>> that maintains sourceware and is able to get funding through SFC for
>> its activities?
> 
> Great idea -- and this is roughly what's happening.  This "body"
> consisting of key individuals has invited other folks interested in
> helping with or helping guide the upkeep of shared sourceware
> infrastructure to join us.

Here's another crazy idea on those lines then: how about having SFC fund 
sourceware overseers' time on TAC (in addition to, perhaps consulting 
tasks like independent security audits so that we have more eyes on the 
infrastructure) so that we continue to have them involved in the 
technical direction of GNU toolchain infrastructure?  That is of course 
for overseers who are actually able to accept payments from the SFC for 
such involvement.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-04 14:19           ` Frank Ch. Eigler
  2022-10-04 14:33             ` Siddhesh Poyarekar
@ 2022-10-06 21:42             ` Alexandre Oliva
  1 sibling, 0 replies; 53+ messages in thread
From: Alexandre Oliva @ 2022-10-06 21:42 UTC (permalink / raw)
  To: Frank Ch. Eigler via Libc-alpha
  Cc: Overseers mailing list, Frank Ch. Eigler, gcc, gdb,
	Mark Wielaard, Frank Ch. Eigler, binutils

On Oct  4, 2022, "Frank Ch. Eigler via Libc-alpha" <libc-alpha@sourceware.org> wrote:

> What aspects of the gnu toolchain are open to being funded via the
> LF/GTI proposal, -other than- the vast majority of the funds being
> redirected to its own managed services infrastructure?

Hear, hear,

I see a number of people, myself included, who are concerned that this
LF "offer" amounts to a power-grab, to use the "donations" as bait to
bring us into a trap in which our projects would be under control of a
body that has seats for sale, effectively "buying" the projects on the
cheap.


One way to significantly alleviate these concerns would be to test
whether the funds can be spent on infrastructure that's not under their
control, i.e., whether it's an investment, or possibly a gift that would
enable us to expand our autonomy rather than curtail it.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-06 20:12                 ` Christopher Faylor
@ 2022-10-06 21:37                   ` Siddhesh Poyarekar
  2022-10-07 13:39                     ` Mark Wielaard
  0 siblings, 1 reply; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-06 21:37 UTC (permalink / raw)
  To: Mark Wielaard, Overseers mailing list, gcc, libc-alpha, binutils, gdb

On 2022-10-06 16:12, Christopher Faylor via Overseers wrote:
> The silence from the proponents of this project is puzzling.  I wonder
> if this means there are more non-public negotiations going on somewhere,
> leaving the community out of the loop.

The proponents of this project are members of the GNU toolchain 
communities.  We approached the LF with the permission of the FSF to 
explore infrastructure funding solutions that would work for our 
communities.  The proposal has been made in response to our request, so 
we need to tell them what we need and not the other way around.

Also as I responded to Mark, the technical details of the transition are 
the responsibility of the GTI TAC (which you were invited to be member 
of and you declined) and not the LF IT, although they'd be the ones 
implementing and maintaining it.

We're at that stage at the moment where we look for consensus from the 
project communities so that we understand if we can move all of 
sourceware to LF IT or if we need both to coexist somehow.

Once we have a direction, we talk about what that transition would look 
like and ask questions accordingly.  Are there services that you 
absolutely cannot move to LF IT and why?  Why would you support (or 
oppose) porting the wiki to something like readthedocs backed by a git repo?

I respect your outright rejection of the proposal because at least it is 
clear that you don't have any stake in its fine tuning.

For everyone else, it's a proposal.  If there are changes you'd like to 
see in it, which will result in it being acceptable for you, please feel 
free to convey that.  If you think it is unnecessary for your project 
and that sourceware in its current state and vision is sufficient for 
your needs, please state that clearly too.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-06 21:07                 ` Siddhesh Poyarekar
@ 2022-10-06 21:36                   ` Frank Ch. Eigler
  2022-10-06 21:44                     ` Siddhesh Poyarekar
  2022-10-07  8:57                   ` Mark Wielaard
  1 sibling, 1 reply; 53+ messages in thread
From: Frank Ch. Eigler @ 2022-10-06 21:36 UTC (permalink / raw)
  To: Overseers mailing list
  Cc: Mark Wielaard, Siddhesh Poyarekar, gdb, libc-alpha, binutils, gcc

Hi -

> [...] Or alternatively, "sourceware overseers" could become a body
> that maintains sourceware and is able to get funding through SFC for
> its activities?

Great idea -- and this is roughly what's happening.  This "body"
consisting of key individuals has invited other folks interested in
helping with or helping guide the upkeep of shared sourceware
infrastructure to join us.

- FChE


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-06 20:02               ` Mark Wielaard
  2022-10-06 20:12                 ` Christopher Faylor
@ 2022-10-06 21:07                 ` Siddhesh Poyarekar
  2022-10-06 21:36                   ` Frank Ch. Eigler
  2022-10-07  8:57                   ` Mark Wielaard
  1 sibling, 2 replies; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-06 21:07 UTC (permalink / raw)
  To: Mark Wielaard, Overseers mailing list; +Cc: gdb, libc-alpha, binutils, gcc

On 2022-10-06 16:02, Mark Wielaard wrote:
>> I had in fact missed the websites mention, sorry I overreacted to your
>> comment.  In that case, I don't know if the GNU websites are actually part
>> of this proposal.
> 
> No worries. It seems everybody is somewhat unclear on the details of
> this proposal. Making it hard for people not to speculate a
> little. And it seems the scope changed between when various "key
> stakeholders" were informed, the LF/IT presentation, the Cauldron talk
> and what eventually got posted.

I had not noticed the mention of websites in the proposal, which is why 
I was taken aback by its mention here.  That oversight is my fault, 
nothing to do with the proposal itself.

Could you clarify in what way you think the *scope* got changed between 
the private communications and the proposal that actually got posted? 
The technical details (which is different from scope) were never meant 
to be baked in, that's for the TAC to agree upon.  In that sense, the 
proposal details being open-ended is by design.

> That is why we are trying to collect all details and file sourceware
> infrastructure bugs to track the various technical needs from a

Fair enough.

> community perspective. But it would be really nice to hear directly
> from the Linux Foundation and the OpenSSF about what exactly they are
> proposing, which parts of the proposal are mandatory, which can be
> mixed and matched, and how they see this working together with
> Sourceware becoming a Software Freedom Conservancy member
> project.

You and others have been repeating "sourceware as a project" in a 
community owned sense as a truth for a while now but it really isn't. 
It is Red Hat owned infrastructure that is maintained by volunteers.  It 
is unquestioningly a community (and I'm proud part of it as someone who 
maintains the patchwork instance), but that's not the same thing as 
being an independent project that can do agreements and sign up for 
memberships.

Maybe Red Hat could spin off a sourceware project in some form that is 
actually capable of becoming a SFC member?  Or alternatively, 
"sourceware overseers" could become a body that maintains sourceware and 
is able to get funding through SFC for its activities?

Thanks,
Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-06 20:02               ` Mark Wielaard
@ 2022-10-06 20:12                 ` Christopher Faylor
  2022-10-06 21:37                   ` Siddhesh Poyarekar
  2022-10-06 21:07                 ` Siddhesh Poyarekar
  1 sibling, 1 reply; 53+ messages in thread
From: Christopher Faylor @ 2022-10-06 20:12 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: Overseers mailing list, gcc, libc-alpha, binutils, gdb

On Thu, Oct 06, 2022 at 10:02:19PM +0200, Mark Wielaard wrote:
>...But it would be really nice to hear directly from the Linux
>Foundation and the OpenSSF about what exactly they are proposing, which
>parts of the proposal are mandatory, which can be mixed and matched,
>and how they see this working together with Sourceware becoming a
>Software Freedom Conservancy member project.

Indeed.

The silence from the proponents of this project is puzzling.  I wonder
if this means there are more non-public negotiations going on somewhere,
leaving the community out of the loop.

cgf


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  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:07                 ` Siddhesh Poyarekar
  0 siblings, 2 replies; 53+ messages in thread
From: Mark Wielaard @ 2022-10-06 20:02 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Siddhesh Poyarekar, gdb, libc-alpha, binutils, gcc

Hi Siddhesh,

On Tue, Oct 04, 2022 at 03:10:35PM -0400, Siddhesh Poyarekar via Overseers wrote:
> > We do take this proposal, and all other suggestions people make about
> > the sourceware infrastructure, seriously, but a lot of details of this
> > proposal are still unclear. We are trying to get as much details as
> > possible so we can see how this fits into the current sourceware
> > roadmap, get a better understanding of the budgetary needs, file
> > sourceware infrastructure bugs with those details. All to get a better
> > understanding what the real needs are and document the necessary steps
> > forward.
> 
> I had in fact missed the websites mention, sorry I overreacted to your
> comment.  In that case, I don't know if the GNU websites are actually part
> of this proposal.

No worries. It seems everybody is somewhat unclear on the details of
this proposal. Making it hard for people not to speculate a
little. And it seems the scope changed between when various "key
stakeholders" were informed, the LF/IT presentation, the Cauldron talk
and what eventually got posted.

That is why we are trying to collect all details and file sourceware
infrastructure bugs to track the various technical needs from a
community perspective. But it would be really nice to hear directly
from the Linux Foundation and the OpenSSF about what exactly they are
proposing, which parts of the proposal are mandatory, which can be
mixed and matched, and how they see this working together with
Sourceware becoming a Software Freedom Conservancy member
project.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-04 19:05           ` Mark Wielaard
@ 2022-10-04 19:10             ` Siddhesh Poyarekar
  2022-10-06 20:02               ` Mark Wielaard
  0 siblings, 1 reply; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-04 19:10 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: Overseers mailing list, gdb, libc-alpha, binutils, gcc

On 2022-10-04 15:05, Mark Wielaard wrote:
> I did indeed. Both the proposal and these minutes mention migrating
> websites without mentioning any specifics. Knowing which websites are
> meant and why they need migration is useful information.
> 
> The FSF tech team is helping us coordinating things on overseers to
> help with release archives, mirroring, backups and sourceware
> continuity. If this is about migrating websites currently on
> www.gnu.org then talking to the FSF tech team does make sense. If it
> isn't about that, then we will simply note that and move one.
> 
> We do take this proposal, and all other suggestions people make about
> the sourceware infrastructure, seriously, but a lot of details of this
> proposal are still unclear. We are trying to get as much details as
> possible so we can see how this fits into the current sourceware
> roadmap, get a better understanding of the budgetary needs, file
> sourceware infrastructure bugs with those details. All to get a better
> understanding what the real needs are and document the necessary steps
> forward.

I had in fact missed the websites mention, sorry I overreacted to your 
comment.  In that case, I don't know if the GNU websites are actually 
part of this proposal.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  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
  1 sibling, 1 reply; 53+ messages in thread
From: Mark Wielaard @ 2022-10-04 19:05 UTC (permalink / raw)
  To: Siddhesh Poyarekar; +Cc: Overseers mailing list, gdb, libc-alpha, binutils, gcc

Hi Siddhesh,

On Tue, Oct 04, 2022 at 01:17:14PM -0400, Siddhesh Poyarekar wrote:
> On 2022-10-04 13:10, Christopher Faylor wrote:
> > On Tue, Oct 04, 2022 at 09:46:08AM -0400, Siddhesh Poyarekar wrote:
> > > I made and shared this copy to dispel any further false speculation of
> > > scope creep of the GTI proposal.
> > 
> > Who is doing the false speculation?  Do you have a mailing list link?
> > It would be interesting to know who's got it wrong.
> 
> Mark asked upthread if content on gnu.org is also going to be migrated over

I did indeed. Both the proposal and these minutes mention migrating
websites without mentioning any specifics. Knowing which websites are
meant and why they need migration is useful information.

The FSF tech team is helping us coordinating things on overseers to
help with release archives, mirroring, backups and sourceware
continuity. If this is about migrating websites currently on
www.gnu.org then talking to the FSF tech team does make sense. If it
isn't about that, then we will simply note that and move one.

We do take this proposal, and all other suggestions people make about
the sourceware infrastructure, seriously, but a lot of details of this
proposal are still unclear. We are trying to get as much details as
possible so we can see how this fits into the current sourceware
roadmap, get a better understanding of the budgetary needs, file
sourceware infrastructure bugs with those details. All to get a better
understanding what the real needs are and document the necessary steps
forward.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-04 17:17         ` Siddhesh Poyarekar
@ 2022-10-04 18:42           ` Christopher Faylor
  2022-10-04 19:05           ` Mark Wielaard
  1 sibling, 0 replies; 53+ messages in thread
From: Christopher Faylor @ 2022-10-04 18:42 UTC (permalink / raw)
  To: Siddhesh Poyarekar
  Cc: Overseers mailing list, gdb, Mark Wielaard, libc-alpha, binutils, gcc

On Tue, Oct 04, 2022 at 01:17:14PM -0400, Siddhesh Poyarekar wrote:
>On 2022-10-04 13:10, Christopher Faylor wrote:
>> On Tue, Oct 04, 2022 at 09:46:08AM -0400, Siddhesh Poyarekar wrote:
>> > I made and shared this copy to dispel any further false speculation of
>> > scope creep of the GTI proposal.
>> 
>> Who is doing the false speculation?  Do you have a mailing list link?
>> It would be interesting to know who's got it wrong.
>
>Mark asked upthread if content on gnu.org is also going to be migrated over
>based on sharing of meeting minutes on the gnu.org domain.

I think you mean:

>>On Sun Oct 2 20:47:49 GMT 2022, Mark Wielaard wrote:
>This does raise the question if you are also proposing migrating
>non-sourceware services for projects like the websites of various of
>the GNU projects on www.gnu.org or the release archives at the GNU ftp
>server (and mirrors) those projects use.

Reading the meeting logs (I wasn't there and left this project shortly
after the meeting) I don't see anything that directly answers Mark's
question.  So, to me, this seems like an innocent request for
clarification rather than an attempt to push a false speculation.

There's no need to go down this rabbit hole, though.  Thanks for
clarifying.

cgf


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  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
  0 siblings, 2 replies; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-04 17:17 UTC (permalink / raw)
  To: Overseers mailing list, gdb, Mark Wielaard, libc-alpha, binutils, gcc



On 2022-10-04 13:10, Christopher Faylor wrote:
> On Tue, Oct 04, 2022 at 09:46:08AM -0400, Siddhesh Poyarekar wrote:
>> I made and shared this copy to dispel any further false speculation of
>> scope creep of the GTI proposal.
> 
> Who is doing the false speculation?  Do you have a mailing list link?
> It would be interesting to know who's got it wrong.
> 

Mark asked upthread if content on gnu.org is also going to be migrated 
over based on sharing of meeting minutes on the gnu.org domain.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-04 13:46     ` Siddhesh Poyarekar
  2022-10-04 14:01       ` Frank Ch. Eigler
@ 2022-10-04 17:10       ` Christopher Faylor
  2022-10-04 17:17         ` Siddhesh Poyarekar
  1 sibling, 1 reply; 53+ messages in thread
From: Christopher Faylor @ 2022-10-04 17:10 UTC (permalink / raw)
  To: Siddhesh Poyarekar
  Cc: Overseers mailing list, gdb, Mark Wielaard, libc-alpha, binutils, gcc

On Tue, Oct 04, 2022 at 09:46:08AM -0400, Siddhesh Poyarekar wrote:
>I made and shared this copy to dispel any further false speculation of
>scope creep of the GTI proposal.

Who is doing the false speculation?  Do you have a mailing list link?
It would be interesting to know who's got it wrong.


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-04 14:55                 ` Siddhesh Poyarekar
@ 2022-10-04 15:07                   ` Frank Ch. Eigler
  0 siblings, 0 replies; 53+ messages in thread
From: Frank Ch. Eigler @ 2022-10-04 15:07 UTC (permalink / raw)
  To: Siddhesh Poyarekar
  Cc: Frank Ch. Eigler, Overseers mailing list, gdb, Mark Wielaard,
	libc-alpha, binutils, gcc

Hi -

> > I'm afraid I don't understand then what the point of comparing to LLVM
> > with respect to competitiveness or freedom was.  AIUI, infrastructure
> > is an enabler, not really a competitive differentiator.
>
> I suppose that's a difference in our perception then.  I think of
> infrastructure as an accelerator and not just an enabler, which
> makes it a serious competitive differentiator.

Okay, we'd love to hear ideas for infrastructure changes that would
result in accelerating your work as developers.


- FChE

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-04 14:41               ` Frank Ch. Eigler
@ 2022-10-04 14:55                 ` Siddhesh Poyarekar
  2022-10-04 15:07                   ` Frank Ch. Eigler
  0 siblings, 1 reply; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-04 14:55 UTC (permalink / raw)
  To: Frank Ch. Eigler
  Cc: Overseers mailing list, Frank Ch. Eigler, gdb, Mark Wielaard,
	libc-alpha, binutils, gcc

On 2022-10-04 10:41, Frank Ch. Eigler wrote:
> I'm afraid I don't understand then what the point of comparing to LLVM
> with respect to competitiveness or freedom was.  AIUI, infrastructure
> is an enabler, not really a competitive differentiator.

I suppose that's a difference in our perception then.  I think of 
infrastructure as an accelerator and not just an enabler, which makes it 
a serious competitive differentiator.

>> Do you think the current proposal is not an upgrade to what we
>> currently have?
> 
> I don't know.  I am not under the impression that infrastructure is
> holding back development on any of these projects.  Further, I suspect
> that if the communities were given a choice to direct the sponsors'
> generous donations toward new development type work, they may well
> prefer that.  Is that possibility on offer?

Not in this proposal AFAICT (I have exactly the same information as you 
do) but IMO it would be great if it happens and the project communities 
accept it.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-04 14:33             ` Siddhesh Poyarekar
@ 2022-10-04 14:41               ` Frank Ch. Eigler
  2022-10-04 14:55                 ` Siddhesh Poyarekar
  0 siblings, 1 reply; 53+ messages in thread
From: Frank Ch. Eigler @ 2022-10-04 14:41 UTC (permalink / raw)
  To: Siddhesh Poyarekar
  Cc: Overseers mailing list, Frank Ch. Eigler, gdb, Mark Wielaard,
	libc-alpha, binutils, gcc

Hi -

> > > I don't see a risk to freedom.  The GNU toolchain is quite underfunded
> > > compared to llvm/clang and IMO it's a major risk to maintain status quo on
> > > that front.  The GTI opens new avenues for funding aspects of the GNU
> > > toolchain without affecting its core governance.
> > 
> > What aspects of the gnu toolchain are open to being funded via the
> > LF/GTI proposal, -other than- the vast majority of the funds being
> > redirected to its own managed services infrastructure?
> 
> This current proposal is limited to infrastructure, which has ever-growing
> needs.

I'm afraid I don't understand then what the point of comparing to LLVM
with respect to competitiveness or freedom was.  AIUI, infrastructure
is an enabler, not really a competitive differentiator.


> Do you think the current proposal is not an upgrade to what we
> currently have?

I don't know.  I am not under the impression that infrastructure is
holding back development on any of these projects.  Further, I suspect
that if the communities were given a choice to direct the sponsors'
generous donations toward new development type work, they may well
prefer that.  Is that possibility on offer?


- FChE


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  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-06 21:42             ` Alexandre Oliva
  1 sibling, 1 reply; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-04 14:33 UTC (permalink / raw)
  To: Frank Ch. Eigler, Overseers mailing list
  Cc: Frank Ch. Eigler, gdb, Mark Wielaard, libc-alpha, binutils, gcc

On 2022-10-04 10:19, Frank Ch. Eigler wrote:
>> I don't see a risk to freedom.  The GNU toolchain is quite underfunded
>> compared to llvm/clang and IMO it's a major risk to maintain status quo on
>> that front.  The GTI opens new avenues for funding aspects of the GNU
>> toolchain without affecting its core governance.
> 
> What aspects of the gnu toolchain are open to being funded via the
> LF/GTI proposal, -other than- the vast majority of the funds being
> redirected to its own managed services infrastructure?

This current proposal is limited to infrastructure, which has 
ever-growing needs.  Do you think the current proposal is not an upgrade 
to what we currently have?

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-04 14:13         ` Siddhesh Poyarekar
@ 2022-10-04 14:19           ` Frank Ch. Eigler
  2022-10-04 14:33             ` Siddhesh Poyarekar
  2022-10-06 21:42             ` Alexandre Oliva
  0 siblings, 2 replies; 53+ messages in thread
From: Frank Ch. Eigler @ 2022-10-04 14:19 UTC (permalink / raw)
  To: Overseers mailing list
  Cc: Frank Ch. Eigler, Siddhesh Poyarekar, gdb, Mark Wielaard,
	libc-alpha, binutils, gcc

Hi -

> > > [...] I think the LF proposal is the best long term way forward for
> > > the GNU toolchain projects to remain competitive *and* Free. [...]
> > 
> > Can you elaborate what risks in terms of competitiveness or freedom
> > you foresee with the status quo?  This is the first I recall hearing
> > of this concern.
> 
> I don't see a risk to freedom.  The GNU toolchain is quite underfunded
> compared to llvm/clang and IMO it's a major risk to maintain status quo on
> that front.  The GTI opens new avenues for funding aspects of the GNU
> toolchain without affecting its core governance.

What aspects of the gnu toolchain are open to being funded via the
LF/GTI proposal, -other than- the vast majority of the funds being
redirected to its own managed services infrastructure?

- FChE


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  2022-10-04 14:01       ` Frank Ch. Eigler
@ 2022-10-04 14:13         ` Siddhesh Poyarekar
  2022-10-04 14:19           ` Frank Ch. Eigler
  0 siblings, 1 reply; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-04 14:13 UTC (permalink / raw)
  To: Frank Ch. Eigler, Overseers mailing list
  Cc: gdb, Mark Wielaard, libc-alpha, binutils, gcc

On 2022-10-04 10:01, Frank Ch. Eigler wrote:
> Hi -
> 
>> [...] I think the LF proposal is the best long term way forward for
>> the GNU toolchain projects to remain competitive *and* Free. [...]
> 
> Can you elaborate what risks in terms of competitiveness or freedom
> you foresee with the status quo?  This is the first I recall hearing
> of this concern.

I don't see a risk to freedom.  The GNU toolchain is quite underfunded 
compared to llvm/clang and IMO it's a major risk to maintain status quo 
on that front.  The GTI opens new avenues for funding aspects of the GNU 
toolchain without affecting its core governance.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  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 17:10       ` Christopher Faylor
  1 sibling, 1 reply; 53+ messages in thread
From: Frank Ch. Eigler @ 2022-10-04 14:01 UTC (permalink / raw)
  To: Overseers mailing list
  Cc: Siddhesh Poyarekar, gdb, Mark Wielaard, libc-alpha, binutils, gcc

Hi -

> [...] I think the LF proposal is the best long term way forward for
> the GNU toolchain projects to remain competitive *and* Free. [...]

Can you elaborate what risks in terms of competitiveness or freedom
you foresee with the status quo?  This is the first I recall hearing
of this concern.


- FChE

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
  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 17:10       ` Christopher Faylor
  0 siblings, 2 replies; 53+ messages in thread
From: Siddhesh Poyarekar @ 2022-10-04 13:46 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Mark Wielaard, gdb, libc-alpha, binutils, gcc

On 2022-10-02 16:47, Mark Wielaard via Overseers wrote:
>> I've published the current GTI TAC meeting minutes to the glibc website:
>> https://www.gnu.org/software/libc/gti-tac/index.html
>>
>> The slides from the LF IT are a good overview:
>> https://www.gnu.org/software/libc/gti-tac/LF%20IT%20Core%20Projects%20Services.pdf
> 
> I assume www.gnu.org was the easiest way for you to quickly make these
> things public. But it now does look like it is an official FSF/GNU
> proposal. Which I assume wasn't your intention. Note that it contains
> a copyright notice "© 2022, GTI TAC." but doesn't seem to have a
> (free) license. Which is kind of necessary if you host it on
> www.gnu.org.

Minutes moved here:

https://gti.gotplt.org/tac/
https://gti.gotplt.org/tac/LF%20IT%20Core%20Projects%20Services.pdf

I own gotplt.org and am happy to lend the subdomain for now to help 
coordinate this because I think the LF proposal is the best long term 
way forward for the GNU toolchain projects to remain competitive *and* Free.

To be clear, I don't think there are any qualms about adding a license 
notice here but we'd have to agree on one.  I made and shared this copy 
to dispel any further false speculation of scope creep of the GTI 
proposal.  For any content attributable to me in the meeting minutes, 
I'm happy to release it under any free license the TAC may agree on.

Sid

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
       [not found] ` <558996ac-e4a0-cf77-48b9-f7d0e13862e8@redhat.com>
  2022-10-02 20:54   ` Mark Wielaard
@ 2022-10-03 19:24   ` Carlos O'Donell
  1 sibling, 0 replies; 53+ messages in thread
From: Carlos O'Donell @ 2022-10-03 19:24 UTC (permalink / raw)
  To: Nick Clifton; +Cc: Binutils

On Thu, Sep 29, 2022 at 11:02:44AM +0100, Nick Clifton wrote:
> Hi Everyone,
> 
> On 9/27/22 21:08, Carlos O'Donell via Binutils wrote:
> > David Edelsohn and I are proud to announce and provide more detail about the
> > GNU Toolchain Infrastructure project.
> 
> Just to be clear on my feelings, I believe that the position of the GNU Binutils
> project should be that we are happy to support the GTI initiative, but we will
> not be abandoning sourceware either.

Thanks for the feedback Nick.

I encourage anyone else to respond to this thread and provide feedback.

It is certainly possible to have hybrid services, like you do already
with binutils (gnu.org website, and tarballs).

> There will not doubt be some technical issues to work through - arranging to
> mirror the repositories for example - but I am sure that these can be resolved.

Absolutely. Thanks for helping with the process.

Cheers,
Carlos.



s,
Carlos.



^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
       [not found] ` <558996ac-e4a0-cf77-48b9-f7d0e13862e8@redhat.com>
@ 2022-10-02 20:54   ` Mark Wielaard
  2022-10-03 19:24   ` Carlos O'Donell
  1 sibling, 0 replies; 53+ messages in thread
From: Mark Wielaard @ 2022-10-02 20:54 UTC (permalink / raw)
  To: Nick Clifton; +Cc: overseers, Binutils

Hi Nick (CC overseers where we work out the technical details),

On Thu, Sep 29, 2022 at 11:02:44AM +0100, Nick Clifton via Binutils wrote:
> Just to be clear on my feelings, I believe that the position of the GNU Binutils
> project should be that we are happy to support the GTI initiative, but we will
> not be abandoning sourceware either.
> 
> There will not doubt be some technical issues to work through - arranging to
> mirror the repositories for example - but I am sure that these can be resolved.

Thanks for your feedback. I am sure we can arrange for binutils to
keep using the sourceware infrastructure while simultaneously work on
setting up mirrors of some of the services.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: The GNU Toolchain Infrastructure Project
       [not found] ` <a9396df3-5699-46ef-0b33-6c7589274654@redhat.com>
@ 2022-10-02 20:47   ` Mark Wielaard
  2022-10-04 13:46     ` Siddhesh Poyarekar
  0 siblings, 1 reply; 53+ messages in thread
From: Mark Wielaard @ 2022-10-02 20:47 UTC (permalink / raw)
  To: overseers; +Cc: libc-alpha, binutils, gdb, gcc

Hi,

We are using overseers to coordinate this and see how we can
mix-and-match pieces of this proposal. And to better understand how
this proposal interacts with Sourceware becoming a Conservancy member
project. So I added overseers@sourceware.org to have one central place
for these discussions.

On Wed, Sep 28, 2022 at 06:38:02PM -0400, Carlos O'Donell via Libc-alpha wrote:
> On 9/27/22 16:08, Carlos O'Donell wrote:
> > "The GNU Toolchain Infrastructure Project"
> > https://sourceware.org/pipermail/overseers/2022q3/018896.html
> 
> I've published the current GTI TAC meeting minutes to the glibc website:
> https://www.gnu.org/software/libc/gti-tac/index.html
> 
> The slides from the LF IT are a good overview:
> https://www.gnu.org/software/libc/gti-tac/LF%20IT%20Core%20Projects%20Services.pdf

I assume www.gnu.org was the easiest way for you to quickly make these
things public. But it now does look like it is an official FSF/GNU
proposal. Which I assume wasn't your intention. Note that it contains
a copyright notice "© 2022, GTI TAC." but doesn't seem to have a
(free) license. Which is kind of necessary if you host it on
www.gnu.org.

This does raise the question if you are also proposing migrating
non-sourceware services for projects like the websites of various of
the GNU projects on www.gnu.org or the release archives at the GNU ftp
server (and mirrors) those projects use.

The attendees list a subset of the GTI TAC members you posted
earlier. Was there any other way for people to participate in these
discussions? Did the GTI TAC invite the LF/IT team to give this
presentation or was this a proposal from the LF?

I note that this discussion and what you presented at Caudron was for
the migration of all services of all projects hosted on
Sourceware. But that your latest proposal is just for a subset of
projects, possibly only in part as would best suit their needs.

Lets file some sourceware infrastructure bugzilla entries for some of
these ideas in this presentation, to get a better understanding what
the real needs are. It would also be nice to hear the prices/budget
for the various options suggested in the presentation.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 53+ messages in thread

end of thread, other threads:[~2022-10-19  5:47 UTC | newest]

Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-27 19:59 The GNU Toolchain Infrastructure Project 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
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
     [not found]                       ` <CAGWvnykKOF=A=LWJ=Rozqx03w3YoCaP+yZ3L8X5+9MFgJ3MO-g@mail.gmail.com>
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

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