Re: [Action Required] glibc decision to use CTI services.

[Mark Wielaard <mark@klomp.org>]

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