* Re: [Action Required] glibc decision to use CTI services. [not found] <b84ea4a5-651a-1a4c-06c8-e9ade4b7d702@redhat.com> @ 2023-08-30 17:19 ` Alexandre Oliva 2023-08-30 17:31 ` Joseph Myers ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: Alexandre Oliva @ 2023-08-30 17:19 UTC (permalink / raw) To: Carlos O'Donell Cc: Joseph Myers, Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov, Jakub Jelinek, Andreas Schwab, libc-alpha [adding libc-alpha, where GNU libc discussions are held] On Aug 29, 2023, "Carlos O'Donell" <carlos@redhat.com> wrote: > I propose the glibc project migrate to services provided by the > Core Toolchain Infrastructure (CTI) project, particularly services > provided by the Linux Foundation IT team. Nay. I do not perceive any benefits to GNU's values in becoming technologically dependent on an organization that never shared GNU's values, that has constantly pretended GNU didn't exist, persistently claimed our work to itself, and promotes and operates under values that conflict deeply with those that GNU stands for. It would amount to shooting itself in the paws. I acknowledge that the present supplier of equivalent services also started in a hostile manner, but at this point it's the devil we know. The plan should IMHO be to mitigate that dependency, not introduce another or replace one with a worse one. As I suggested back when this idea was first raised (and AFAICT there have been no attempts to dispute that this would be a better path to pursue), I'd be happy to accept this sort of contribution to GNU *iff* the services were *actively* *replicated* among two or three separate suppliers, so as to reduce the risk of dependency and of corrupting pressure on us. Even then, this would IMHO be a move for GNU to decide, or at the very least be consulted on, according to its own values and priorities, something that all mantainers appointed by GNU, myself included, committed ourselves to observe, prioritize and uphold as maintainers of GNU packages. I encourage other maintainers to justify their responses based on GNU's values and priorities, as they understand them. -- 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. Think Assange & Stallman. The empires strike back ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-30 17:19 ` [Action Required] glibc decision to use CTI services Alexandre Oliva @ 2023-08-30 17:31 ` Joseph Myers 2023-08-31 19:59 ` Paul Eggert ` (2 more replies) 2023-08-31 8:37 ` Mark Wielaard 2023-08-31 10:34 ` Florian Weimer 2 siblings, 3 replies; 33+ messages in thread From: Joseph Myers @ 2023-08-30 17:31 UTC (permalink / raw) To: Alexandre Oliva Cc: Carlos O'Donell, Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov, Jakub Jelinek, Andreas Schwab, libc-alpha On Wed, 30 Aug 2023, Alexandre Oliva wrote: > Even then, this would IMHO be a move for GNU to decide, or at the very > least be consulted on, according to its own values and priorities, > something that all mantainers appointed by GNU, myself included, > committed ourselves to observe, prioritize and uphold as maintainers of > GNU packages. I encourage other maintainers to justify their responses > based on GNU's values and priorities, as they understand them. I believe the LF has already agreed to implement the hosting entirely with free software. Naturally we should make sure that other requirements from https://www.gnu.org/software/repo-criteria.en.html such as "Does not discriminate against classes of users, or against any country. (C2)" and "Permits access via Tor (we consider this an important site function). (C3)" are met, though I don't expect problems there. Several criteria are trivally met or inapplicable simply because they concern things that are beyond the scope of this proposed hosting (for example, recommending particular choices of license, or offering choices of license, is entirely outside the scope of what these hosting facilities do, just as it's outside the scope of what Sourceware does - those are criteria for general-purpose hosting sites that anyone might add a package to). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-30 17:31 ` Joseph Myers @ 2023-08-31 19:59 ` Paul Eggert 2023-09-01 6:03 ` Sam James ` (3 more replies) 2023-09-01 15:09 ` Alexandre Oliva 2023-09-27 13:50 ` Carlos O'Donell 2 siblings, 4 replies; 33+ messages in thread From: Paul Eggert @ 2023-08-31 19:59 UTC (permalink / raw) To: Joseph Myers, Alexandre Oliva Cc: Carlos O'Donell, Ryan S. Arnold, Maxim Kuvyrkov, Jakub Jelinek, Andreas Schwab, libc-alpha On 2023-08-30 10:31, Joseph Myers wrote: > I believe the LF has already agreed to implement the hosting entirely with > free software. Where is this agreement written down? I didn't see it in the URLs mentioned at the start of this thread. Too often it is tempting to use non-free software in these enterprises, and we need to have an agreement and a commitment about an enforcement mechanism that detects and repairs things if somebody falls victim to this temptation (and of course that guides people away from succumbing to the temptation in the first place). This detection and enforcement mechanism has to be usable by glibc software contributors and maintainers, not just by the CTI providers. As I'm new to this (I just read yesterday that a decision is wanted by today) I'll vote NAY until I see something more binding about this important issue. > Naturally we should make sure that other requirements from > https://www.gnu.org/software/repo-criteria.en.html ... are met, though I don't expect problems there. Although I don't expect problems either, I'd like to see this written down as well. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-31 19:59 ` Paul Eggert @ 2023-09-01 6:03 ` Sam James 2023-09-01 8:55 ` Florian Weimer 2023-09-01 12:30 ` Siddhesh Poyarekar 2023-09-01 9:08 ` Mark Wielaard ` (2 subsequent siblings) 3 siblings, 2 replies; 33+ messages in thread From: Sam James @ 2023-09-01 6:03 UTC (permalink / raw) To: Paul Eggert, Mark Wielaard Cc: Joseph Myers, Alexandre Oliva, Jakub Jelinek, Andreas Schwab, Maxim Kuvyrkov, libc-alpha Paul Eggert <eggert@cs.ucla.edu> writes: > On 2023-08-30 10:31, Joseph Myers wrote: >> I believe the LF has already agreed to implement the hosting entirely with >> free software. > > Where is this agreement written down? I didn't see it in the URLs > mentioned at the start of this thread. > > Too often it is tempting to use non-free software in these > enterprises, and we need to have an agreement and a commitment about > an enforcement mechanism that detects and repairs things if somebody > falls victim to this temptation (and of course that guides people away > from succumbing to the temptation in the first place). This detection > and enforcement mechanism has to be usable by glibc software > contributors and maintainers, not just by the CTI providers. > > As I'm new to this (I just read yesterday that a decision is wanted by > today) I'll vote NAY until I see something more binding about this > important issue. > It's still unclear to me what problems this will solve compared to using sourceware. As far as I've seen, the sourceware overseers handle requests promptly. Is there something we've asked them to do which they've been unable to fulfill? thanks, sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 6:03 ` Sam James @ 2023-09-01 8:55 ` Florian Weimer 2023-09-01 9:02 ` Sam James ` (2 more replies) 2023-09-01 12:30 ` Siddhesh Poyarekar 1 sibling, 3 replies; 33+ messages in thread From: Florian Weimer @ 2023-09-01 8:55 UTC (permalink / raw) To: Sam James via Libc-alpha Cc: Paul Eggert, Mark Wielaard, Sam James, Jakub Jelinek, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov * Sam James via Libc-alpha: > As far as I've seen, the sourceware overseers handle requests > promptly. Is there something we've asked them to do which they've > been unable to fulfill? Removing the From: header rewriting from the mailing lists, including libc-alpha. With the current list configuration, “git am” often does not produce correct results. Thanks, Florian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 8:55 ` Florian Weimer @ 2023-09-01 9:02 ` Sam James 2023-09-01 9:21 ` dmarc, dkim and From rewriting Mark Wielaard 2023-09-01 9:03 ` [Action Required] glibc decision to use CTI services Andrew Pinski 2023-09-01 13:32 ` Frank Ch. Eigler 2 siblings, 1 reply; 33+ messages in thread From: Sam James @ 2023-09-01 9:02 UTC (permalink / raw) To: Florian Weimer Cc: Jakub Jelinek, Andreas Schwab, Mark Wielaard, Joseph Myers, Maxim Kuvyrkov, libc-alpha Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes: > * Sam James via Libc-alpha: > >> As far as I've seen, the sourceware overseers handle requests >> promptly. Is there something we've asked them to do which they've >> been unable to fulfill? > > Removing the From: header rewriting from the mailing lists, including > libc-alpha. With the current list configuration, “git am” often does > not produce correct results. Have we communicated that to the overseers though (that it's so serious it's worth moving services over)? Obviously there's https://sourceware.org/bugzilla/show_bug.cgi?id=29713 already from you, but that's not the same as "this is a showstopper". I wasn't aware this was a serious blocker given b2 helps collect the Reviewed-bys anyway. But I can understand it being a pain for some people's workflows. thanks, sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* dmarc, dkim and From rewriting 2023-09-01 9:02 ` Sam James @ 2023-09-01 9:21 ` Mark Wielaard 2023-09-01 11:52 ` Florian Weimer 0 siblings, 1 reply; 33+ messages in thread From: Mark Wielaard @ 2023-09-01 9:21 UTC (permalink / raw) To: Sam James Cc: Florian Weimer, Jakub Jelinek, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov, libc-alpha Hi, On Fri, Sep 01, 2023 at 10:02:23AM +0100, Sam James via Libc-alpha wrote: > Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes: > > * Sam James via Libc-alpha: > > > >> As far as I've seen, the sourceware overseers handle requests > >> promptly. Is there something we've asked them to do which they've > >> been unable to fulfill? > > > > Removing the From: header rewriting from the mailing lists, including > > libc-alpha. With the current list configuration, “git am” often does > > not produce correct results. > > Have we communicated that to the overseers though (that it's so serious > it's worth moving services over)? > Obviously there's https://sourceware.org/bugzilla/show_bug.cgi?id=29713 > already from you, but that's not the same as "this is a showstopper". > > I wasn't aware this was a serious blocker given b2 helps collect the > Reviewed-bys anyway. But I can understand it being a pain for some > people's workflows. Sorry this is being resolved slowly. But as you can see in the bug progress is being made, we just upgraded our mailman instance again last week. I had requested testers a couple of months ago [1], but didn't get much/any response, so I thought this wasn't very urgent. I think we are ready to switch the list to not use From rewriting for lists that want that. We could test it next week? Cheers, Mark [1] https://inbox.sourceware.org/libc-alpha/Y2GocuarFslwvb9j@wildebeest.org/ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: dmarc, dkim and From rewriting 2023-09-01 9:21 ` dmarc, dkim and From rewriting Mark Wielaard @ 2023-09-01 11:52 ` Florian Weimer 0 siblings, 0 replies; 33+ messages in thread From: Florian Weimer @ 2023-09-01 11:52 UTC (permalink / raw) To: Mark Wielaard Cc: Sam James, Jakub Jelinek, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov, libc-alpha * Mark Wielaard: > Sorry this is being resolved slowly. But as you can see in the bug > progress is being made, we just upgraded our mailman instance again > last week. I had requested testers a couple of months ago [1], but > didn't get much/any response, so I thought this wasn't very urgent. I > think we are ready to switch the list to not use From rewriting for > lists that want that. We could test it next week? > [1] https://inbox.sourceware.org/libc-alpha/Y2GocuarFslwvb9j@wildebeest.org/ I read <https://sourceware.org/bugzilla/show_bug.cgi?id=29713#c35> and comments in the vicinity as expressing a desire not to make the change (i.e., keep From: header rewriting) for compatibility with DKIM defaults in certain widely deploy free software MTAs. Thanks, Florian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 8:55 ` Florian Weimer 2023-09-01 9:02 ` Sam James @ 2023-09-01 9:03 ` Andrew Pinski 2023-09-01 11:49 ` Florian Weimer 2023-09-01 13:32 ` Frank Ch. Eigler 2 siblings, 1 reply; 33+ messages in thread From: Andrew Pinski @ 2023-09-01 9:03 UTC (permalink / raw) To: Florian Weimer Cc: Sam James via Libc-alpha, Jakub Jelinek, Andreas Schwab, Mark Wielaard, Joseph Myers, Maxim Kuvyrkov On Fri, Sep 1, 2023 at 1:56 AM Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> wrote: > > * Sam James via Libc-alpha: > > > As far as I've seen, the sourceware overseers handle requests > > promptly. Is there something we've asked them to do which they've > > been unable to fulfill? > > Removing the From: header rewriting from the mailing lists, including > libc-alpha. With the current list configuration, “git am” often does > not produce correct results. Isn't that due to security (anti-spam) measures of many ISPs? How can someone solve that issue without the rewriting due to mailing lists and security measures not going hand in hand these days? Thanks, Andrew > > Thanks, > Florian > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 9:03 ` [Action Required] glibc decision to use CTI services Andrew Pinski @ 2023-09-01 11:49 ` Florian Weimer 0 siblings, 0 replies; 33+ messages in thread From: Florian Weimer @ 2023-09-01 11:49 UTC (permalink / raw) To: Andrew Pinski Cc: Sam James via Libc-alpha, Jakub Jelinek, Andreas Schwab, Mark Wielaard, Joseph Myers, Maxim Kuvyrkov * Andrew Pinski: > On Fri, Sep 1, 2023 at 1:56 AM Florian Weimer via Libc-alpha > <libc-alpha@sourceware.org> wrote: >> >> * Sam James via Libc-alpha: >> >> > As far as I've seen, the sourceware overseers handle requests >> > promptly. Is there something we've asked them to do which they've >> > been unable to fulfill? >> >> Removing the From: header rewriting from the mailing lists, including >> libc-alpha. With the current list configuration, “git am” often does >> not produce correct results. > > Isn't that due to security (anti-spam) measures of many ISPs? No, not really, it's about preserving the integrity of messages. Something that we should interested in anyway, particularly for patches. Historically, Mailman promoted editing of messages in various ways while distributing them over the list, and DKIM/DMARC prevents that. > How can someone solve that issue without the rewriting due to mailing > lists and security measures not going hand in hand these days? It's true that the default DKIM configuration in Debian & Co. prevents forwarding of DKIM-signed mail over mailing lists while preserving the signature: they explicitly sign message in such a way that they assert the non-existence of headers related to mailing lists. Empirically, the large mail operators and most corporations (as long as they do not use Debian & Co.) simply don't do this. Their signatures only cover the body and critical headers already included in the message (and which the mailing list software does not need to alter). For others, it's just a minor configuration change, which is hopefully easy to implement for smaller organizations. Mailing lists without From: rewriting are not unusual at all: gnu.org, kernel.org, openjdk.java.net all operate in this way, to name just a few. So upstream participation often requires that you use a mail service that does not prohibit distributing mail over mailing lists. There's one remaining issue: what to do with mail that has HTML alternate parts that you want to remove as a list policy matter. This requires stripping certain DKIM signatures, which in turn my necessitate From: header rewriting, depending on the DMARC policy. But this unlikely to get implemented in the Red Hat version of Mailman 2 (that sourceware.org uses). Thanks, Florian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 8:55 ` Florian Weimer 2023-09-01 9:02 ` Sam James 2023-09-01 9:03 ` [Action Required] glibc decision to use CTI services Andrew Pinski @ 2023-09-01 13:32 ` Frank Ch. Eigler 2 siblings, 0 replies; 33+ messages in thread From: Frank Ch. Eigler @ 2023-09-01 13:32 UTC (permalink / raw) To: Florian Weimer Cc: Sam James via Libc-alpha, Paul Eggert, Mark Wielaard, Sam James, Jakub Jelinek, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov fweimer wrote: >> As far as I've seen, the sourceware overseers handle requests >> promptly. Is there something we've asked them to do which they've >> been unable to fulfill? > > Removing the From: header rewriting from the mailing lists, including > libc-alpha. [...] Each mailing list has its own administrator, who has the power to switch off these mailman2 spam-proofing measures (at their own risk of course). - FChE ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 6:03 ` Sam James 2023-09-01 8:55 ` Florian Weimer @ 2023-09-01 12:30 ` Siddhesh Poyarekar 2023-09-01 14:54 ` Paul Eggert 2023-09-01 15:01 ` Sam James 1 sibling, 2 replies; 33+ messages in thread From: Siddhesh Poyarekar @ 2023-09-01 12:30 UTC (permalink / raw) To: Sam James, Paul Eggert, Mark Wielaard Cc: Jakub Jelinek, libc-alpha, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov On 2023-09-01 02:03, Sam James via Libc-alpha wrote: > > Paul Eggert <eggert@cs.ucla.edu> writes: > >> On 2023-08-30 10:31, Joseph Myers wrote: >>> I believe the LF has already agreed to implement the hosting entirely with >>> free software. >> >> Where is this agreement written down? I didn't see it in the URLs >> mentioned at the start of this thread. >> >> Too often it is tempting to use non-free software in these >> enterprises, and we need to have an agreement and a commitment about >> an enforcement mechanism that detects and repairs things if somebody >> falls victim to this temptation (and of course that guides people away >> from succumbing to the temptation in the first place). This detection >> and enforcement mechanism has to be usable by glibc software >> contributors and maintainers, not just by the CTI providers. It is the Technical Advisory Committee that decides on the infrastructure tech and that is comprised completely of members from the GNU toolchain community. We will make sure that glibc services are implemented using Free software. >> >> As I'm new to this (I just read yesterday that a decision is wanted by >> today) I'll vote NAY until I see something more binding about this >> important issue. >> > > It's still unclear to me what problems this will solve compared to > using sourceware. > > As far as I've seen, the sourceware overseers handle requests > promptly. Is there something we've asked them to do which they've > been unable to fulfill? There was a fairly long thread here and on overseers list last year on the motivation for moving to LFIT, if that's what you're asking about. To summarize, it's not about the overseers, who have indeed been prompt in handling requests and providing support for existing infrastructure. It's about doing things like service isolation, future enhancements/scaling and dedicated devops, that current infrastructure (that we depend on Red Hat to provide) is unable to support. Essentially, this is a move from Red Hat to LF. Sid ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 12:30 ` Siddhesh Poyarekar @ 2023-09-01 14:54 ` Paul Eggert 2023-09-01 16:08 ` Siddhesh Poyarekar 2023-09-01 15:01 ` Sam James 1 sibling, 1 reply; 33+ messages in thread From: Paul Eggert @ 2023-09-01 14:54 UTC (permalink / raw) To: Siddhesh Poyarekar, Sam James, Mark Wielaard Cc: Jakub Jelinek, libc-alpha, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov, Carlos O'Donell On 2023-09-01 05:30, Siddhesh Poyarekar wrote: > It is the Technical Advisory Committee that decides on the > infrastructure tech and that is comprised completely of members from the > GNU toolchain community. We will make sure that glibc services are > implemented using Free software. This sounds good, but I don't see the Linux Foundation agreeing to it in the URLs Carlos mentioned at the start of this thread (see below). What I see are statements[1][2] from the GNU Toolchain Infrastructure project that GTI has "requested" that only free software be used. This is not the same thing. It'd be helpful to have a statement from the Linux Foundation that they agree to use only free software to support glibc, and that GTI's Technical Advisory Committee is empowered to inspect the Core Toolchain Infrastructure used for glibc, so that the GTI TAC can verify that only free software is used. This shouldn't be that much to ask for. And I would think that the Linux Foundation would welcome such an agreement, not only because the Linux Foundation wants to support free software, but because it wants its infrastructure to be open and checkable and usable by others. > it's not about the overseers, who have indeed been prompt in handling requests and providing support for existing infrastructure. It's about doing things like service isolation, future enhancements/scaling and dedicated devops It would indeed be nice to have things like that. Here are the URLs from Carlos's earlier email. > [1] https://sourceware.org/pipermail/overseers/2022q3/018896.html > [2] https://sourceware.org/pipermail/overseers/2022q4/018981.html > [3] https://lore.kernel.org/gti-tac/804cee43-a120-3acf-a302-b1640f2285a9@redhat.com/ > [4] https://lore.kernel.org/cti-tac/47d5d7a0-60ab-b400-2f75-880fdaae0738@redhat.com/T/#u > [5] https://sourceware.org/pipermail/libc-alpha/2023-August/150610.html > [6] https://sourceware.org/pipermail/libc-alpha/2023-July/150071.html ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 14:54 ` Paul Eggert @ 2023-09-01 16:08 ` Siddhesh Poyarekar 0 siblings, 0 replies; 33+ messages in thread From: Siddhesh Poyarekar @ 2023-09-01 16:08 UTC (permalink / raw) To: Paul Eggert, Sam James, Mark Wielaard Cc: Jakub Jelinek, libc-alpha, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov, Carlos O'Donell On 2023-09-01 10:54, Paul Eggert wrote: > On 2023-09-01 05:30, Siddhesh Poyarekar wrote: > >> It is the Technical Advisory Committee that decides on the >> infrastructure tech and that is comprised completely of members from >> the GNU toolchain community. We will make sure that glibc services >> are implemented using Free software. > > This sounds good, but I don't see the Linux Foundation agreeing to it in > the URLs Carlos mentioned at the start of this thread (see below). What > I see are statements[1][2] from the GNU Toolchain Infrastructure project > that GTI has "requested" that only free software be used. This is not > the same thing. > > It'd be helpful to have a statement from the Linux Foundation that they > agree to use only free software to support glibc, and that GTI's > Technical Advisory Committee is empowered to inspect the Core Toolchain > Infrastructure used for glibc, so that the GTI TAC can verify that only > free software is used. > > This shouldn't be that much to ask for. And I would think that the Linux > Foundation would welcome such an agreement, not only because the Linux > Foundation wants to support free software, but because it wants its > infrastructure to be open and checkable and usable by others. Ack, I'll leave this for Carlos to bring up with LF. As far as my understanding goes, it's upon us as TAC to drive this but we can figure out the specifics. Thanks, Sid ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 12:30 ` Siddhesh Poyarekar 2023-09-01 14:54 ` Paul Eggert @ 2023-09-01 15:01 ` Sam James 2023-09-01 16:19 ` Frank Ch. Eigler ` (2 more replies) 1 sibling, 3 replies; 33+ messages in thread From: Sam James @ 2023-09-01 15:01 UTC (permalink / raw) To: Siddhesh Poyarekar Cc: Sam James, Paul Eggert, Mark Wielaard, Jakub Jelinek, libc-alpha, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov Siddhesh Poyarekar <siddhesh@gotplt.org> writes: > On 2023-09-01 02:03, Sam James via Libc-alpha wrote: >> Paul Eggert <eggert@cs.ucla.edu> writes: >> >>> On 2023-08-30 10:31, Joseph Myers wrote: >>>> I believe the LF has already agreed to implement the hosting entirely with >>>> free software. >>> >>> Where is this agreement written down? I didn't see it in the URLs >>> mentioned at the start of this thread. >>> >>> Too often it is tempting to use non-free software in these >>> enterprises, and we need to have an agreement and a commitment about >>> an enforcement mechanism that detects and repairs things if somebody >>> falls victim to this temptation (and of course that guides people away >>> from succumbing to the temptation in the first place). This detection >>> and enforcement mechanism has to be usable by glibc software >>> contributors and maintainers, not just by the CTI providers. > > It is the Technical Advisory Committee that decides on the > infrastructure tech and that is comprised completely of members from > the GNU toolchain community. We will make sure that glibc services > are implemented using Free software. Thank you. > >>> >>> As I'm new to this (I just read yesterday that a decision is wanted by >>> today) I'll vote NAY until I see something more binding about this >>> important issue. >>> >> It's still unclear to me what problems this will solve compared to >> using sourceware. >> As far as I've seen, the sourceware overseers handle requests >> promptly. Is there something we've asked them to do which they've >> been unable to fulfill? > > There was a fairly long thread here and on overseers list last year on > the motivation for moving to LFIT, if that's what you're asking > about. Thanks - I did read that at the time, but I wasn't very specific here, sorry. I guess I meant I don't really understand the transition plan if it goes ahead. While we know they handle kernel.org fine, I'm a bit nervous about it being an unknown entity wrt glibc - and also whether it needs to be all or nothing. Could they not provide services in addition to sourceware, at least initially? Do we need to move all the eggs? Or, to put it another way: it just seems like a leap into the unknown and I don't really get why it's worth it yet. > To summarize, it's not about the overseers, who have indeed > been prompt in handling requests and providing support for existing > infrastructure. It's about doing things like service isolation, future > enhancements/scaling and dedicated devops, that current infrastructure > (that we depend on Red Hat to provide) is unable to > support. Essentially, this is a move from Red Hat to LF. > Have we actually hit scaling issues? The only real thing we need to scale up is our testing AFAIK - which we have builder.sourceware.org for now and it's growing. I can see the advantage in dedicated devops and service isolation - although I don't know if sw has given an opinion on whether they can do service isolation. best, sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 15:01 ` Sam James @ 2023-09-01 16:19 ` Frank Ch. Eigler 2023-09-01 16:30 ` Siddhesh Poyarekar 2023-09-02 18:25 ` Mark Wielaard 2 siblings, 0 replies; 33+ messages in thread From: Frank Ch. Eigler @ 2023-09-01 16:19 UTC (permalink / raw) To: Sam James Cc: Siddhesh Poyarekar, Paul Eggert, Mark Wielaard, Jakub Jelinek, libc-alpha, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov sam wrote: > [...] I can see the advantage in dedicated devops and service > isolation - although I don't know if sw has given an opinion on > whether they can do service isolation. [...] For what it's worth, I don't recall seeing an actual complete worked-out plan for precisely what kinds of isolation are desired (never mind why), and how they would all be provided at LF. Therefore, it has not been possible for sourceware folks to contemplate providing an equivalent. - FChE ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 15:01 ` Sam James 2023-09-01 16:19 ` Frank Ch. Eigler @ 2023-09-01 16:30 ` Siddhesh Poyarekar 2023-09-02 18:25 ` Mark Wielaard 2 siblings, 0 replies; 33+ messages in thread From: Siddhesh Poyarekar @ 2023-09-01 16:30 UTC (permalink / raw) To: Sam James Cc: Paul Eggert, Mark Wielaard, Jakub Jelinek, libc-alpha, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov On 2023-09-01 11:01, Sam James wrote: > Thanks - I did read that at the time, but I wasn't very specific here, > sorry. I guess I meant I don't really understand the transition plan > if it goes ahead. We've been discussing it in some detail on the CTI TAG mailing list[1]. The actual transition plan will come when the stewards vote to actually approve this. It would be a waste of time if there's no interest among the stewards to move services to LFIT. > While we know they handle kernel.org fine, I'm a bit nervous > about it being an unknown entity wrt glibc - and also whether > it needs to be all or nothing. Yes there are differences but they're all workflow related. In terms of setup and scale though, glibc is in the noise compared to the kernel and what we're really hoping for is to pick up some of the infrastructure they already have for the kernel, e.g. patchwork automation and pre-commit CI. At the moment there are at least 3 people (including me) spending time on this when we could be doing something else. It's also not really all or nothing. I expect some services to remain on sourceware because they're distributed by default, e.g. builder. > Could they not provide services in addition to sourceware, > at least initially? Do we need to move all the eggs? > > Or, to put it another way: it just seems like a leap into the unknown > and I don't really get why it's worth it yet. We've been discussing this for some years now (in the true spirit of conservatism that is prevalent in the GNU toolchain community when it comes to major changes), so I don't know if it's fair to look at it as a leap into the unknown :) >> To summarize, it's not about the overseers, who have indeed >> been prompt in handling requests and providing support for existing >> infrastructure. It's about doing things like service isolation, future >> enhancements/scaling and dedicated devops, that current infrastructure >> (that we depend on Red Hat to provide) is unable to >> support. Essentially, this is a move from Red Hat to LF. >> > > Have we actually hit scaling issues? The only real thing we need to > scale up is our testing AFAIK - which we have builder.sourceware.org for now > and it's growing. The builder doesn't really need the sourceware server to scale. I don't think glibc singularly has hit scaling issues but it shares the same instance of most services with most other sourceware projects, not to mention the fact that it's all on one machine. That is a *lot* of core software crammed into a single box. > I can see the advantage in dedicated devops and service isolation - > although I don't know if sw has given an opinion on whether they can > do service isolation. I don't think Red Hat has the infrastructure behind sourceware to do anything more than it currently does. It's all just one machine. I don't know if anybody made requests for it though. Thanks, Sid [1] https://lore.kernel.org/cti-tac/b1fa024-2144-2645-bdc5-96588a529cf0@codesourcery.com/T/#t ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-01 15:01 ` Sam James 2023-09-01 16:19 ` Frank Ch. Eigler 2023-09-01 16:30 ` Siddhesh Poyarekar @ 2023-09-02 18:25 ` Mark Wielaard 2 siblings, 0 replies; 33+ messages in thread From: Mark Wielaard @ 2023-09-02 18:25 UTC (permalink / raw) To: Sam James Cc: Paul Eggert, Jakub Jelinek, libc-alpha, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov Hi Sam, On Fri, Sep 01, 2023 at 04:01:02PM +0100, Sam James wrote: > >>> As I'm new to this (I just read yesterday that a decision is wanted by > >>> today) I'll vote NAY until I see something more binding about this > >>> important issue. > >>> > >> It's still unclear to me what problems this will solve compared to > >> using sourceware. > >> As far as I've seen, the sourceware overseers handle requests > >> promptly. Is there something we've asked them to do which they've > >> been unable to fulfill? > > > > There was a fairly long thread here and on overseers list last year on > > the motivation for moving to LFIT, if that's what you're asking > > about. > > Thanks - I did read that at the time, but I wasn't very specific here, > sorry. I guess I meant I don't really understand the transition plan > if it goes ahead. > > While we know they handle kernel.org fine, I'm a bit nervous > about it being an unknown entity wrt glibc - and also whether > it needs to be all or nothing. > > Could they not provide services in addition to sourceware, > at least initially? Do we need to move all the eggs? > > Or, to put it another way: it just seems like a leap into the unknown > and I don't really get why it's worth it yet. As others said there is no transition plan, just a list of services Sourceware currently provides, some of which LF IT might also be able to provide. There are also (less detailed) Sourceware services lists at https://sourceware.org/mission.html#services and per project at https://sourceware.org/projects.html There doesn't need to be a transition (plan) if people are ok with staying with Sourceware. There is a roadmap and people dedicated to maintaining and expanding the services together with various hardware and services partners. https://sourceware.org/mission.html#organization https://sourceware.org/sourceware-25-roadmap.html And of course before creating any transition plan there is the question of the governance of this proposed new organization. Does it give the same guarantees of money being used for Software Freedom and community focus as the Sourceware/SFC setup? https://sourceware.org/mission.html#plc https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/ > Have we actually hit scaling issues? The only real thing we need to > scale up is our testing AFAIK - which we have builder.sourceware.org > for now and it's growing. > > I can see the advantage in dedicated devops and service isolation - > although I don't know if sw has given an opinion on whether they can > do service isolation. I am sure the Sourceware project can. As you say we have been scaling builder.sourceware.org very nicely so it is doing 15.000+ builds a month across 28 bare metal, VMs and container workers. And we have multiple hardware and service partners now. https://sourceware.org/mission.html#sponsors Next to the two servers Red Hat provides we also have three from OSUOSL. So some of the new services are already running on separate machines in different datacenters. Other services have been setup so they can be easily migrated to VMs or separate servers. We also have good working relationships with the FSF tech-team, which already runs various services for the GNU projects, and the OSUOSL, which we have asked to run services, like the mattermost server, where they have more expertise. Both have paid staff to look after servers and services. We have monthly Open Office hours to learn from the community about any (scaling) issues and then the Sourceware Project Leadership Committee meets to discuss any issues, set priorities and decide how to spend any funds and/or negotiate with hardware and service partners to resolve them together with the Software Freedom Conservancy staff. Cheers, Mark ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-31 19:59 ` Paul Eggert 2023-09-01 6:03 ` Sam James @ 2023-09-01 9:08 ` Mark Wielaard 2023-09-03 6:31 ` Alexandre Oliva 2023-09-27 13:49 ` Carlos O'Donell 3 siblings, 0 replies; 33+ messages in thread From: Mark Wielaard @ 2023-09-01 9:08 UTC (permalink / raw) To: Paul Eggert Cc: Joseph Myers, Alexandre Oliva, Jakub Jelinek, libc-alpha, Andreas Schwab, Maxim Kuvyrkov Hi Paul, On Thu, Aug 31, 2023 at 12:59:11PM -0700, Paul Eggert wrote: > On 2023-08-30 10:31, Joseph Myers wrote: > >I believe the LF has already agreed to implement the hosting entirely with > >free software. > > Where is this agreement written down? I didn't see it in the URLs > mentioned at the start of this thread. > > Too often it is tempting to use non-free software in these > enterprises, and we need to have an agreement and a commitment about > an enforcement mechanism that detects and repairs things if somebody > falls victim to this temptation (and of course that guides people > away from succumbing to the temptation in the first place). This > detection and enforcement mechanism has to be usable by glibc > software contributors and maintainers, not just by the CTI > providers. > > As I'm new to this (I just read yesterday that a decision is wanted > by today) I'll vote NAY until I see something more binding about > this important issue. What I understand from the earlier GTI proposal last year (which caused so much drama around the 2022 Cauldron [1]) nothing about this was written down. The idea was to set up a directed fund operated by the Linux Foundation. Paying members of the Linux Foundation would then be able to put money into this fund in exchange for board seats. The community would get an advisory role on how to spend these funds. One proposal was to use some of these funds to have the Linux Foundation IT team provide shared services which they already provide for the linux kernel project. The LF IT team was asked to only use Free Software to provide those services. And that if Free Software versions of necessary tools are missing, to work with Free Software supporters to develop Free Software alternatives. But no agreement about using Free Software was made when funds are spend any other way. I cannot tell whether this new CTI proposal has fixed these flaws because I was not involved. But I can tell you what we did for Sourceware to address these issues and what has been written down. Sourceware is a Software Freedom Conservancy member project [2]. The SFC accepts earmarked donations for Sourceware from anybody, individuals, corporations or grant organizations. The SFC does receive a handling fee for providing the Fiscal Sponsorship services [3] and so the project avoids non-profit administrivia. This money will be spend according to the mission of the SFC to support community-driven free software. Sourceware community is represented by the Sourceware Project Leadership Committee [4]. The Sourceware PLC makes all financial decisions. The PLC includes (old) overseers, hosted project representatives, steering committee and GNU maintainers. The current members are Elena Zannoni, Ian Lance Taylor, Ian Kelling, Frank Ch. Eigler, Christopher Faylor, Jon Turney, Tom Tromey and me. The Fiscal Sponsorship Agreement [5] between the SFC and Sourceware states that for projects Sourceware hosts everything will be distributed solely as Free Software and that we will publish all services as free software. We follow a conflict of interest policy [6]. Cheers, Mark [1] https://lwn.net/Articles/908638/ [2] https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/ [3] https://sfconservancy.org/projects/services/ [4] https://sourceware.org/mission.html#plc [5] https://sourceware.org/Conservancy-Sourceware-FSA.pdf [6] https://sfconservancy.org/projects/policies/conflict-of-interest-policy.html ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-31 19:59 ` Paul Eggert 2023-09-01 6:03 ` Sam James 2023-09-01 9:08 ` Mark Wielaard @ 2023-09-03 6:31 ` Alexandre Oliva 2023-09-27 13:49 ` Carlos O'Donell 3 siblings, 0 replies; 33+ messages in thread From: Alexandre Oliva @ 2023-09-03 6:31 UTC (permalink / raw) To: Paul Eggert Cc: Joseph Myers, Carlos O'Donell, Ryan S. Arnold, Maxim Kuvyrkov, Jakub Jelinek, Andreas Schwab, libc-alpha On Aug 31, 2023, Paul Eggert <eggert@cs.ucla.edu> wrote: > On 2023-08-30 10:31, Joseph Myers wrote: >> I believe the LF has already agreed to implement the hosting entirely with >> free software. > Where is this agreement written down? To the best of my knowledge, it just isn't. It's the sort of commitment that's not worth the paper it's written on. Besides, LF is not really about Free Software, and never has been. They might as well prefer to refer to it with such weasel words as Open Source Software, that when it comes to the software mean pretty much the same, but that shift the focus and motivations away from the freedom that software users deserve. One of the consequences of this shift is that people who swallow their terms are more prone to make mistakes and forget that when doing your computing through third-party services, the software that the third-party uses, if free, respects the service *provider*'s freedom, not the service *users*' freedom, and the users end up even more helpless than in the case of proprietary software. That's how SaaSS providers have managed to fool some Free Software-caring people time and again, making them believe that it's enough for the software to respect someone else's freedom. Multiple businesses have engaged in lock in through SaaSS, and we need to make sure we avoid such traps. And then, even if there was a written agreement, the other relevant question is who'd enforce it. Just like a strong copyleft without enforcement is little different from de-facto optional compliance, LF's making an alleged commitment to a group without any leverage or means for enforcement is little different from the group's having begging rights. That's not a position I want us to be in. It's not like the LF has a long history of respecting or caring for software freedom that could make their unwritten allegation more trustworthy. The kernel Linux, that they're named after, contains binary blobs, after all. Their board is packed with companies who have long disregarded provisions of the GNU GPL, even when it comes to Linux. If the LF were at a bank trying to borrow some money, these factors would demand the bank to require *more* assurance from the borrower, not less, than from a random borrower without such a history of not living up to commitments to others. We should be no less careful than this hypothetical bank in protecting our collective assets, particularly our freedom. -- 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. Think Assange & Stallman. The empires strike back ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-31 19:59 ` Paul Eggert ` (2 preceding siblings ...) 2023-09-03 6:31 ` Alexandre Oliva @ 2023-09-27 13:49 ` Carlos O'Donell 2023-10-04 0:09 ` Paul Eggert 3 siblings, 1 reply; 33+ messages in thread From: Carlos O'Donell @ 2023-09-27 13:49 UTC (permalink / raw) To: Paul Eggert, Joseph Myers, Alexandre Oliva Cc: Ryan S. Arnold, Maxim Kuvyrkov, Jakub Jelinek, Andreas Schwab, libc-alpha On 8/31/23 15:59, Paul Eggert wrote: > On 2023-08-30 10:31, Joseph Myers wrote: >> I believe the LF has already agreed to implement the hosting >> entirely with free software. > > Where is this agreement written down? I didn't see it in the URLs > mentioned at the start of this thread. CTI is the project providing the services. CTI asks the provider, LF IT, to adhere to our requirements which include the use of only FOSS in the deployment of the services. I will work with the CTI TAC and LF IT to setup documents that detail the requests and what will be provided and I'll publish those publicly. We have also had requests for ensuring that we have a proper strategy for changing providers. I will document those also. Some services are quite hard in reality like Bugzilla or Patchwork which have databases that need duplication. > Too often it is tempting to use non-free software in these > enterprises, and we need to have an agreement and a commitment about > an enforcement mechanism that detects and repairs things if somebody > falls victim to this temptation (and of course that guides people > away from succumbing to the temptation in the first place). This > detection and enforcement mechanism has to be usable by glibc > software contributors and maintainers, not just by the CTI > providers. Thanks for that input. -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-27 13:49 ` Carlos O'Donell @ 2023-10-04 0:09 ` Paul Eggert 0 siblings, 0 replies; 33+ messages in thread From: Paul Eggert @ 2023-10-04 0:09 UTC (permalink / raw) To: Carlos O'Donell, Joseph Myers, Alexandre Oliva Cc: Ryan S. Arnold, Maxim Kuvyrkov, Jakub Jelinek, Andreas Schwab, libc-alpha On 9/27/23 06:49, Carlos O'Donell wrote: > CTI is the project providing the services. CTI asks the provider, LF IT, to adhere > to our requirements which include the use of only FOSS in the deployment of the > services. > > I will work with the CTI TAC and LF IT to setup documents that detail the requests > and what will be provided and I'll publish those publicly. > > We have also had requests for ensuring that we have a proper strategy for changing > providers. I will document those also. Some services are quite hard in reality > like Bugzilla or Patchwork which have databases that need duplication. Thanks, this is exactly the sort of thing I was looking for. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-30 17:31 ` Joseph Myers 2023-08-31 19:59 ` Paul Eggert @ 2023-09-01 15:09 ` Alexandre Oliva 2023-09-27 13:50 ` Carlos O'Donell 2 siblings, 0 replies; 33+ messages in thread From: Alexandre Oliva @ 2023-09-01 15:09 UTC (permalink / raw) To: Joseph Myers Cc: Carlos O'Donell, Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov, Jakub Jelinek, Andreas Schwab, libc-alpha On Aug 30, 2023, Joseph Myers <joseph@codesourcery.com> wrote: > On Wed, 30 Aug 2023, Alexandre Oliva wrote: >> Even then, this would IMHO be a move for GNU to decide, or at the very >> least be consulted on, according to its own values and priorities, >> something that all mantainers appointed by GNU, myself included, >> committed ourselves to observe, prioritize and uphold as maintainers of >> GNU packages. I encourage other maintainers to justify their responses >> based on GNU's values and priorities, as they understand them. > I believe the LF has already agreed to implement the hosting entirely with > free software. Meeting basic requirements that, if not met, would make the service provider profoundly hostile to software freedom is a far cry from being in line with the movement's values. Are you familiar with the notion of SaaSS, Service as a Software Substitute? "LF has agreed to such and such" doesn't sound good for me. "We the community have decided to implement our own services so and so" would have made a lot of difference in avoiding the ills of SaaSS, but that doesn't seem to even be in the radar of the path that is being proposed. Now, this doesn't pertain to activities of publishing source code; publishing is not SaaSS. Remote merging, building, testing, and other activities that are being bundled with source code publishing services, however, are computing, community computing, and communities of such key projects ought to not only be careful to avoid enabling third parties to subjugate us through SaaSS, but also show other communities how to go about avoiding that. -- 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. Think Assange & Stallman. The empires strike back ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-30 17:31 ` Joseph Myers 2023-08-31 19:59 ` Paul Eggert 2023-09-01 15:09 ` Alexandre Oliva @ 2023-09-27 13:50 ` Carlos O'Donell 2024-02-13 0:43 ` Carlos O'Donell 2 siblings, 1 reply; 33+ messages in thread From: Carlos O'Donell @ 2023-09-27 13:50 UTC (permalink / raw) To: Joseph Myers, Alexandre Oliva Cc: Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov, Jakub Jelinek, Andreas Schwab, libc-alpha On 8/30/23 13:31, Joseph Myers wrote: > On Wed, 30 Aug 2023, Alexandre Oliva wrote: > >> Even then, this would IMHO be a move for GNU to decide, or at the very >> least be consulted on, according to its own values and priorities, >> something that all mantainers appointed by GNU, myself included, >> committed ourselves to observe, prioritize and uphold as maintainers of >> GNU packages. I encourage other maintainers to justify their responses >> based on GNU's values and priorities, as they understand them. > > I believe the LF has already agreed to implement the hosting entirely with > free software. Naturally we should make sure that other requirements from > https://www.gnu.org/software/repo-criteria.en.html such as "Does not > discriminate against classes of users, or against any country. (C2)" and > "Permits access via Tor (we consider this an important site function). > (C3)" are met, though I don't expect problems there. Several criteria are > trivally met or inapplicable simply because they concern things that are > beyond the scope of this proposed hosting (for example, recommending > particular choices of license, or offering choices of license, is entirely > outside the scope of what these hosting facilities do, just as it's > outside the scope of what Sourceware does - those are criteria for > general-purpose hosting sites that anyone might add a package to). The LF IT has agreed to implement hosting entirely with FOSS. I agree completely with Joseph here that the repo criteria [1] are the relevant criteria to apply in this case. I'll reach out to LF IT to work through the repo criteria. Likewise I will create documents to answer and cover some of Paul Eggert's questions. -- Cheers, Carlos. [1] https://www.gnu.org/software/repo-criteria.en.html ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-09-27 13:50 ` Carlos O'Donell @ 2024-02-13 0:43 ` Carlos O'Donell 2024-02-19 21:22 ` Alexandre Oliva 0 siblings, 1 reply; 33+ messages in thread From: Carlos O'Donell @ 2024-02-13 0:43 UTC (permalink / raw) To: Alexandre Oliva Cc: Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov, Jakub Jelinek, Andreas Schwab, libc-alpha, Joseph Myers On 9/27/23 09:50, Carlos O'Donell wrote: > I agree completely with Joseph here that the repo criteria [1] are the relevant > criteria to apply in this case. We believe that we are satisfying all of the requirements that the FSF and the GNU Project are requiring. Do you wish to raise any other FSF or GNU Project requirements? > I'll reach out to LF IT to work through the repo criteria. The CTI TAC did an initial review with LF IT and our expectation is that CTI services will meet B for "Good enough to recommend" if not better. -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2024-02-13 0:43 ` Carlos O'Donell @ 2024-02-19 21:22 ` Alexandre Oliva 2024-02-19 22:03 ` DJ Delorie 0 siblings, 1 reply; 33+ messages in thread From: Alexandre Oliva @ 2024-02-19 21:22 UTC (permalink / raw) To: Carlos O'Donell Cc: Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov, Jakub Jelinek, Andreas Schwab, libc-alpha, Joseph Myers On Feb 12, 2024, "Carlos O'Donell" <carlos@redhat.com> wrote: > On 9/27/23 09:50, Carlos O'Donell wrote: >> I agree completely with Joseph here that the repo criteria [1] are the relevant >> criteria to apply in this case. > We believe that we are satisfying all of the requirements that the FSF > and the GNU Project are requiring. Do you wish to raise any other FSF > or GNU Project requirements? I don't speak for the FSF or for GNU, and I'm not a party to any of the agreements you may have made with them, but I'd be surprised if the requirements were indeed satisfied. Outsourcing an individual's or a group's computing is SaaSS even when using Free Software, and SaaSS triggers basically the same obstacles to users' freedom that nonfree software does, but in a way that makes users even more helpless, so our movement rules out both SaaSS and nonfree software. From what I know of the FSF and of the GNU project, they surely wouldn't be on board with that sort of outsourcing, and AFAICT that sort of outsourcing is precisely what's being proposed, so I recommend you check back with them. When you do, I suspect you'll find that your belief arises out of some sort of misunderstanding as to the requirements. -- 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. Think Assange & Stallman. The empires strike back ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2024-02-19 21:22 ` Alexandre Oliva @ 2024-02-19 22:03 ` DJ Delorie 2024-02-20 1:49 ` Mark Wielaard 2024-02-20 3:01 ` Alexandre Oliva 0 siblings, 2 replies; 33+ messages in thread From: DJ Delorie @ 2024-02-19 22:03 UTC (permalink / raw) To: Alexandre Oliva; +Cc: libc-alpha Alexandre Oliva <oliva@gnu.org> writes: > Outsourcing an individual's or a group's computing is SaaSS even when > using Free Software, You just argued that we should all stop using sourceware.org or gnu.org. I respect the SaaSS argument, but we have to draw the line somewhere or we can't work together at all. Trust has to be a factor. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2024-02-19 22:03 ` DJ Delorie @ 2024-02-20 1:49 ` Mark Wielaard 2024-02-20 3:01 ` Alexandre Oliva 1 sibling, 0 replies; 33+ messages in thread From: Mark Wielaard @ 2024-02-20 1:49 UTC (permalink / raw) To: DJ Delorie; +Cc: Alexandre Oliva, libc-alpha Hi, On Mon, Feb 19, 2024 at 05:03:31PM -0500, DJ Delorie wrote: > Alexandre Oliva <oliva@gnu.org> writes: > > Outsourcing an individual's or a group's computing is SaaSS even when > > using Free Software, > > You just argued that we should all stop using sourceware.org or gnu.org. > > I respect the SaaSS argument, but we have to draw the line somewhere or > we can't work together at all. Trust has to be a factor. I do hope the glibc community trusts Sourceware. The Sourceware Project Leadership Committee does have regular discussions with the FSF and coordinates with the FSF tech-team around shared services we provide to GNU projects like glibc. Also we made sure that in our agreement with our fiscal sponsor, the Software Freedom Conservancy, we put in writing that any infrastructure software used is and will be published as Free Software. See the Fiscal Sponsorship Agreement at https://sourceware.org/mission.html#plc If the glibc community has any concerns about the Sourceware infrastructure and services, or simply would like to improve them, then please do reach out: https://sourceware.org/mission.html#organization The Sourceware Project Leadership Committee also meets once a month to discuss all community input, set priorities and decide how to spend funds, etc. Cheers, Mark ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2024-02-19 22:03 ` DJ Delorie 2024-02-20 1:49 ` Mark Wielaard @ 2024-02-20 3:01 ` Alexandre Oliva 1 sibling, 0 replies; 33+ messages in thread From: Alexandre Oliva @ 2024-02-20 3:01 UTC (permalink / raw) To: DJ Delorie; +Cc: libc-alpha On Feb 19, 2024, DJ Delorie <dj@redhat.com> wrote: > Alexandre Oliva <oliva@gnu.org> writes: >> Outsourcing an individual's or a group's computing is SaaSS even when >> using Free Software, > You just argued that we should all stop using sourceware.org or gnu.org. Your response just confirms that there's some misunderstanding around the notion of SaaSS. You may be confusing it with SaSS. The services that gnu.org and sourceware.org offer are publishing and communication, that are not any one party's computing, and that necessarily involve more than one party. These are not SaaSS. See "Distinguishing SaaSS from Other Network Services" on https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html You may also get a better understanding by reading "When the User Is a Collective Activity Or an Organization" on the same web page. It applies to our case. > I respect the SaaSS argument, but we have to draw the line somewhere or > we can't work together at all. Trust has to be a factor. The line is drawn, it just needs to be understood and respected. It has enabled us to work together for a long time. Currently, we're not outsourcing our computing, so there's no loss of software freedom, regardless of whom we trust. Trust may play a role when it comes to communication and publishing services, and we have a reasonably trusted party we've all relied on for a long time. There's a push to move them to a third party that is not uniformly better trusted, which is a problem in itself. But the anathema IMHO is that the plans AFAICT involve outsourcing our computing. That would be crossing a line that nobody should cross, and we, the Free Software movement, as the reference in this issue, must be the change we wish to see in the world, not seek ways to compromise. -- 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. Think Assange & Stallman. The empires strike back ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-30 17:19 ` [Action Required] glibc decision to use CTI services Alexandre Oliva 2023-08-30 17:31 ` Joseph Myers @ 2023-08-31 8:37 ` Mark Wielaard 2023-09-01 15:08 ` Alexandre Oliva 2023-08-31 10:34 ` Florian Weimer 2 siblings, 1 reply; 33+ messages in thread From: Mark Wielaard @ 2023-08-31 8:37 UTC (permalink / raw) To: Alexandre Oliva Cc: Jakub Jelinek, libc-alpha, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov Hi Alex, On Wed, Aug 30, 2023 at 02:19:20PM -0300, Alexandre Oliva via Libc-alpha wrote: > [adding libc-alpha, where GNU libc discussions are held] Thanks. I am just a small contributor to glibc, but I do help out with some of the infrastructure we use. So I am happy we are having this discussion with all contributors. I can only answer your concerns for the Sourceware project. I wasn't included in this Linux Foundation CTI proposal. > On Aug 29, 2023, "Carlos O'Donell" <carlos@redhat.com> wrote: > > I propose the glibc project migrate to services provided by the > > Core Toolchain Infrastructure (CTI) project, particularly services > > provided by the Linux Foundation IT team. > > Nay. I do not perceive any benefits to GNU's values in becoming > technologically dependent on an organization that never shared GNU's > values, that has constantly pretended GNU didn't exist, persistently > claimed our work to itself, and promotes and operates under values that > conflict deeply with those that GNU stands for. It would amount to > shooting itself in the paws. > > I acknowledge that the present supplier of equivalent services also > started in a hostile manner, but at this point it's the devil we know. I assume you are referring to when egcs/sourceware were started. I wasn't around then. But I note that these days we have a good working relation with the FSF tech-team, Ian Kelling is one of the Sourceware PLC members, and we talked through our plans to setup a non-profit home for Sourceware as SFC member project with the FSF director, Zoë Kooyman. > The plan should IMHO be to mitigate that dependency, not introduce > another or replace one with a worse one. We also worked to diversify our hardware and services partners so we are less reliant on just corporate sponsors. See https://sourceware.org/sourceware-25-roadmap.html for the various efforts. > As I suggested back when this idea was first raised (and AFAICT there > have been no attempts to dispute that this would be a better path to > pursue), I'd be happy to accept this sort of contribution to GNU *iff* > the services were *actively* *replicated* among two or three separate > suppliers, so as to reduce the risk of dependency and of corrupting > pressure on us. I know this doesn't go far enough for you, but we have always provided rsync services to make it easy to replicate the data needed for various services. All the source code repositories are now actively mirrored at the Software Heritage projects and the active git repositories are also available at https://sr.ht/~sourceware/ With public-inbox all public mailinglists are also easy to replicate and access through various protocols. For the main servers we do have "hot backups". Currently at the same provider, but we are planning to have something similar at OSUOSL and/or the FSF. > Even then, this would IMHO be a move for GNU to decide, or at the very > least be consulted on, according to its own values and priorities, > something that all mantainers appointed by GNU, myself included, > committed ourselves to observe, prioritize and uphold as maintainers of > GNU packages. I encourage other maintainers to justify their responses > based on GNU's values and priorities, as they understand them. For Sourceware we have the Sourceware Project Leadership committee which includes various GNU Maintainers/Stewards. I hope the community trusts them to uphold the values and priorities. You can find the current members at https://sourceware.org/mission.html#plc which also lists the legal agreements and conflict of interest policy. Cheers, Mark ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-31 8:37 ` Mark Wielaard @ 2023-09-01 15:08 ` Alexandre Oliva 0 siblings, 0 replies; 33+ messages in thread From: Alexandre Oliva @ 2023-09-01 15:08 UTC (permalink / raw) To: Mark Wielaard Cc: Jakub Jelinek, libc-alpha, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov On Aug 31, 2023, Mark Wielaard <mark@klomp.org> wrote: >> I acknowledge that the present supplier of equivalent services also >> started in a hostile manner, but at this point it's the devil we know. > I assume you are referring to when egcs/sourceware were started. Exactly. > I note that these days we have a good working relation with the FSF > tech-team, Ian Kelling is one of the Sourceware PLC members, and we > talked through our plans to setup a non-profit home for Sourceware as > SFC member project with the FSF director, Zoë Kooyman. These are all desirable properties indeed, that are to the best of my knowledge not valued by the other proposal, which by itself makes the move less desirable than staying put. But I don't conflate FSF and GNU, those are separate entities, despite FSF's strong support for GNU, and I express my position here strictly in my capacity of appointed GNU co-maintainer. > We also worked to diversify our hardware and services partners so we > are less reliant on just corporate sponsors. I don't see that GNU has a position of rejecting corporate support per se, so that wouldn't be so much of an issue if it weren't for LF's long history of disfavor to and attempted displacement of GNU. These concerns are reinforced by its corporate supporters' misalignment with GNU's pursuit of software freedom for all users. Freedom and autonomy are not something we generally expect others to give us; they're something we need to constantly pursue and struggle for. Per my calculations, even if the proposed move were to bring us any technical advantages, it would still be a risky proposition, but my reading of the situation is that it's no more than an attempt of a hostile take-over, in which the main factor driving others' preference for the candidate supplier of hosting services over the present one is ideological distance from GNU, rather than alignment with it. I'd love to be proven wrong in this reading, but I don't expect that. There haven't been any arguments about what LF could offer through strictly FS that SW couldn't or wouldn't, and anyone who understands enough of FS, particularly that used for hosting services, should be able to tell why there haven't been any such arguments: anything that either can do with FS, so can the other. It's no more than an exercise of seeking excuses to push other agendas through. I'd much rather we were honest and debated those motivations instead. > I know this doesn't go far enough for you, but we have always provided > rsync services to make it easy to replicate the data needed for > various services. *nod*, that is desirable, but it would still be quite disruptive if any service provider were to pull any such plugs, or use the influence gained through these possibilities to advance detrimental agendas, even if only temporarily. Why take that risk? Why centralize control, especially in hostile hands, if there are means to retain our autonomy? Why follow practices designed to take control away from users if we can be leading examples of how to retain our autonomy without making room for subjugation through control over SaaSS, that is even worse than proprietary software even when implemented through Free Software? LF has clearly been, erhm, hesitant to grant the community access to the servers that host services for the community. That, to me, makes most services SaaSS, a practice that self-respecting communities shouldn't adopt. Being locked out of one's own servers is giving up control over the community's computing, and that's exactly the core value of the Free Software movement that is at risk here. > For Sourceware we have the Sourceware Project Leadership committee > which includes various GNU Maintainers/Stewards. I hope the community > trusts them to uphold the values and priorities. I'd like to, but I find it hard to find reason to be confident in that. The notion of outsourcing the hosting of community services seems to have become so prevalent and ingrained that most people don't appear to realize the extent to which it becomes SaaSS when the community ends up excluded from control over the hosting services, and how that loss of control over one's individual and collective computing is exactly what our movement has stood against since its inception. Sharing the hosting of such services between multiple entities external to a community does nothing to address this problem, even if it mitigates other concerns about potential disruptions. For the kind of services that amount to a community's computing, only by involving active members of the community in the hosting services for the community can we avoid making the community a victim of SaaSS. Enabling some chosen community members to beg for a third-party hosting service provider to do their bidding does not seem enough to me to avoid betraying the core value of our movement. -- 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. Think Assange & Stallman. The empires strike back ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-30 17:19 ` [Action Required] glibc decision to use CTI services Alexandre Oliva 2023-08-30 17:31 ` Joseph Myers 2023-08-31 8:37 ` Mark Wielaard @ 2023-08-31 10:34 ` Florian Weimer 2023-09-04 6:09 ` Alexandre Oliva 2 siblings, 1 reply; 33+ messages in thread From: Florian Weimer @ 2023-08-31 10:34 UTC (permalink / raw) To: Alexandre Oliva via Libc-alpha Cc: Carlos O'Donell, Alexandre Oliva, Jakub Jelinek, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov * Alexandre Oliva via Libc-alpha: > Even then, this would IMHO be a move for GNU to decide, or at the very > least be consulted on, according to its own values and priorities, > something that all mantainers appointed by GNU, myself included, > committed ourselves to observe, prioritize and uphold as maintainers of > GNU packages. I encourage other maintainers to justify their responses > based on GNU's values and priorities, as they understand them. I'm not sure why “GNU” should have a say in this (whatever this is, you do not quote enough context). How would that even work? I think we don't have consensus what GNU's current decision-making structure looks like. I'm also puzzled why this was sent to the glibc stewards. The main task of this group these days seems to be to forward submissions to the stewards to libc-alpha. That doesn't seem to be very useful. Thanks, Florian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Action Required] glibc decision to use CTI services. 2023-08-31 10:34 ` Florian Weimer @ 2023-09-04 6:09 ` Alexandre Oliva 0 siblings, 0 replies; 33+ messages in thread From: Alexandre Oliva @ 2023-09-04 6:09 UTC (permalink / raw) To: Florian Weimer Cc: Alexandre Oliva via Libc-alpha, Carlos O'Donell, Jakub Jelinek, Andreas Schwab, Joseph Myers, Maxim Kuvyrkov On Aug 31, 2023, Florian Weimer <fweimer@redhat.com> wrote: > I'm not sure why “GNU” should have a say in this GNU libc is part of the GNU Project. GNU libc appointed maintainers have formally accepted responsibilities to operate in line with the project in our capacity as GNU maintainers. We're being called to make a decision, as GNU maintainers, that pretty much alienates from GNU the package entrusted to us. Any legitimate decision-making powers we maintainers have over GNU libc, it was delegated to us by GNU, conditioned on our observance of these responsibilities. We're expected to make sure that contributions that are accepted advance the project's goals, and to ask for guidance when there's uncertainty. How could one possibly imagine that GNU should *not* have a say on it? > How would that even work? Ask some GNU-appointed maintainer you trust who hasn't gone rogue, they should be able to convey that answer to you in a way you wouldn't doubt as much as if it came from me. > I think we don't have consensus what GNU's current decision-making > structure looks like. I realize there are people who'd like the GNU leadership structure to be different from what it is, but that's at the peril of delegitimizing their own roles appointed through the existing structure. Anyhow, GNU mission and structure are not matters for consensus among whoever wishes to share their opinions: those who agree to volunteer to a cause don't get to redefine the cause, and making it so that they did would make the cause too vulnerable to dilution and occupation. Even majority votes among the general population are a poor choice for promoting social change: it captures where most of the population *is*, which is by definition the opposite of social *change*. GNU mission and structure are what they have been since long before any of us started contributing to it. They were designed to be reasonably robust against hostile takeover, power grabs and attempts to dilute GNU's goals or otherwise turn GNU into something else, while enabling GNU to accept contributions from people and organizations who don't share its values and goals. Historically, most contributors haven't shared our values or goals, and enabling them to reset our course would have been the surest way to get none of the social change we hope to achieve. Instead of striving for an overall average likely influenced by extraneous interests, we're better served by the strongest commitment to the cause, to the goals, to the values, and the deepest understanding of the challenges we face. That diversity of values, alignments, motivations and opinions among potentially-misaligned contributors also makes room for some tension when people and organizations attempt to project or even impose by force onto GNU their own extraneous stances, without regard for the decision-making structure, for why it is as it is, or for what we're up for, up against, or up to. These tensions are sometimes hard to navigate, but they strike an IMHO ideal balance between accepting contributions from anyone willing to contribute to the cause, and rejecting changes that would be detrimental to the cause. -- 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. Think Assange & Stallman. The empires strike back ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2024-02-20 3:01 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <b84ea4a5-651a-1a4c-06c8-e9ade4b7d702@redhat.com> 2023-08-30 17:19 ` [Action Required] glibc decision to use CTI services Alexandre Oliva 2023-08-30 17:31 ` Joseph Myers 2023-08-31 19:59 ` Paul Eggert 2023-09-01 6:03 ` Sam James 2023-09-01 8:55 ` Florian Weimer 2023-09-01 9:02 ` Sam James 2023-09-01 9:21 ` dmarc, dkim and From rewriting Mark Wielaard 2023-09-01 11:52 ` Florian Weimer 2023-09-01 9:03 ` [Action Required] glibc decision to use CTI services Andrew Pinski 2023-09-01 11:49 ` Florian Weimer 2023-09-01 13:32 ` Frank Ch. Eigler 2023-09-01 12:30 ` Siddhesh Poyarekar 2023-09-01 14:54 ` Paul Eggert 2023-09-01 16:08 ` Siddhesh Poyarekar 2023-09-01 15:01 ` Sam James 2023-09-01 16:19 ` Frank Ch. Eigler 2023-09-01 16:30 ` Siddhesh Poyarekar 2023-09-02 18:25 ` Mark Wielaard 2023-09-01 9:08 ` Mark Wielaard 2023-09-03 6:31 ` Alexandre Oliva 2023-09-27 13:49 ` Carlos O'Donell 2023-10-04 0:09 ` Paul Eggert 2023-09-01 15:09 ` Alexandre Oliva 2023-09-27 13:50 ` Carlos O'Donell 2024-02-13 0:43 ` Carlos O'Donell 2024-02-19 21:22 ` Alexandre Oliva 2024-02-19 22:03 ` DJ Delorie 2024-02-20 1:49 ` Mark Wielaard 2024-02-20 3:01 ` Alexandre Oliva 2023-08-31 8:37 ` Mark Wielaard 2023-09-01 15:08 ` Alexandre Oliva 2023-08-31 10:34 ` Florian Weimer 2023-09-04 6:09 ` Alexandre Oliva
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).