* Re: Toolchain Infrastructure project statement of support [not found] <2513b668-9ebd-9e78-7263-dc24f4a9558a@redhat.com> @ 2022-10-13 18:25 ` Christopher Faylor 2022-10-14 12:33 ` Siddhesh Poyarekar 2022-10-17 15:10 ` Mark Wielaard 2022-10-23 21:19 ` Alexandre Oliva 1 sibling, 2 replies; 31+ messages in thread From: Christopher Faylor @ 2022-10-13 18:25 UTC (permalink / raw) To: Overseers mailing list; +Cc: gdb, libc-alpha, binutils, gcc, Zoë Kooyman Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote: >The GNU Toolchain project leadership supports the proposal[1] to move the >services for the GNU Toolchain to the Linux Foundation IT under the auspices of >the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the >OpenSSF and other major donors. Noted, however, a list of signatories does not automatically confer authority over any particular project. Any participation from overseers in moving projects to different infrastructure will require clear approval from the individual projects themselves. Also, the FSF, being the existing fiscal sponsor to these projects, surely needs to review the formal agreements before we sunset our infrastructural offerings to glibc, gcc, binutils, and gdb and hand control of the projects' infrastructure over to a different entity. We'd like to assure the communities that, when and if any individual project formally expresses the decision of their developers to transfer their services, we'll endeavor to make the move as smooth as possible. Those projects that wish to stay will continue to receive the best services that the overseers can offer, with the ongoing assistance of Red Hat, the SFC, and, when relevant, the FSF tech team. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-13 18:25 ` Toolchain Infrastructure project statement of support Christopher Faylor @ 2022-10-14 12:33 ` Siddhesh Poyarekar 2022-10-17 15:10 ` Mark Wielaard 1 sibling, 0 replies; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-14 12:33 UTC (permalink / raw) To: Overseers mailing list, gdb, libc-alpha, binutils, gcc, Zoë Kooyman On 2022-10-13 14:25, Christopher Faylor via Overseers wrote: > Also, the FSF, being the existing fiscal sponsor to these projects, > surely needs to review the formal agreements before we sunset our > infrastructural offerings to glibc, gcc, binutils, and gdb and hand > control of the projects' infrastructure over to a different entity. I believe Nick at least has said that for binutils they would like to use both, i.e. mirror some of the LF offerings with sourceware (or vice versa, I suppose it's Nick's call to take) and that'll probably be the case for glibc and gcc as well over the years. So sunset, whenever that will be and whatever it'll look like, will likely be a while. Sid ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-13 18:25 ` Toolchain Infrastructure project statement of support Christopher Faylor 2022-10-14 12:33 ` Siddhesh Poyarekar @ 2022-10-17 15:10 ` Mark Wielaard 2022-10-17 16:11 ` Siddhesh Poyarekar 1 sibling, 1 reply; 31+ messages in thread From: Mark Wielaard @ 2022-10-17 15:10 UTC (permalink / raw) To: Overseers mailing list; +Cc: gdb, libc-alpha, binutils, gcc Hi Carlos, On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote: > The GNU Toolchain project leadership [...] I must say I don't understand why you are communicating in this way. Sending out "proclamations" about having support from "leadership", "committees" and "key stakeholders". Some of these key people seem to not even agree with it or know what it is really about and they cannot or don't want to answer questions about the details. In the last year we did some really nice work for the sourceware infrastructure. We setup the shared buildbot, got various companies and organisations to provide compute resources, workers for various architectures. We now have CI, Try and Full builders for various projects and doing 10.000+ builds a month. With a bunsen analysis database with all those test-results. Did a resource analysis and wrote up this public roadmap to make the email/git based workflow that sourceware projects rely on more fun, secure and productive by automating contribution tracking and testing. We now also have the sourcehut mirror and the public-inbox instance to make the email workflow nicer and support things like patch attestation. We are working on better integration between patchwork and buildbot for pre- commit checking. And we got the Software Freedom Conservancy to accept sourceware as a member project to act as a fiscal sponsor. They are now helping us with the future roadmap, setting up a organization, budgeting, etc. And the FSF also is supportive of this. All this was done in public, we even setup some public video chats about how we wanted to do this in the future. And you were explicitly invited to participate because we wanted to make sure it fit with any other plans people might be having. At the Cauldron, when we wanted to discuss with the community how to use and set project policies around the sourceware infrastructure services, one of the "leaders" ran around the room shouting down and pushing people who wanted to discuss this. Telling people they didn't got to decide what we would talk about. And finally yelling at me that I lost all trust of the "gnu toolchain leadership". All just for wanting to have a public discussion on some cool stuff we did and were planning to do together. That isn't "leadership". That is just intimidation and bullying. It made me really sad. And now you again seem to not want to discuss any details on how to work together. After Cauldron I thought we agreed we would discuss goals on overseers and create sourceware infrastructure bugs. So we could see what the community priorities were, write an updated sourceware roadmap, setup a budget, etc. I was really happy to see the discussions about setting up a video chat system for projects, the FSF tech-team offering to setup mirrors, backups and help coordinate secure release uploads. And I had hoped to see some discussion on how the LF and potential sponsors could help, working together with the sourceware community and the SFC. We really would love for gdb, glibc, binutils and gcc to keep being part of sourceware. Cheers, Mark ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-17 15:10 ` Mark Wielaard @ 2022-10-17 16:11 ` Siddhesh Poyarekar 2022-10-18 9:50 ` Mark Wielaard 2022-10-23 11:33 ` Ian Kelling 0 siblings, 2 replies; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-17 16:11 UTC (permalink / raw) To: Overseers mailing list; +Cc: Mark Wielaard, gdb, libc-alpha, binutils, gcc On 2022-10-17 11:10, Mark Wielaard via Overseers wrote: <snip> > In the last year we did some really nice work for the sourceware > infrastructure. We setup the shared buildbot, got various companies and I feel like you're taking this personally as an overseer; the proposal to transition to LF IT is not a value judgment on your work. It is a proposal to scale far beyond what our current resources can afford. I personally am grateful for all that work and have participated in some of it too but I don't think that it's a scalable approach for gcc or to a lesser extent, glibc. > organisations to provide compute resources, workers for various > architectures. We now have CI, Try and Full builders for various > projects and doing 10.000+ builds a month. With a bunsen analysis > database with all those test-results. Did a resource analysis and wrote > up this public roadmap to make the email/git based workflow that > sourceware projects rely on more fun, secure and productive by > automating contribution tracking and testing. We now also have the > sourcehut mirror and the public-inbox instance to make the email > workflow nicer and support things like patch attestation. We are > working on better integration between patchwork and buildbot for pre- > commit checking. And we got the Software Freedom Conservancy to accept > sourceware as a member project to act as a fiscal sponsor. They are now Fiscal sponsor for the *sourceware overseers*. There's no way for SFC to be a fiscal sponsor for sourceware, which is infrastructure owned by Red Hat. > helping us with the future roadmap, setting up a organization, > budgeting, etc. And the FSF also is supportive of this. The FSF has little stake in sourceware beyond the GNU toolchain, so FSF being supportive of sourceware overseers seeking funding has about the same relevance as the FSF being supportive of my decision to move to a different country. They do have a significant stake in infrastructure for the GNU toolchain project and they've been part of discussions since the idea for GTI germinated. > And now you again seem to not want to discuss any details on how to > work together. After Cauldron I thought we agreed we would discuss > goals on overseers and create sourceware infrastructure bugs. So we > could see what the community priorities were, write an updated > sourceware roadmap, setup a budget, etc. On multiple occasions I've been told on this list that sourceware administration being transitioned to LF IT is out of question, so I don't see the point of having these discussions. I don't see a retention plan that's viable for the next 5, 10 or 20 years. I personally do not think the current sourceware infrastructure, even with the roadmap it promises is a viable alternative to what LF IT can provide. There is a significant resource gap (e.g. service isolation to different machines and/or containers, full time administrators with global presence for FTS support, established security and administration practices, traffic acceleration, to name a few) that we seem to disagree about. There seems to be little to discuss from the GNU toolchain perspective IMO; the overseers think that the LF IT proposal and the additional funding and infrastructure it brings in are not necessary and we think it is. > I was really happy to see the discussions about setting up a video chat > system for projects, the FSF tech-team offering to setup mirrors, > backups and help coordinate secure release uploads. And I had hoped to > see some discussion on how the LF and potential sponsors could help, > working together with the sourceware community and the SFC. > > We really would love for gdb, glibc, binutils and gcc to keep being > part of sourceware. IMO the best way to make this happen is for us to transition sourceware administration to LF IT. However since all projects hosted on sourceware don't seem to agree on this and the overseers also do not desire to give up control over the infrastructure, I don't see another way out of this. Of course, like I said to Chris, it's likely going to be a while before we fully transition away from sourceware (it'll likely happen one service at a time, or something like that, we need to figure that out at some point) and we'll need continued help from the overseers to help manage the infrastructure in the near future. Sid ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-17 16:11 ` Siddhesh Poyarekar @ 2022-10-18 9:50 ` Mark Wielaard 2022-10-18 15:17 ` Siddhesh Poyarekar 2022-10-23 11:33 ` Ian Kelling 1 sibling, 1 reply; 31+ messages in thread From: Mark Wielaard @ 2022-10-18 9:50 UTC (permalink / raw) To: Siddhesh Poyarekar; +Cc: Overseers mailing list, gdb, libc-alpha, binutils, gcc Hi Siddhesh, On Mon, Oct 17, 2022 at 12:11:53PM -0400, Siddhesh Poyarekar wrote: > There seems to be little to discuss from the GNU toolchain perspective IMO; Yes, it is clear you don't want any discussion or answer any questions about the proposals, how funds can be used, what the budget is, what the requirements are, how the governance structure works, what alternatives we have, etc. But personally I think it is healthy to have real discussions, doing resource analysis, creating public roadmaps, collecting infrastructure enahancement requests, discuss how to organize, argue about the needed budget and how to use funding most efficiently, etc. To make sure that sourceware keeps being a healthy and viable free software infrastructure project for the next 24 years, hopefully including the various GNU toolchain projects. Cheers, Mark ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-18 9:50 ` Mark Wielaard @ 2022-10-18 15:17 ` Siddhesh Poyarekar 2022-10-18 16:42 ` Christopher Faylor 2022-10-23 8:59 ` Ian Kelling 0 siblings, 2 replies; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-18 15:17 UTC (permalink / raw) To: Mark Wielaard; +Cc: Overseers mailing list, gdb, libc-alpha, binutils, gcc On 2022-10-18 05:50, Mark Wielaard wrote: > Hi Siddhesh, > > On Mon, Oct 17, 2022 at 12:11:53PM -0400, Siddhesh Poyarekar wrote: >> There seems to be little to discuss from the GNU toolchain perspective IMO; > > Yes, it is clear you don't want any discussion or answer any questions > about the proposals, That is not true, Mark. Your objections and questions have been answered at every stage, privately as well as publicly. What *is* clear is that we have been talking past each other because despite our common high level intentions, we appear to have little common ground for our goals. You want to retain the current sourceware infrastructure and try and see what we can do within that framework and I want us to migrate services to infrastructure with better funding (that's not just limited to services), dedicated ops management and an actually scalable future. > how funds can be used, Let me turn that around: how *would* you like funds to be used beyond what is currently proposed in the LF IT proposal? > what the budget is, Around $400,000. > what > the requirements are, Your lack of clarity about requirements IMO have more to do with you wanting to fulfill those requirements within sourceware and not with their existence. I and others have repeated them here and the overseers have either questioned their validity or noted them in bugzilla as possible things to explore in the current sourceware context. With sourceware migration to LF IT off the table, there's little incentive for me personally to explore them. > how the governance structure works, I think you know how it works, maybe you meant to say that you don't like it? The governance structure and their workings have been described in the GTI introduction. There are two key bodies that govern the project: the Technical Advisory Council (comprised of project community members) manages the technical details of the infrastructure and the governing board (comprised of representatives from funding companies) manages the funding for those technical details. The current TAC comprises of people from the initial community stakeholders who were contacted and subsequently accepted the invitation to be part of TAC. You, along with other overseers, were invited too but most of you declined. > what > alternatives we have, etc. For projects the alternatives they have are: 1. Migrate to LF IT infrastructure 2. Have a presence on sourceware as well as LF IT, contingent to Red Hat's decision on the hardware infrastructure 3. Stay fully on sourceware For sourceware as infrastructure the alternatives are: 1. Migrate to LF IT infrastructure 2. Stay as it currently is For sourceware overseers, the choices are contingent on what projects decide and what Red Hat decides w.r.t. sourceware. All of the above has been clear all along. Maybe the problem here is that you're not happy with the alternatives? > But personally I think it is healthy to have real discussions, doing > resource analysis, creating public roadmaps, collecting infrastructure > enahancement requests, discuss how to organize, argue about the needed > budget and how to use funding most efficiently, etc. To make sure that > sourceware keeps being a healthy and viable free software > infrastructure project for the next 24 years, hopefully including the > various GNU toolchain projects. You want to talk about sourceware without including the LF IT proposal whereas I'd love to talk about sourceware as an LF IT maintained infrastructure. There's a real disconnect that precludes any real discussions. Sid ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-18 15:17 ` Siddhesh Poyarekar @ 2022-10-18 16:42 ` Christopher Faylor 2022-10-18 18:13 ` Siddhesh Poyarekar 2022-10-23 8:59 ` Ian Kelling 1 sibling, 1 reply; 31+ messages in thread From: Christopher Faylor @ 2022-10-18 16:42 UTC (permalink / raw) To: Siddhesh Poyarekar Cc: Mark Wielaard, gdb, Overseers mailing list, libc-alpha, binutils, gcc On Tue, Oct 18, 2022 at 11:17:15AM -0400, Siddhesh Poyarekar wrote: >That is not true, Mark. Your objections and questions have been answered at >every stage, privately as well as publicly. Actually, going back through this thread, I see outstanding questions/issues raised by Mark, Frank, Alexandre Oliva, Jon Corbet, and Andrew Pinski. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-18 16:42 ` Christopher Faylor @ 2022-10-18 18:13 ` Siddhesh Poyarekar 2022-10-18 18:14 ` Siddhesh Poyarekar 2022-10-21 0:33 ` Alexandre Oliva 0 siblings, 2 replies; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-18 18:13 UTC (permalink / raw) To: Mark Wielaard, gdb, Overseers mailing list, libc-alpha, binutils, gcc On 2022-10-18 12:42, Christopher Faylor wrote: > On Tue, Oct 18, 2022 at 11:17:15AM -0400, Siddhesh Poyarekar wrote: >> That is not true, Mark. Your objections and questions have been answered at >> every stage, privately as well as publicly. > > Actually, going back through this thread, I see outstanding > questions/issues raised by Mark, Frank, Alexandre Oliva, Jon Corbet, and > Andrew Pinski. As far as actual questions regarding the proposal is concerned, I think only Job Corbet's questions to Carlos/David are pending an answer; I deferred them to Carlos or David because I think they're better placed to answer them in their entirety. The rest, AFAICT, are either fear of some kind of corporate takeover, discussions about current sourceware infrastructure, or just rhetoric, none of which I'm interested in engaging with. The corporate takeover fear especially is amusing to me given how much of GNU toolchain development and infrastructure is sponsored by corporations right now but that's just my personal opinion. Maybe the FSF hosted call next week[1] would be a suitable forum to discuss fears of corporate control of the GNU toolchain project infrastructure due to the LF IT migration, or for that matter any other questions you or others think may have gone unanswered. Since sourceware is neither a GNU nor an FSF project, it probably does not make sense to discuss current sourceware infrastructure there. Sid [1] https://sourceware.org/pipermail/overseers/2022q4/018997.html ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-18 18:13 ` Siddhesh Poyarekar @ 2022-10-18 18:14 ` Siddhesh Poyarekar 2022-10-18 18:47 ` Paul Smith 2022-10-21 0:33 ` Alexandre Oliva 1 sibling, 1 reply; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-18 18:14 UTC (permalink / raw) To: Mark Wielaard, gdb, Overseers mailing list, libc-alpha, binutils, gcc On 2022-10-18 14:13, Siddhesh Poyarekar wrote: > only Job Corbet's questions to Carlos/David are pending an answer; I s/Job/Jon/ sorry about misspelling your name. Sid ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-18 18:14 ` Siddhesh Poyarekar @ 2022-10-18 18:47 ` Paul Smith 0 siblings, 0 replies; 31+ messages in thread From: Paul Smith @ 2022-10-18 18:47 UTC (permalink / raw) To: gdb, Overseers mailing list, libc-alpha, binutils, gcc On Tue, 2022-10-18 at 14:14 -0400, Siddhesh Poyarekar wrote: > On 2022-10-18 14:13, Siddhesh Poyarekar wrote: > > only Job Corbet's questions to Carlos/David are pending an answer; > > s/Job/Jon/ sorry about misspelling your name. I thought it was great! We all have known for years that Jon has the requisite patience for that role... ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-18 18:13 ` Siddhesh Poyarekar 2022-10-18 18:14 ` Siddhesh Poyarekar @ 2022-10-21 0:33 ` Alexandre Oliva 1 sibling, 0 replies; 31+ messages in thread From: Alexandre Oliva @ 2022-10-21 0:33 UTC (permalink / raw) To: Siddhesh Poyarekar Cc: Mark Wielaard, gdb, Overseers mailing list, libc-alpha, binutils, gcc On Oct 18, 2022, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: > The rest, AFAICT, are either fear of some kind of corporate takeover, > discussions about current sourceware infrastructure, or just rhetoric, > none of which I'm interested in engaging with. So in which category do you place my question about the viability of using the funds raised through the LF to pay for IT services provided by third parties rather than by the LF? -- 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] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-18 15:17 ` Siddhesh Poyarekar 2022-10-18 16:42 ` Christopher Faylor @ 2022-10-23 8:59 ` Ian Kelling 2022-10-23 13:27 ` Siddhesh Poyarekar 1 sibling, 1 reply; 31+ messages in thread From: Ian Kelling @ 2022-10-23 8:59 UTC (permalink / raw) To: Overseers mailing list Cc: Mark Wielaard, Siddhesh Poyarekar, gdb, libc-alpha, binutils, gcc Siddhesh Poyarekar via Overseers <overseers@sourceware.org> writes: >> what >> alternatives we have, etc. > For projects the alternatives they have are: > > 1. Migrate to LF IT infrastructure > 2. Have a presence on sourceware as well as LF IT, contingent to Red > Hat's decision on the hardware infrastructure > 3. Stay fully on sourceware > > For sourceware as infrastructure the alternatives are: > > 1. Migrate to LF IT infrastructure > 2. Stay as it currently is > > For sourceware overseers, the choices are contingent on what projects > decide and what Red Hat decides w.r.t. sourceware. > > All of the above has been clear all along. Maybe the problem here is > that you're not happy with the alternatives? No, I don't think that was ever clear. I've just read this message, but I've been keeping up with everything public since Cauldron. All your options assume that any specific service is 100% managed by LF IT, or 100% managed by sourceware. That is a bad assumption. They could do it together, or another group could help. So, you said you wanted "dedicated ops management", and I assume sourceware is not currently equipped for that. But there is no reason that an ops team from LF IT or FSF could not provide dedicated ops management for existing sourceware services in collaboration with sourceware. Another notable ops team is OSU, https://osuosl.org/. For example, at FSF tech team (where I work), we jointly maintain services with many volunteers that volunteer for specific projects. They are mainly: KDE, Linux Libre, Emacs, Savannah, Guix, GNU debbugs, replicant, h-node.org, planet.gnu.org, and Trisquel. The FSF tech team keeps a 24 hour on call rotation, so the services have a dedicated ops team to fix issues and respond to alerts, but the day to day management of the services those groups want, eg: upgrading them, configuring, modifying, etc is mostly done by volunteers. To give some very specific examples: a group of volunteer sysadmins for emacs decided they wanted a new build service for Emacs, so they jumped in a meeting with FSF tech team (I'm part of it) to discuss all the technical details and requirements. We decided the volunteers would do the primary installation and management of a gitlab that was only configured to use the build server, and FSF tech team would setup alerts, create the VM and the DNS. We agree on what kind of uptime is expected and what kind of alerts the tech team will respond to in off hours. The volunteer's ssh keys sit alongside the FSF tech team's keys on that VM. Alternatively, for Trisquel, Trisquel orders hardware and we go install it to the data center, and the Trisquel sysadmins spin up their own virtual machines or whatever they want to run, we just go into the data center with spare parts and fix things if the hardware breaks down. For any service we are going to support, we learn enough about the service to fix things things. Anyways, basically, having a dedicated ops team does not imply removing the sourceware's role, it could simply mean: adding a dedicated ops team to sourceware. To provide dedicated ops for the physical servers would require moving the servers or into servers in a data center near the ops team, or outsourcing the hardware management to one of many companies (usually by renting a physical server), but that is all totally feasible and not a big cost. Siddhesh Poyarekar via Overseers <overseers@sourceware.org> writes: > I want us to migrate > services to infrastructure with better funding (that's not just limited > to services), What do you want to fund specifically? "Infrastructure" and "not limited to services" is not specific enough to understand. > and an actually scalable future. What does "an actually scalable future" mean? That is very vague. -- Ian Kelling | Senior Systems Administrator, Free Software Foundation GPG Key: B125 F60B 7B28 7FF6 A2B7 DF8F 170A F0E2 9542 95DF https://fsf.org | https://gnu.org ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 8:59 ` Ian Kelling @ 2022-10-23 13:27 ` Siddhesh Poyarekar 2022-10-23 15:16 ` Frank Ch. Eigler 2022-10-23 20:57 ` Christopher Faylor 0 siblings, 2 replies; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-23 13:27 UTC (permalink / raw) To: Ian Kelling, Overseers mailing list Cc: Mark Wielaard, gdb, libc-alpha, binutils, gcc On 2022-10-23 04:59, Ian Kelling wrote: > No, I don't think that was ever clear. I've just read this message, but > I've been keeping up with everything public since Cauldron. All your > options assume that any specific service is 100% managed by LF IT, or > 100% managed by sourceware. That is a bad assumption. They could do it > together, or another group could help. So, you said you wanted > "dedicated ops management", and I assume sourceware is not currently > equipped for that. But there is no reason that an ops team from LF IT or > FSF could not provide dedicated ops management for existing sourceware > services in collaboration with sourceware. Another notable ops team is > OSU, https://osuosl.org/. Hybrid administration isn't part of the GTI proposal, why would that be considered an option? Is this something you'd like to propose to the TAC, i.e. give named members from the community access to infrastructure administration? We can bring that up in our discussion with the LF IT. > Anyways, basically, having a dedicated ops team does not imply removing > the sourceware's role, it could simply mean: adding a dedicated ops team > to sourceware. Given that the current sourceware admins have decided to block migration of all sourceware assets to the LF IT, I don't have a stake on how they'd like to handle this for sourceware. I could however, as a member of TAC (and as member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc), discuss with others the possibility of specific community volunteers being given some amount of access to manage infrastructure. > To provide dedicated ops for the physical servers would require moving > the servers or into servers in a data center near the ops team, or > outsourcing the hardware management to one of many companies (usually by > renting a physical server), but that is all totally feasible and not a > big cost. > > > Siddhesh Poyarekar via Overseers <overseers@sourceware.org> writes: > >> I want us to migrate >> services to infrastructure with better funding (that's not just limited >> to services), > > What do you want to fund specifically? "Infrastructure" and "not limited > to services" is not specific enough to understand. > >> and an actually scalable future. > > What does "an actually scalable future" mean? That is very vague. Both of those point to scaling hardware in addition to services, having things like physical isolation of services. Scaling volunteers (which hasn't happened in the last 20-soemthing years; it has scaled *down*, if anything) and money to pay for dedicated ops isn't going to mostly pointless if we can't pay for hardware, which is owned by Red Hat. That, and FSF not being able to add resources for the GNU toolchain was in fact why we had to look elsewhere for funding. I suggest you wait a day for the FSF hosted call so that the background is clearer. Sid ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 13:27 ` Siddhesh Poyarekar @ 2022-10-23 15:16 ` Frank Ch. Eigler 2022-10-23 16:07 ` Siddhesh Poyarekar 2022-10-23 20:57 ` Christopher Faylor 1 sibling, 1 reply; 31+ messages in thread From: Frank Ch. Eigler @ 2022-10-23 15:16 UTC (permalink / raw) To: Overseers mailing list Cc: Ian Kelling, Siddhesh Poyarekar, gdb, Mark Wielaard, libc-alpha, binutils, gcc Hi - > [...] Given that the current sourceware admins have decided to > block migration of all sourceware assets to the LF IT [...] If you're trying to say that projects have not unanimously shown interest in moving infrastructure to LF IT, just say that. Don't blame overseers. If you're trying to suggest that overseers, contrary to our repeated public statements, wish to block all migration, that is untrue and you will need to retract this. - FChE ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 15:16 ` Frank Ch. Eigler @ 2022-10-23 16:07 ` Siddhesh Poyarekar 2022-10-23 16:32 ` Siddhesh Poyarekar ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-23 16:07 UTC (permalink / raw) To: Frank Ch. Eigler, Overseers mailing list Cc: Ian Kelling, gdb, Mark Wielaard, libc-alpha, binutils, gcc On 2022-10-23 11:16, Frank Ch. Eigler wrote: > Hi - > >> [...] Given that the current sourceware admins have decided to >> block migration of all sourceware assets to the LF IT [...] > > If you're trying to say that projects have not unanimously shown > interest in moving infrastructure to LF IT, just say that. Don't > blame overseers. I did not say that, although no project (barring maybe elfutils and systemtap, assuming that your and Mark's objection as overseers implies that you do not want to move to LF IT) has specifically *opposed* moving infrastructure to LF IT either. To be specific, gcc steering committee and glibc FSF stewards have announced the decision for their projects, Nick announced for binutils that he supports moving to LF IT (with the caveat that he won't abandon sourceware, I assume that means he'd like to use sourceware as a mirror or something similar) but gdb folks have been silent so far. Given how gdb and binutils are coupled, the gdb conversation really needs to happen at some point. From private conversations with folks from the gdb community, it seems to me that they're primarily avoiding getting into this public spat. I am not aware of any opposition from maintainers of libabigail or cygwin or any other active sourceware based project over moving either, but I haven't had any links to those projects, so I may be uninformed. > If you're trying to suggest that overseers, contrary to our repeated > public statements, wish to block all migration, that is untrue and you > will need to retract this. Here's a more precise statement: Two of the overseers are leaders of projects hosted on sourceware and three overseers (including those two) have stated clearly on multiple occasions that transitioning to LF IT is off the table, effectively announcing their decision on behalf of projects they lead. It is hence clear that the overseers have effectively blocked full migration of sourceware to LF IT. Sid ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 16:07 ` Siddhesh Poyarekar @ 2022-10-23 16:32 ` Siddhesh Poyarekar 2022-10-23 17:01 ` Jeff Law 2022-10-23 17:09 ` Frank Ch. Eigler 2 siblings, 0 replies; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-23 16:32 UTC (permalink / raw) To: Overseers mailing list, Frank Ch. Eigler Cc: gcc, libc-alpha, gdb, Mark Wielaard, binutils On 2022-10-23 12:07, Siddhesh Poyarekar via Overseers wrote: > sourceware, I assume that means he'd like to use sourceware as a mirror > or something similar) but gdb folks have been silent so far. Given how > gdb and binutils are coupled, the gdb conversation really needs to > happen at some point. From private conversations with folks from the > gdb community, it seems to me that they're primarily avoiding getting > into this public spat. ... and I've been corrected offline that a gdb GNU maintainer (Joel Brobecker) has indeed signed on to support the LF IT proposal and there have been no objections so far that I'm aware of, either publicly or privately. Sid ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 16:07 ` Siddhesh Poyarekar 2022-10-23 16:32 ` Siddhesh Poyarekar @ 2022-10-23 17:01 ` Jeff Law 2022-10-23 22:35 ` Christopher Faylor 2022-10-23 17:09 ` Frank Ch. Eigler 2 siblings, 1 reply; 31+ messages in thread From: Jeff Law @ 2022-10-23 17:01 UTC (permalink / raw) To: Siddhesh Poyarekar, Frank Ch. Eigler, Overseers mailing list Cc: gcc, libc-alpha, gdb, Mark Wielaard, binutils, Ian Kelling On 10/23/22 10:07, Siddhesh Poyarekar wrote: >> If you're trying to suggest that overseers, contrary to our repeated >> public statements, wish to block all migration, that is untrue and you >> will need to retract this. > > Here's a more precise statement: Two of the overseers are leaders of > projects hosted on sourceware and three overseers (including those > two) have stated clearly on multiple occasions that transitioning to > LF IT is off the table, effectively announcing their decision on > behalf of projects they lead. It is hence clear that the overseers > have effectively blocked full migration of sourceware to LF IT. They can make those decisions for the projects they lead. But making the decision or setting criteria for other projects is highly unreasonable. Jeff ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 17:01 ` Jeff Law @ 2022-10-23 22:35 ` Christopher Faylor 0 siblings, 0 replies; 31+ messages in thread From: Christopher Faylor @ 2022-10-23 22:35 UTC (permalink / raw) To: Jeff Law Cc: Siddhesh Poyarekar, Frank Ch. Eigler, Overseers mailing list, gcc, libc-alpha, gdb, Mark Wielaard, binutils On Sun, Oct 23, 2022 at 11:01:34AM -0600, Jeff Law wrote: >On 10/23/22 10:07, Siddhesh Poyarekar wrote: >>>If you're trying to suggest that overseers, contrary to our repeated >>>public statements, wish to block all migration, that is untrue and you >>>will need to retract this. >> >>Here's a more precise statement: Two of the overseers are leaders of >>projects hosted on sourceware and three overseers (including those two) >>have stated clearly on multiple occasions that transitioning to LF IT >>is off the table, effectively announcing their decision on behalf of >>projects they lead. It is hence clear that the overseers have >>effectively blocked full migration of sourceware to LF IT. > >They can make those decisions for the projects they lead. But making >the decision or setting criteria for other projects is highly >unreasonable. This is not, IMO, helping. On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote: >We'd like to assure the communities that, when and if any individual >project formally expresses the decision of their developers to transfer >their services, we'll endeavor to make the move as smooth as possible. >Those projects that wish to stay will continue to receive the best >services that the overseers can offer, with the ongoing assistance of >Red Hat, the SFC, and, when relevant, the FSF tech team. We can't help move anyone without first establishing some kind of criteria. The only reasonable criteria is a formal request from the project being moved. As an exercise in human psychology, these insinuations of anticipated unhelpfulness *can* eventually be a self-fullfilling prophecy, though. i.e., if you really do not *want* any help with any transitions of projects then, just keep implying, despite evidence to the contrary, that we might be unreasonable jerks. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 16:07 ` Siddhesh Poyarekar 2022-10-23 16:32 ` Siddhesh Poyarekar 2022-10-23 17:01 ` Jeff Law @ 2022-10-23 17:09 ` Frank Ch. Eigler 2022-10-23 17:38 ` Jeff Law 2022-10-24 1:51 ` Siddhesh Poyarekar 2 siblings, 2 replies; 31+ messages in thread From: Frank Ch. Eigler @ 2022-10-23 17:09 UTC (permalink / raw) To: Siddhesh Poyarekar Cc: Overseers mailing list, Ian Kelling, gdb, Mark Wielaard, libc-alpha, binutils, gcc Hi - > [...] To be specific, gcc steering committee and glibc FSF stewards > have announced the decision for their projects [...] I may be missing something. All I've seen so far were some of the leaders of some of the projects being joint signatories to a letter on overseers@. As far as I'm aware, that is not how any of these projects make or announce **project decisions** with/to their respective constituencies. > I am not aware of any opposition from maintainers of libabigail or > cygwin or any other active sourceware based project over moving > either, but I haven't had any links to those projects, so I may be > uninformed. Indeed. The onus is obviously on the shoulders of the proponents of this proposal to convince each sourceware guest project to consent to move. If you wish to frame any dissent as "blocking full migration", then I'd say the job of convincing everyone just has not been up to par. Perhaps it was the wrong goal all along. - FChE ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 17:09 ` Frank Ch. Eigler @ 2022-10-23 17:38 ` Jeff Law 2022-10-24 1:51 ` Siddhesh Poyarekar 1 sibling, 0 replies; 31+ messages in thread From: Jeff Law @ 2022-10-23 17:38 UTC (permalink / raw) To: Frank Ch. Eigler, Siddhesh Poyarekar Cc: gcc, Overseers mailing list, libc-alpha, gdb, Mark Wielaard, binutils, Ian Kelling On 10/23/22 11:09, Frank Ch. Eigler via Libc-alpha wrote: > Hi - > >> [...] To be specific, gcc steering committee and glibc FSF stewards >> have announced the decision for their projects [...] > I may be missing something. All I've seen so far were some of the > leaders of some of the projects being joint signatories to a letter on > overseers@. As far as I'm aware, that is not how any of these > projects make or announce **project decisions** with/to their > respective constituencies. Right. It's a general statement of support from a variety of leaders but I wouldn't consider it authoritative from any project. For GCC the decision would be made by the overseers and relayed to the overseers as an official statement for the GCC project. That would happen after a vote by the steering committee members based on already established voting procedures. > > >> I am not aware of any opposition from maintainers of libabigail or >> cygwin or any other active sourceware based project over moving >> either, but I haven't had any links to those projects, so I may be >> uninformed. > Indeed. The onus is obviously on the shoulders of the proponents of > this proposal to convince each sourceware guest project to consent to > move. If you wish to frame any dissent as "blocking full migration", > then I'd say the job of convincing everyone just has not been up to > par. Perhaps it was the wrong goal all along. Also agreed. And I fully support needing a statement from project leadership for each project wishing to move. That is reasonable and I wish we'd been clearer about that. In simplest terms, overseers need to be a neutral party here. In cases where overseers have leadership roles on particular projects, then they will have to wear multiple hats, but it's not really complicated. Each project makes a decision, by whatever means project leadership has in place to make decisions. overseers then honors those requests to stay or go. It's a pretty simple separation of responsibilities. It need not be contentious in any way shape or form. Jeff ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 17:09 ` Frank Ch. Eigler 2022-10-23 17:38 ` Jeff Law @ 2022-10-24 1:51 ` Siddhesh Poyarekar 1 sibling, 0 replies; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-24 1:51 UTC (permalink / raw) To: Frank Ch. Eigler Cc: Overseers mailing list, Ian Kelling, gdb, Mark Wielaard, libc-alpha, binutils, gcc On 2022-10-23 13:09, Frank Ch. Eigler wrote: >> [...] To be specific, gcc steering committee and glibc FSF stewards >> have announced the decision for their projects [...] > > I may be missing something. All I've seen so far were some of the > leaders of some of the projects being joint signatories to a letter on > overseers@. As far as I'm aware, that is not how any of these > projects make or announce **project decisions** with/to their > respective constituencies. Fair enough. >> I am not aware of any opposition from maintainers of libabigail or >> cygwin or any other active sourceware based project over moving >> either, but I haven't had any links to those projects, so I may be >> uninformed. > > Indeed. The onus is obviously on the shoulders of the proponents of > this proposal to convince each sourceware guest project to consent to > move. If you wish to frame any dissent as "blocking full migration", > then I'd say the job of convincing everyone just has not been up to > par. Perhaps it was the wrong goal all along. Are you saying then that your dissent so far is as maintainer for systemtap and not as an overseer? Sid ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 13:27 ` Siddhesh Poyarekar 2022-10-23 15:16 ` Frank Ch. Eigler @ 2022-10-23 20:57 ` Christopher Faylor 2022-10-23 21:17 ` Siddhesh Poyarekar 1 sibling, 1 reply; 31+ messages in thread From: Christopher Faylor @ 2022-10-23 20:57 UTC (permalink / raw) To: Siddhesh Poyarekar Cc: Ian Kelling, Overseers mailing list, gdb, Mark Wielaard, libc-alpha, binutils, gcc On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote: >Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html > >On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote: >>The GNU Toolchain project leadership supports the proposal[1] to move the >>services for the GNU Toolchain to the Linux Foundation IT under the auspices of >>the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the >>OpenSSF and other major donors. > >Noted, however, a list of signatories does not automatically confer >authority over any particular project. Any participation from >overseers in moving projects to different infrastructure will require >clear approval from the individual projects themselves. > >Also, the FSF, being the existing fiscal sponsor to these projects, >surely needs to review the formal agreements before we sunset our >infrastructural offerings to glibc, gcc, binutils, and gdb and hand >control of the projects' infrastructure over to a different entity. > >We'd like to assure the communities that, when and if any individual >project formally expresses the decision of their developers to transfer >their services, we'll endeavor to make the move as smooth as possible. >Those projects that wish to stay will continue to receive the best >services that the overseers can offer, with the ongoing assistance of >Red Hat, the SFC, and, when relevant, the FSF tech team. On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote: >Given that the current sourceware admins have decided to block migration of >all sourceware assets to the LF IT, I don't have a stake on how they'd like >to handle this for sourceware. I could however, as a member of TAC (and as >member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc), >discuss with others the possibility of specific community volunteers being >given some amount of access to manage infrastructure. Stop spreading FUD. The "we" in my statement above, from October 13, included fche, mjw, and myself. You have no reason to be confused on this subject. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 20:57 ` Christopher Faylor @ 2022-10-23 21:17 ` Siddhesh Poyarekar 2022-10-23 21:59 ` Christopher Faylor 0 siblings, 1 reply; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-23 21:17 UTC (permalink / raw) To: Ian Kelling, Overseers mailing list, gdb, Mark Wielaard, libc-alpha, binutils, gcc On 2022-10-23 16:57, Christopher Faylor wrote: > On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote: >> Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html >> >> On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote: >>> The GNU Toolchain project leadership supports the proposal[1] to move the >>> services for the GNU Toolchain to the Linux Foundation IT under the auspices of >>> the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the >>> OpenSSF and other major donors. >> >> Noted, however, a list of signatories does not automatically confer >> authority over any particular project. Any participation from >> overseers in moving projects to different infrastructure will require >> clear approval from the individual projects themselves. >> >> Also, the FSF, being the existing fiscal sponsor to these projects, >> surely needs to review the formal agreements before we sunset our >> infrastructural offerings to glibc, gcc, binutils, and gdb and hand >> control of the projects' infrastructure over to a different entity. >> >> We'd like to assure the communities that, when and if any individual >> project formally expresses the decision of their developers to transfer >> their services, we'll endeavor to make the move as smooth as possible. >> Those projects that wish to stay will continue to receive the best >> services that the overseers can offer, with the ongoing assistance of >> Red Hat, the SFC, and, when relevant, the FSF tech team. > > On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote: >> Given that the current sourceware admins have decided to block migration of >> all sourceware assets to the LF IT, I don't have a stake on how they'd like >> to handle this for sourceware. I could however, as a member of TAC (and as >> member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc), >> discuss with others the possibility of specific community volunteers being >> given some amount of access to manage infrastructure. > > Stop spreading FUD. The "we" in my statement above, from October 13, > included fche, mjw, and myself. You have no reason to be confused on > this subject. > Nope, I'm not spreading FUD, in fact that statement of yours is perfectly consistent with what I've said: the blocker at the moment is that the sourceware overseers have refused to hand over the server *in its entirety* to LF IT, not that any projects themselves have refused to move their services to LF IT. I don't doubt that the overseers will help in smooth migration for projects that eventually state that they wish to move over. Sid ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 21:17 ` Siddhesh Poyarekar @ 2022-10-23 21:59 ` Christopher Faylor 2022-10-24 1:29 ` Siddhesh Poyarekar 0 siblings, 1 reply; 31+ messages in thread From: Christopher Faylor @ 2022-10-23 21:59 UTC (permalink / raw) To: Siddhesh Poyarekar Cc: Ian Kelling, Overseers mailing list, gdb, Mark Wielaard, libc-alpha, binutils, gcc On Sun, Oct 23, 2022 at 05:17:40PM -0400, Siddhesh Poyarekar wrote: >On 2022-10-23 16:57, Christopher Faylor wrote: >> On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote: >> > Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html >> > >> > On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote: >> > > The GNU Toolchain project leadership supports the proposal[1] to move the >> > > services for the GNU Toolchain to the Linux Foundation IT under the auspices of >> > > the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the >> > > OpenSSF and other major donors. >> > >> > Noted, however, a list of signatories does not automatically confer >> > authority over any particular project. Any participation from >> > overseers in moving projects to different infrastructure will require >> > clear approval from the individual projects themselves. >> > >> > Also, the FSF, being the existing fiscal sponsor to these projects, >> > surely needs to review the formal agreements before we sunset our >> > infrastructural offerings to glibc, gcc, binutils, and gdb and hand >> > control of the projects' infrastructure over to a different entity. >> > >> > We'd like to assure the communities that, when and if any individual >> > project formally expresses the decision of their developers to transfer >> > their services, we'll endeavor to make the move as smooth as possible. >> > Those projects that wish to stay will continue to receive the best >> > services that the overseers can offer, with the ongoing assistance of >> > Red Hat, the SFC, and, when relevant, the FSF tech team. >> >> On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote: >> > Given that the current sourceware admins have decided to block migration of >> > all sourceware assets to the LF IT, I don't have a stake on how they'd like >> > to handle this for sourceware. I could however, as a member of TAC (and as >> > member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc), >> > discuss with others the possibility of specific community volunteers being >> > given some amount of access to manage infrastructure. >> >> Stop spreading FUD. The "we" in my statement above, from October 13, >> included fche, mjw, and myself. You have no reason to be confused on >> this subject. >> > >Nope, I'm not spreading FUD, in fact that statement of yours is perfectly >consistent with what I've said: the blocker at the moment is that the >sourceware overseers have refused to hand over the server *in its entirety* >to LF IT, not that any projects themselves have refused to move their >services to LF IT. I don't doubt that the overseers will help in smooth >migration for projects that eventually state that they wish to move over. Your initial implication was that the unreasonable overseers would hold all projects hostage on our current infrastructure. Now you've "clarified" that point by implying that we've been approached to transfer the server "in its entirety" to the LF and have unreasonably refused. Both of those are FUD. You're either intentionally trying to muddy the waters or you're just confused. I'd submit that in either case you should just think about shutting up. You have no special authority to speak for the GTI TAC and your increasingly hostile messages are not helping anyone. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 21:59 ` Christopher Faylor @ 2022-10-24 1:29 ` Siddhesh Poyarekar 0 siblings, 0 replies; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-24 1:29 UTC (permalink / raw) To: Ian Kelling, Overseers mailing list, gdb, Mark Wielaard, libc-alpha, binutils, gcc On 2022-10-23 17:59, Christopher Faylor wrote: > On Sun, Oct 23, 2022 at 05:17:40PM -0400, Siddhesh Poyarekar wrote: >> On 2022-10-23 16:57, Christopher Faylor wrote: >>> On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote: >>>> Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html >>>> >>>> On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote: >>>>> The GNU Toolchain project leadership supports the proposal[1] to move the >>>>> services for the GNU Toolchain to the Linux Foundation IT under the auspices of >>>>> the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the >>>>> OpenSSF and other major donors. >>>> >>>> Noted, however, a list of signatories does not automatically confer >>>> authority over any particular project. Any participation from >>>> overseers in moving projects to different infrastructure will require >>>> clear approval from the individual projects themselves. >>>> >>>> Also, the FSF, being the existing fiscal sponsor to these projects, >>>> surely needs to review the formal agreements before we sunset our >>>> infrastructural offerings to glibc, gcc, binutils, and gdb and hand >>>> control of the projects' infrastructure over to a different entity. >>>> >>>> We'd like to assure the communities that, when and if any individual >>>> project formally expresses the decision of their developers to transfer >>>> their services, we'll endeavor to make the move as smooth as possible. >>>> Those projects that wish to stay will continue to receive the best >>>> services that the overseers can offer, with the ongoing assistance of >>>> Red Hat, the SFC, and, when relevant, the FSF tech team. >>> >>> On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote: >>>> Given that the current sourceware admins have decided to block migration of >>>> all sourceware assets to the LF IT, I don't have a stake on how they'd like >>>> to handle this for sourceware. I could however, as a member of TAC (and as >>>> member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc), >>>> discuss with others the possibility of specific community volunteers being >>>> given some amount of access to manage infrastructure. >>> >>> Stop spreading FUD. The "we" in my statement above, from October 13, >>> included fche, mjw, and myself. You have no reason to be confused on >>> this subject. >>> >> >> Nope, I'm not spreading FUD, in fact that statement of yours is perfectly >> consistent with what I've said: the blocker at the moment is that the >> sourceware overseers have refused to hand over the server *in its entirety* >> to LF IT, not that any projects themselves have refused to move their >> services to LF IT. I don't doubt that the overseers will help in smooth >> migration for projects that eventually state that they wish to move over. > > Your initial implication was that the unreasonable overseers would hold > all projects hostage on our current infrastructure. Absolutely not, you and I have had multiple exchanges on this list so far and I'd have trusted you to take my statement above in the correct context. I did not even negate your statement when you stated that the overseers would support seamless migration of services over to LF IT and in fact supplemented[1] by saying that the transition would likely take years. > Now you've "clarified" > that point by implying that we've been approached to transfer the server > "in its entirety" to the LF and have unreasonably refused. You literally have an email on the list with the subject like "Moving sourceware to the Linux Foundation? no thanks". > Both of those are FUD. You're either intentionally trying to muddy the > waters or you're just confused. I'd submit that in either case you should > just think about shutting up. You have no special authority to speak for > the GTI TAC and your increasingly hostile messages are not helping anyone. It's funny that you're asking me to shut up and also implying that my messages are hostile. Sid [1] https://sourceware.org/pipermail/overseers/2022q4/018987.html ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-17 16:11 ` Siddhesh Poyarekar 2022-10-18 9:50 ` Mark Wielaard @ 2022-10-23 11:33 ` Ian Kelling 2022-10-23 16:17 ` Siddhesh Poyarekar 1 sibling, 1 reply; 31+ messages in thread From: Ian Kelling @ 2022-10-23 11:33 UTC (permalink / raw) To: Overseers mailing list Cc: Siddhesh Poyarekar, gdb, Mark Wielaard, libc-alpha, binutils, gcc Siddhesh Poyarekar via Overseers <overseers@sourceware.org> writes: > I personally do not think the current sourceware infrastructure, even > with the roadmap it promises is a viable alternative to what LF IT can > provide. There is a significant resource gap (e.g. .... > established security and administration practices, ... > that we seem to disagree about. Let's consider some "established security and administration practices" curl -v http://vger.kernel.org | head ... < Server: Apache/2.0.52 (Red Hat) < X-Powered-By: PHP/4.3.9 This is RHEL 3, released in 2003, according to https://people.redhat.com/crunge/RHEL3-package-lists.pdf, The final end of support for this distro was on 2014-01-30. There are CVE's for that version of Apache. I assume their apache is not running in a configuration that makes them actually exploitable, but it is still better security practice upgrade. The kernel is likely from RHEL 3 too. I'm reminded of Greg KH beating the drum that old kernels need upgrades for security, especially because the kernel devs don't always check if a bug is a security issue and especially not for really old kernels ( https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/ ) Notice that link is http because https is not supported by the apache from 2003. Linux kernel development works through patches on mailing lists, and how do you find the patches if you aren't already subscribed to a list? You'd naturally go to the lists main webpage, http://vger.kernel.org, and click "LIST INFO", http://vger.kernel.org/vger-lists.html, and then click one of the list archive links, or maybe the subscribe link. So, those vger.kerne.org pages are an essential part of retrieving upstream kernel patches and security information for some people. And being http only, my isp or anyone in my network path could alter them to be malicious urls that that appear to give the correct result, but actually give malicious kernel patches, or hides away a security relevant patch. Obviously, https for security sensitive pages like these is a basic 101 security practice in 2022. You might think when kernel.org had a major compromise in 2011, 11 years later, they would have managed this basic upgrade. The fact is that the Linux Foundation struggles with getting stuff to current versions and following good security practices like everyone else does. This narrative that there is a huge resource gap in security practices between LF and sourceware is not true, and I don't think the kernel.org IT team would claim that either. They certainly made no such claims in their slide deck about the GTI proposal. If LF IT were to get involved in services for GNU toolchain packages, it should be more of a collaboration with sourceware instead of taking over what sourceware is doing. Competent sysadmin volunteers are rare and valuable to GNU. They help build community, they help GNU stay independent, and they help GNU practice what it preaches. -- Ian Kelling | Senior Systems Administrator, Free Software Foundation GPG Key: B125 F60B 7B28 7FF6 A2B7 DF8F 170A F0E2 9542 95DF https://fsf.org | https://gnu.org ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 11:33 ` Ian Kelling @ 2022-10-23 16:17 ` Siddhesh Poyarekar 2022-10-23 18:56 ` Konstantin Ryabitsev 0 siblings, 1 reply; 31+ messages in thread From: Siddhesh Poyarekar @ 2022-10-23 16:17 UTC (permalink / raw) To: Ian Kelling, Overseers mailing list Cc: gdb, Mark Wielaard, libc-alpha, binutils, gcc, Konstantin Ryabitsev On 2022-10-23 07:33, Ian Kelling wrote: > Siddhesh Poyarekar via Overseers <overseers@sourceware.org> writes: > >> I personally do not think the current sourceware infrastructure, even >> with the roadmap it promises is a viable alternative to what LF IT can >> provide. There is a significant resource gap (e.g. > .... >> established security and administration practices, > ... >> that we seem to disagree about. > > > Let's consider some "established security and administration practices" > > curl -v http://vger.kernel.org | head > ... > < Server: Apache/2.0.52 (Red Hat) > < X-Powered-By: PHP/4.3.9 > > This is RHEL 3, released in 2003, according to > https://people.redhat.com/crunge/RHEL3-package-lists.pdf, > > The final end of support for this distro was on 2014-01-30. > > There are CVE's for that version of Apache. I assume their apache is not > running in a configuration that makes them actually exploitable, but it > is still better security practice upgrade. > > The kernel is likely from RHEL 3 too. I'm reminded of Greg KH beating the > drum that old kernels need upgrades for security, especially because the > kernel devs don't always check if a bug is a security issue and > especially not for really old kernels ( > https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/ > ) > > Notice that link is http because https is not supported by the apache > from 2003. Linux kernel development works through patches on mailing > lists, and how do you find the patches if you aren't already subscribed > to a list? You'd naturally go to the lists main webpage, > http://vger.kernel.org, and click "LIST INFO", > http://vger.kernel.org/vger-lists.html, and then click one of the list > archive links, or maybe the subscribe link. So, those vger.kerne.org > pages are an essential part of retrieving upstream kernel patches and > security information for some people. And being http only, my isp or > anyone in my network path could alter them to be malicious urls that > that appear to give the correct result, but actually give malicious > kernel patches, or hides away a security relevant patch. Obviously, > https for security sensitive pages like these is a basic 101 security > practice in 2022. +Konstantin from LF IT since he's better equipped to speak to this, although ISTM that they started migrating off vger last year[1]. Sid [1] https://www.kernel.org/lists-linux-dev.html Sid ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 16:17 ` Siddhesh Poyarekar @ 2022-10-23 18:56 ` Konstantin Ryabitsev 0 siblings, 0 replies; 31+ messages in thread From: Konstantin Ryabitsev @ 2022-10-23 18:56 UTC (permalink / raw) To: Siddhesh Poyarekar Cc: Ian Kelling, Overseers mailing list, gdb, Mark Wielaard, libc-alpha, binutils, gcc On Sun, Oct 23, 2022 at 12:17:36PM -0400, Siddhesh Poyarekar wrote: > > Let's consider some "established security and administration practices" > > > > curl -v http://vger.kernel.org | head These are all very fair observations, with one important caveat -- vger.kernel.org is the last remaining piece of kernel.org infrastructure that is not managed by our team. It's been historically maintained by volunteers that are not associated with the Linux Foundation (vger used to be hosted at Red Hat, iirc). > +Konstantin from LF IT since he's better equipped to speak to this, although > ISTM that they started migrating off vger last year[1]. Correct, everything is ready for the migration on our end, but we cannot unilaterally initiate the process. The mail server maintained by the Linux Foundation is at subspace.kernel.org. I invite you to poke at it to see if it fares any better compared to vger. Best wishes, Konstantin ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support [not found] <2513b668-9ebd-9e78-7263-dc24f4a9558a@redhat.com> 2022-10-13 18:25 ` Toolchain Infrastructure project statement of support Christopher Faylor @ 2022-10-23 21:19 ` Alexandre Oliva 2022-10-23 22:07 ` Christopher Faylor 1 sibling, 1 reply; 31+ messages in thread From: Alexandre Oliva @ 2022-10-23 21:19 UTC (permalink / raw) To: Carlos O'Donell; +Cc: overseers, gcc, libc-alpha, gdb, binutils On Oct 12, 2022, "Carlos O'Donell via Overseers" <overseers@sourceware.org> wrote: > The GNU Toolchain project leadership Is GNU Toolchain the name of a project? This term has usually meant a set of packages that are part of the GNU Project. Each package has its own set of maintainers appointed by GNU leadership, each one with a commitment to advance the goals of the GNU Project through their maintainership. GNU Project leadership hasn't been consulted, and the proposed move appears to be detrimental to the GNU Project, so it follows that these people are not acting in their capacity of GNU maintainers. As such, any kind of leadership and decision-making arising from these roles must be presumed void and null. Speaking specifically of the GCC Steering Committee, I quote from the very first sentence in https://gcc.gnu.org/steering.html The steering committee was founded in 1998 with the intent of *preventing* *any* particular individual, group or *organization* from *getting* *control* *over* *the* *project*. (highlights are mine) Turning over control over critical project infrastructure, in a way that seemingly places the packages under the umbrella of that single organization, is not in line with the existential reason of the GCC Steering Committee. As such, it must follow that the undersigners are not acting in their capacity of GCC Steering Committee members, which removes any decision-making weight that might have otherwise been presumed from them, due to expectations associated with these roles. That said, I acknowledge that several of them are prominent contributors to GCC, and the GNU Project is happy to welcome contributions from anyone willing to help advance its goals (please do not mistake this as speaking on behalf of the GNU project; I merely state GNU policies and positions to the extend that I'm familiar with and understand them). Several others were relevant developers, as I and RMS have been for quite some time in GNU libc and GCC, respectively. It's interesting to see that past contributors can have a voice, but it appears to me that there has been some bias in the selection of which past voices to actively seek out, and which to dismiss, that places the legitimacy of the pronouncement under further doubt. Anyhow, FWIW, I hereby raise my objection to the proposed outright move of our infrastructure out of Sourceware and into LF. I have a different proposal that is more in line with GNU policies, that GNU maintainers ought to uphold, and with the stated goals of the GCC SC quoted above. I wish to be clear on GNU policy of welcoming contributions that help advance its goals. I, as contributor to the affected packages, and as long-time GNU contributor, do not wish GNU to turn down the resources offered as part of this proposal, any more than I wish GNU to turn down the resources that have long been made available to us by Sourceware. There are significant upsides to using both, to increase our autonomy, rather than jumping from one single point of corporate dependence (AKA autonomy failure :-) to another. It seems fine to me, and also welcome, that groups of contributors pool their individual efforts towards finding resources for the GNU packages they wish to support. I have no objection in principle to our relying on these resources, be they financial or infrastructure, to advance our projects, even if the governance model of each supporting group is independent from and unrelated to the governance structure of GNU. After all, we have no say in Red Hat's internal governance structure and funding of Sourceware, and that hasn't stopped and IMHO shouldn't stop us from accepting that contribution either. So it shouldn't stop us from accepting contributions from the LF, even if we have no say in its governance structure or in the composition of the governing board of the organization or of the brands and subgroups that would affect directly their offer to our packages. As long as the offered resources advance our goals, they are welcome. I don't see that an outright move does, but I do see that increased autonomy and robustness through replication would. Should any such supporting group at any point in the future take actions that conflict with our goal, the GNU Project may then turn them down, and then, as long as critical project infrastructure doesn't make us hostage, we will be no worse off than if the contributions had never been offered in the first place, and presumably even a little ahead because of already-accepted past contributions. It seems very important, however, that we take steps to guard our own autonomy, so as to avoid the risks of finding ourselves in such a hostage situation or of being strongarmed into behaviors we'd not engage in out of our own volition, and even of having our governance structures confused, subverted or replaced by misperceptions about the nature of these supporting structures. To this end, it appears to me that the reliance on multiple supporting groups, each with their own independent governance structures, is a strength we should embrace, by keeping critical package resources replicated across multiple such groups, instead of placing all eggs in a single basket. I urge responsible maintainers of all encompassed projects to take this possibility into account, and also, while planning a transition hopefully into a multi-party infrastructure arrangements, to see what another organization that has long supported the GNU Project, namely the FSF, has to offer, and rely on its resources as well. I'd also encourage people involved in this initiative to look into directing part of the raised funds towards paying *other* organizations for infrastructure services, in addition to the LF itself. I expect the FSF could and would welcome this, and, just as there are contributors and users who trust the LF better than the FSF, there are others who trust the FSF better than the LF, and having trustworthy parties involved in offering replicated/redundant infrastructure would likely make everyone more comfortable. I'd perceive this decentralization as yet another positive development towards increasing our autonomy and robustness towards preventing any particular individual, group or organization from getting control over the project. Accepting multiple such contributions, we also preemptively dispell any potential assumptions that the GNU packages themselves, or their governance structures, are in any way under the authority of the governance structures of any of the infrastructure suppliers or funding channels. Please find a few other points below. > We believe that utilizing the experience and infrastructure of the LF IT team > that already is used by the Linux kernel community will provide the most > effective solution and best experience for the GNU Toolchain developer > community. I'm curious as to any facts that support this statement. Without risk-cost-benefit analyses of the actual offer, and comparison with at least a few alternatives, it feels more like an expression of enchantment for promises made by a politician during an electoral run than anything one could count on. Gratis offers are often bait-and-switch or other kinds of traps, so caution is advisable when accepting them. Considering that, in the end, the decisions wouldn't even be made by the proponents themselves, it doesn't smell good to me. But then, again, unless we're silly enough as to jump in without safety jackets, or we are dragged in by force, I have no objections to accepting contributions from this supporting group on a tentative basis. That means, at least at first, replicating rather than moving; rolling out new services (with viable plans to replicate them) rather than replacing existing ones. So far, there's no clarity to me as to the proposed plans of moving services and how this would impact or benefit us, which makes it impossible to have any rational grounds for any decision whatsoever. I look forward to tomorrow's presentation about expected benefits, so that we can reason about them and see how to retain them in the multi-party infrastructure scenario I propose. It doesn't smell good, however, that Sourceware has been prevented from presenting its own expansion plans and proposals at the Cauldron. I wish it too gets a chance to extend their offer. There's no basis for a rational decision in refusing to listen to alternatives; it comes across to me as acknowledgment that a weaker proposal wishes to prevail by denying others any consideration. > 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. That is nice. What has LF IT responded? AFAICT, it doesn't look like they took it to heart. So far, not even the infrastructure for meetings has been based on Free Software, and that's not a very hopeful sign. Still, it's worth keeping in mind that, when it comes to infrastructure offered by third parties, the use of Free Software benefits the infrastructure providers, but as for the freedom of users of that infrastructure, both as people and as packages or projects, the arrangement is a Service as a Software Substitute, SaaSS, which is in most freedom-related aspects even worse than nonfree software. https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html Outsourcing key infrastructure (as opposed to relying on community members to maintain it) creates a detrimental power dynamic, that requires working harder to maintain a group's autonomy. Relying exclusively on Free Software alleviates some of the extra difficulties, but because of the SaaSS dynamics, it does not solve them entirely. Thus my recommendation to pursue multiple redundant infrastructure providers, for the sake of our autonomy. > If Free Software versions of necessary security tools are missing, GTI > will work with Free Software supporters to develop Free Software > alternatives. There are no "necessary security tools" for GNU that are nonfree, but an implication of this phrasing is that, if any are found or framed as such, they'd end up being used, because of "necessary", until an alternative is developed and readied for use. Still worrysome is that OpenSSF policies disfavor strong copyleft, so even if such tools end up being developed and released as Free Software, GNU might find itself relying on non-copyleft, push-over licenses. While these are not unethical, associating ourselves with an organization that has an anti-copyleft bias raises quite some red flags for me. Could your supporting infrastructure initiative negotiate some arrangement with the OpenSSF so that any "necessary security tools" developed in responses to our needs (even if addressing others' needs as well) be released under strong copyleft, such as GNU GPLv3+? Could they be contributed to the GNU Project? Thanks for listening, -- 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] 31+ messages in thread
* Re: Toolchain Infrastructure project statement of support 2022-10-23 21:19 ` Alexandre Oliva @ 2022-10-23 22:07 ` Christopher Faylor 0 siblings, 0 replies; 31+ messages in thread From: Christopher Faylor @ 2022-10-23 22:07 UTC (permalink / raw) To: Alexandre Oliva Cc: Carlos O'Donell, gcc, overseers, libc-alpha, binutils, gdb vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv On Sun, Oct 23, 2022 at 06:19:33PM -0300, Alexandre Oliva wrote: >It doesn't smell good, however, that Sourceware has been prevented from presenting its own >expansion plans and proposals at the Cauldron. I wish it too gets a chance to extend their offer. >There's no basis for a rational decision in refusing to listen to alternatives; it comes across to >me as acknowledgment that a weaker proposal wishes to prevail by denying others any consideration. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Toolchain Infrastructure project statement of support @ 2022-10-12 17:40 Carlos O'Donell 0 siblings, 0 replies; 31+ messages in thread From: Carlos O'Donell @ 2022-10-12 17:40 UTC (permalink / raw) To: Binutils We're excited to post a statement of support for the direction we're moving with the infrastructure for the GNU Toolchain: https://sourceware.org/pipermail/overseers/2022q4/018981.html We look forward to supporting the GTI TAC and community to work through the technical details of the proposal to use LF IT services. Thanks, Carlos and David ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2022-10-24 1:51 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <2513b668-9ebd-9e78-7263-dc24f4a9558a@redhat.com> 2022-10-13 18:25 ` Toolchain Infrastructure project statement of support Christopher Faylor 2022-10-14 12:33 ` Siddhesh Poyarekar 2022-10-17 15:10 ` Mark Wielaard 2022-10-17 16:11 ` Siddhesh Poyarekar 2022-10-18 9:50 ` Mark Wielaard 2022-10-18 15:17 ` Siddhesh Poyarekar 2022-10-18 16:42 ` Christopher Faylor 2022-10-18 18:13 ` Siddhesh Poyarekar 2022-10-18 18:14 ` Siddhesh Poyarekar 2022-10-18 18:47 ` Paul Smith 2022-10-21 0:33 ` Alexandre Oliva 2022-10-23 8:59 ` Ian Kelling 2022-10-23 13:27 ` Siddhesh Poyarekar 2022-10-23 15:16 ` Frank Ch. Eigler 2022-10-23 16:07 ` Siddhesh Poyarekar 2022-10-23 16:32 ` Siddhesh Poyarekar 2022-10-23 17:01 ` Jeff Law 2022-10-23 22:35 ` Christopher Faylor 2022-10-23 17:09 ` Frank Ch. Eigler 2022-10-23 17:38 ` Jeff Law 2022-10-24 1:51 ` Siddhesh Poyarekar 2022-10-23 20:57 ` Christopher Faylor 2022-10-23 21:17 ` Siddhesh Poyarekar 2022-10-23 21:59 ` Christopher Faylor 2022-10-24 1:29 ` Siddhesh Poyarekar 2022-10-23 11:33 ` Ian Kelling 2022-10-23 16:17 ` Siddhesh Poyarekar 2022-10-23 18:56 ` Konstantin Ryabitsev 2022-10-23 21:19 ` Alexandre Oliva 2022-10-23 22:07 ` Christopher Faylor 2022-10-12 17:40 Carlos O'Donell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).