forge vs gitolite (Re: CTI - Making a decision for glibc.)
Alexandre Oliva
oliva@gnu.org
Tue Feb 3 03:18:34 GMT 2026
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.
> It is an operation which the user can easily fall back to doing on
> their own machine (i.e. running git merge/apply/am themselves), of
> which the user already has to transmit all the data involved to the
> server even if they do it themselves (that is, the information
> transmitted to the server when doing a merge locally and when doing it
> on the server directly is the same), and which is trivially verifiable
> by them (if the server did something else than what would have been
> done locally, this would be trivially detectable and pretty
> systematically so, too). I would have assumed SaaSS was the result of,
> at the very least, one of these things being false.
It's not. Even if multiple people set out to build the same program in
a reproducible way, or to perform any other reproducible computation
that (by definition) yields the same results, each party's computing
ought to be done under the party's own control.
Maybe it shouldn't be that way. I've been thinking lately, prompted by
this very thread and earlier iterations thereof, that it might make
sense to carve out an exception for such reproducible computations. I'm
glad you seem to have grasped the notion of SaaSS and come to similar
thoughts that I have: we're probably on the same track to a useful
conclusion.
The end result I imagine is to be able to carve out another exception to
distinguish SaaSS from SaaS. Just like publishing and mediation of
communications are not SaaSS because they're no single party's
computing, reproducible computations could also be reasonably argued to
be no single party's computing.
However, the line has to be drawn very carefully to avoid turning any
SaaS whatsoever into something you could do on your computer, but you do
under someone else's control and it's the same because you could have
done it on your computer. There must be more than that for the
distinction and the exception to be useful, to avoid enabling a truck to
go through.
In my developing thoughts, publicity of the process [to the target
community] may be a requirement, so that anyone else [in the community],
or at least many third parties, could have all the data and the software
required to verify the results.
Perhaps some amount of statistical or competitive verification should
also be a requirement for it not to turn into blind trust, which would
IMHO make it SaaSS.
In order to make a useful and solid distinction, we also have to look at
the flip side, and have examples of computing that should *not* fit in
this exception, even if they could conceivably be reproduced on the
user's end. This would help identify where to draw the line without
going too far either way.
Thanks for your collaboration,
--
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/
More information about the Libc-alpha
mailing list