* 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; 54+ 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] 54+ messages in thread
* Re: The GNU Toolchain Infrastructure Project 2022-10-02 20:47 ` The GNU Toolchain Infrastructure Project 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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 2022-10-11 17:14 ` David Edelsohn 1 sibling, 1 reply; 54+ 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] 54+ messages in thread
* Re: The GNU Toolchain Infrastructure Project 2022-10-11 15:58 ` Alexandre Oliva @ 2022-10-11 17:14 ` David Edelsohn 2022-10-11 18:12 ` Frank Ch. Eigler ` (2 more replies) 0 siblings, 3 replies; 54+ messages in thread From: David Edelsohn @ 2022-10-11 17:14 UTC (permalink / raw) To: Alexandre Oliva Cc: Mark Wielaard, gcc, Overseers mailing list, libc-alpha, gdb, binutils [-- Attachment #1: Type: text/plain, Size: 3865 bytes --] On Tue, Oct 11, 2022 at 12:00 PM Alexandre Oliva via Gcc <gcc@gcc.gnu.org> wrote: > 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. > The "Sourceware as SFC member project proposal" has been negotiated in more secrecy than the GTI proposal. The "Sourceware" proposal was created without input or support from key members of any of the GNU Toolchain projects (GCC, GLIBC, GDB or Binutils). The GTI proposal has been circulated and socialized among the GNU Toolchain project leadership, GNU Toolchain project Release Managers, key developers, active members of "Overseers" and various stakeholders, including the FSF. 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? All of the people with "skin in the game" who actively depend on the services have been included and updated at each step of developing GTI, and their feedback has helped shape the proposal. > > 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). > That is your assertion and accusation without any evidence. Another interpretation is that you didn't understand or you misinterpreted the conversations. Did you try to clarify this before making public accusations? > > 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. > > We appreciate everyone's opinion on this topic. 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, and have not used private conversations as public debating points nor for divisive purposes.. I believe that speaks for itself. Thanks, David ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: The GNU Toolchain Infrastructure Project 2022-10-11 17:14 ` David Edelsohn @ 2022-10-11 18:12 ` Frank Ch. Eigler 2022-10-12 8:00 ` Mark Wielaard 2022-10-12 10:55 ` Alexandre Oliva 2 siblings, 0 replies; 54+ 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] 54+ messages in thread
* Re: The GNU Toolchain Infrastructure Project 2022-10-11 17:14 ` David Edelsohn 2022-10-11 18:12 ` Frank Ch. Eigler @ 2022-10-12 8:00 ` Mark Wielaard 2022-10-12 13:18 ` Florian Weimer 2022-10-12 15:15 ` Jonathan Corbet 2022-10-12 10:55 ` Alexandre Oliva 2 siblings, 2 replies; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ messages in thread
* Re: The GNU Toolchain Infrastructure Project 2022-10-11 17:14 ` David Edelsohn 2022-10-11 18:12 ` Frank Ch. Eigler 2022-10-12 8:00 ` Mark Wielaard @ 2022-10-12 10:55 ` Alexandre Oliva 2 siblings, 0 replies; 54+ 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] 54+ messages in thread
[parent not found: <b00dc0aa-31a6-a004-a430-099af3d0f6d1@redhat.com>]
[parent not found: <558996ac-e4a0-cf77-48b9-f7d0e13862e8@redhat.com>]
* 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; 54+ 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] 54+ 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; 54+ 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] 54+ messages in thread
* 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; 54+ 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] 54+ messages in thread
* Re: The GNU Toolchain Infrastructure Project 2022-09-27 19:59 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; 54+ 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] 54+ messages in thread
* Re: The GNU Toolchain Infrastructure Project 2022-09-27 19:59 Carlos O'Donell 2022-09-28 14:06 ` Frank Ch. Eigler @ 2022-09-29 9:51 ` Mark Wielaard 2022-09-29 14:45 ` Jonathan Corbet ` (2 subsequent siblings) 4 siblings, 0 replies; 54+ 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] 54+ messages in thread
* Re: The GNU Toolchain Infrastructure Project 2022-09-27 19:59 Carlos O'Donell 2022-09-28 14:06 ` Frank Ch. Eigler 2022-09-29 9:51 ` Mark Wielaard @ 2022-09-29 14:45 ` Jonathan Corbet 2022-09-29 17:13 ` Joseph Myers 2022-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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ messages in thread
* Re: The GNU Toolchain Infrastructure Project 2022-09-27 19:59 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ 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; 54+ 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] 54+ messages in thread
* Re: The GNU Toolchain Infrastructure Project 2022-09-27 19:59 Carlos O'Donell ` (3 preceding siblings ...) 2022-09-29 21:13 ` Andrew Pinski @ 2022-10-02 22:19 ` Mark Wielaard 4 siblings, 0 replies; 54+ 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] 54+ messages in thread
end of thread, other threads:[~2022-10-19 5:47 UTC | newest] Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <d9cb6cf9-89f5-87bb-933b-a03240479e71@redhat.com> [not found] ` <a9396df3-5699-46ef-0b33-6c7589274654@redhat.com> 2022-10-02 20:47 ` The GNU Toolchain Infrastructure Project Mark Wielaard 2022-10-04 13:46 ` Siddhesh Poyarekar 2022-10-04 14:01 ` Frank Ch. Eigler 2022-10-04 14:13 ` Siddhesh Poyarekar 2022-10-04 14:19 ` Frank Ch. Eigler 2022-10-04 14:33 ` Siddhesh Poyarekar 2022-10-04 14:41 ` Frank Ch. Eigler 2022-10-04 14:55 ` Siddhesh Poyarekar 2022-10-04 15:07 ` Frank Ch. Eigler 2022-10-06 21:42 ` Alexandre Oliva 2022-10-04 17:10 ` Christopher Faylor 2022-10-04 17:17 ` Siddhesh Poyarekar 2022-10-04 18:42 ` Christopher Faylor 2022-10-04 19:05 ` Mark Wielaard 2022-10-04 19:10 ` Siddhesh Poyarekar 2022-10-06 20:02 ` Mark Wielaard 2022-10-06 20:12 ` Christopher Faylor 2022-10-06 21:37 ` Siddhesh Poyarekar 2022-10-07 13:39 ` Mark Wielaard 2022-10-06 21:07 ` Siddhesh Poyarekar 2022-10-06 21:36 ` Frank Ch. Eigler 2022-10-06 21:44 ` Siddhesh Poyarekar 2022-10-06 22:57 ` Frank Ch. Eigler 2022-10-11 13:02 ` Siddhesh Poyarekar 2022-10-07 8:57 ` Mark Wielaard 2022-10-11 13:24 ` Siddhesh Poyarekar 2022-10-11 14:23 ` Frank Ch. Eigler 2022-10-11 15:58 ` Alexandre Oliva 2022-10-11 17:14 ` David Edelsohn 2022-10-11 18:12 ` Frank Ch. Eigler 2022-10-12 8:00 ` Mark Wielaard 2022-10-12 13:18 ` Florian Weimer 2022-10-12 21:23 ` Mark Wielaard 2022-10-12 15:15 ` Jonathan Corbet 2022-10-12 10:55 ` Alexandre Oliva [not found] <b00dc0aa-31a6-a004-a430-099af3d0f6d1@redhat.com> [not found] ` <558996ac-e4a0-cf77-48b9-f7d0e13862e8@redhat.com> 2022-10-02 20:54 ` Mark Wielaard 2022-10-03 19:24 ` Carlos O'Donell 2022-09-27 19:59 Carlos O'Donell 2022-09-28 14:06 ` Frank Ch. Eigler 2022-09-29 9:51 ` Mark Wielaard 2022-09-29 14:45 ` Jonathan Corbet 2022-09-29 17:13 ` Joseph Myers 2022-09-29 18:40 ` Elena Zannoni 2022-09-29 18:54 ` Andrew Pinski 2022-10-19 5:47 ` Carlos O'Donell 2022-09-29 21:13 ` Andrew Pinski 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
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).