forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  3, 2026, "Zack Weinberg" <zack@owlfolio.org> wrote:

> On Mon, Feb 2, 2026, at 10:18 PM, Alexandre Oliva wrote:
>> On Feb  1, 2026, Gabriel Ravier <gabravier@gmail.com> wrote:
>> 
>>> I don't get what the issue with patch merging is, exactly.
>> 
>> The issue is precisely that it's your computing, so you should do it
>> under your control.  If you do that under someone else's control,
>> that's the definition of SaaSS.
>> 
>> We can consider it the community's computing, at which point it should
>> run under the community's control.  If the Forge runs under the
>> community's control, that would be fine, it wouldn't be SaaSS.  But if
>> the Forge is controlled by a third party, then we have a freedom
>> problem, because it would be SaaSS.

> The thrust of the _rationale_ presented for avoiding SaaSS is that we're
> giving up control over what software is used on the service provider's
> machines and how it's configured,

Not quite.  Those are practical consequences of that, but the core of
the argument against SaaSS is the same ethical argument against nonfree
software: you deserve control over your computing.  If it's your
computing, and you don't have control over it, whoever has that control
holds unjust power over you through your computing.

So the two questions that need to be asked to tell whether there's an
ethical problem and an injustice are:

1. whose computing is it, and

2. who controls it

If it's not the same person, the same party, the same group, that's the
freedom problem that the free software movement set out to solve.


When we speak of a community's computing, the community should control
it.  So programs it installs and runs on computers it operates should be
free software, and services provided by third parties should not be
SaaSS.


When we talk about communities, boundaries and governance matters, and
nesting structures also matter.

Say, a glibc test run could be conceived as your own computing, or as
glibc community's computing, or as GNU computing, or even as Free
Software community's computing, or even FLOSS computing or humankind
computing.

Some of these probably don't make much sense, but I mention them for
completeness.

Which of these is the right answer depends largely on intent, and on
belonging IMHO.

If you're running the tests for yourself, then it's your computing, even
if you will share the results with others.  So you should have control
over it.

If you're running the tests on behalf of any of these communities, as in
at its request, or under an assignment, then that's the community that
should have control over it.

So this is not about our being part of a huge community with fuzzy
boundaries.  We can and should be strict about who controls our
computing, including our computing devices, just as we can and should be
strict about who governs our community.  If we were to think of
"community" too broadly, we'd end up submitting our community's
governance and control over computing to the UNO or somesuch, and that
probably wouldn't do us good WRT our autonomy.

Does that make sense?  I think community boundaries make as much sense
when it comes governance and autonomy as when it comes to computing
autonomy.  The latter is part of governance and autonomy, after all.


Now, let's look at the concrete examples you named.


Savannah is operated by GNU Project's representatives, for the GNU
Project.  Whatever runs there is presumaby GNU Project's computing.
That said, most of what that server actually does is publishing and
mediating communication, that aren't regarded as any specific party's
computing, because at least two parties might claim it to be their own
computing, but they likely wouldn't have a stronger claim than the other
parties.  So those features can even be used by third parties who don't
belong to the GNU Project, without that being SaaSS for them.

When you ssh into Savannah, you're presumably engaged in GNU Project's
computing.  So it's reasonable for the GNU Project to have control over
that computing.  So it's not objectionable, freedom wise, that they
choose (or can't help) to keep running an old version of ssh on their
end.  It's also unfortunate that this requires you to keep a weak key on
your computers.  But it is their prerogative to decide what to run on
their servers, under their control.  Just as it is your prerogative to
decide what to install on yours.  Depending on decisions from both
parties, you may or may not be able to interact.

> Also, consider the Compile Farm.  It is run by people who I don't know
> well, and who actively refused to update sshd on Farm machines, when I
> made the same request to them.  They are probably within the "community"
> if that is defined in a broad sense

We are certainly part of the same broad community they are, but I don't
think they've ever submitted full control or governance over their
machines to us, so at another level we are different communities, and
they're entitled to control their machines as they wish, and to hand us
as much control as they like.

If they offer our community enough control that we can have control over
our own computing if it runs there, we can then use those computing
resources for our community's own computing and purposes.

If, however, they only offer access and control to individuals, who also
happen to be members of our community, then instead of an institutional
relationship, we'd have multiple individual relationships.  This may be
enough for individuals to run their own computing there, or even for the
community to assign individuals to run community computing there, but
would that be our community doing its computing there?  I'm not sure, I
don't think this is a settled matter, but I'm inclined to think that
this kind of arrangement might make the individual a provider of SaaSS
to the community, because ISTM the community wouldn't have control over
the computing, only the individual would.


So, you see, the issue of SaaSS is not at all about where in the FLOSS
spectrum the operator is.  The issue, first and foremost, is whether it
is SaaSS at all.  And then, if it is SaaSS, we shouldn't use it, but if
someone insists on using it anyway, then choosing a misaligned provider
aggravates the SaaSS problem, because it's not only relinquishing
control over our computing, it's turning the control over to a
misaligned party.

-- 
Alexandre Oliva, happy hacker            https://blog.lx.oliva.nom.br/
Free Software Activist     FSFLA co-founder     GNU Toolchain Engineer
Learn the truth about Richard Stallman at https://stallmansupport.org/