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

[Gabriel Ravier]

On 2/9/26 7:30 PM, Alexandre Oliva wrote:
> On Feb  9, 2026, "Frank Ch. Eigler"<fche@elastic.org> wrote:
>
>> Hi -
>>> [...]  Whereas if the community computing takes place under control
>>> of the community, so that its autonomy is not curtailed by the
>>> person who carries out the computing on our behalf, then it is not
>>> SaaSS. [...]
>> I am skeptical that a concept such as "community computing" is
>> coherent, especially when it is applied to someone running testsuites
>> and reporting results.  Putting such activities under "control of the
>> community" appears a literal violation of FSD Freedom #0.  Let's stay
>> on topic.
> Yeah, let's.  There's clearly some mental model mismatch here.  I can't
> quite make sense of what you're trying to get at, there seems to be a
> deep disconnect.  Can we please dig deeper so as to increase our common,
> shared understanding, instead of leaving it alone, pretending it's not
> there and reinforcing the miscommunication?
>
>
> When I speak of "community computing" in the context of running
> testsuites and reporting results, I'm speaking of those testsuite runs
> and reported results that are made by decision of the community
> governance.
>
> I am *not* speaking of third party test runs done independently.
>
> I'm *not* speaking of test runs done independently even by community
> members.
>
> Anyone is still free to run the tests however they wish: it is their own
> computing, after all, so they should be sovereign and autonomous WRT to
> them.
>
>
> What I'm speaking of is the runs done on behalf of our collective
> organization, GNU libc, in response to collective decision taken by its
> governance structure.
>
> We shouldn't run those as SaaSS, but that's not because our freedom is
> curtailed (the supposed freedom #0 violation you mentioned), but rather
> to stop it from being curtailed.  We should refrain from entering SaaSS
> arrangements not because someone prohibits us from doing so, but because
> it is foolish and self-defeating to give up our freedom.  That should be
> avoided out of our own volition, out of our alignment with free software
> values and principles, and out of our alignment with the GNU Project's
> goals and example-setting.
>

I think the issue here is more that there appears to be a disconnect as 
to what exactly is SaaSS (or at least an "acceptable" thing for the 
glibc project to do) in the context of stuff like running tests 
automatically. Let's say that today, there is one s390x machine running 
tests (or arc, csky, or1k, sh or some other esoteric architecture - the 
specifics aren't super important), and that the project "relies" on this 
to make sure random commits don't break on s390x. Would this be SaaSS ? 
Would whether such is SaaSS rely on the precise manner in which the 
tests are used ? e.g.:
- Is it SaaSS if we consider that the machine is required for s390x 
support, and if it is retracted with no replacement, s390x support will 
be officially dropped ?
- Is it SaaSS if we consider that the machine is a non-required courtesy 
- if it is available, we make sure as often as possible to not break 
s390x, but if it isn't/is retracted in the future, we simply decide that 
some other interested s390x user can provide their machine if they want 
better support/to make sure random commits don't break s390x, and if no 
one provides one just support s390x somewhat less well ?
- Is it SaaSS if the machine is of a more common architecture that we 
could "test ourselves" ? How common would it have to be ? Does e.g. any 
architecture with QEMU support qualify ? (even if running the tests 
would take much longer there, almost impractically so)
- Is it SaaSS depending on *who asked* the machines to run the tests 
(e.g. because the glibc project kindly asked the owner of the machine to 
do so, or because the owner of the machine simply decided to do so), and 
if so, does it matter at all how the tests are used after someone 
"independently" (or not) ran the tests ?

Note that in none of these cases we would have direct control over the 
machine - at least insofar as the machine could be legally retracted at 
any time should the owner of the machine not like whatever specific 
things we're doing on it/need it for something else/any reason they want.

Reading the SaaSS definition RMS gives seems to imply the answer is 
"yes" to almost all my questions (except perhaps the last one) but it 
gets pretty impractical in many cases - do you consider dropping Itanium 
because testing it is basically impossible without some form of SaaSS to 
be the correct choice because, technically, we could go spend a bunch of 
money on Itanium blades for and spend weeks getting them working, or 
develop an Itanium implementation for QEMU and run it on that, and that 
the choice should be either doing that or dropping Itanium, because 
anything else would be SaaSS ?


PS: As to my last question, it seems like an oddly simple structural 
run-around-the-rules to say that the tests are being "run independently" 
if glibc developers regularly consult the tests and use them to improve 
the project (regardless of how "officially" this is integrated into the 
workflow). For instance, a simple example would be to replace "the 
project relying on the particular machine" with "the project simply 
waiting on someone to independently decide to run the tests and posting 
the results publicly somewhere" (which would likely end up with a single 
practical provider for most architecture in practice, even if 
bureaucratically mildly different) within the context of the first two 
questions - would this be SaaSS in either the "required for architecture 
support" or the "courtesy" scenarios ? I would like to note this already 
effectively exists for the courtesy scenario on pretty much any project, 
insofar as that's effectively just the equivalent of someone deciding to 
run the tests on a particular architecture and posting the results to 
the mailing list in response to someone posting a patch - which doesn't 
seem particularly different in practice to having those machines run the 
tests because the glibc project asked them to do so, given the final 
practical usage of them is the same if it's not e.g. required for 
architecture support.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260210/d670cf87/attachment-0001.htm>