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

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

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