Meeting Minutes - Office Hours for CTI - 2026-08-28

[Siddhesh Poyarekar]

On 2026-09-10 19:33, Zack Weinberg wrote:
> I don't accept a *list of names* of people who have expressed non-
> specific "support" via backchannels.  If each of the people on the list
> were to post to the thread, perhaps relayed as above, explaining
> concretely why they think your proposal is the best available option for
> the project (as indeed several have), that would have at least *some*
> weight with me.

They're not a list of names, they were a list of people who explicitly 
voiced their support on the list.  There were more who posted after I 
wrote that message.

>> I apologize, I've been saying consensus where I've meant a significant
>> majority with only a couple of sustained objections.  I don't think
>> consensus can be achieved in this case
> 
> Unfortunately, it's consensus or nothing.  The project's established
> decision-making procedures (or more accurately lack thereof) do not
> allow for majority rule on a decision of this magnitude.

I don't think so.  It has happened before (the abort joke fiasco for 
example) where there was no consensus but a decision was made in one 
firm direction based on a majority.

>> because the sustained objections are based on conditions that
>> cannot be met,
> 
> I'm not so pessimistic.

I've been part of these conversations since 2022 and we've had to 
restart conversations every single time, reiterating our justifications 
and adjusting to new realities (sourceware overseers backing out, SFC 
coming into the picture to help form a PLC, re-envisioning the project 
as a critical services one, continuing to use sourceware infrastructure 
for non-critical services, etc.) at every given point.  The status has 
been the same because the blocking points are essentially 
ideological/personal biases.

Besides, I think we have a fundamental disagreement on the state of the 
decision; I think we have gathered enough agreement to proceed with the 
move, as we've been doing steadily for the past months.  There is scope 
for improvement because obviously this won't be the last time we'll have 
to make contentious decisions, so maybe there's scope to have a 
discussion within the glibc community on a decision framework when 
there's no consensus.

>> or objections over SaaSS, antagonistic feelings for the LF
> 
> These could both, I think, be addressed by an incremental process
> beginning with non-essential services, allowing people time to develop
> confidence that LF wasn't going to pull out the rug from under them.

That's useless on multiple fronts.  It's harder to raise money for and 
even if it works, it won't change ideological biases.  Not to mention 
that it solves 5% of the problem, keeping the core issue of critical 
service scaling behind.

>> or the perception that there's no need to scale infrastructure or have
>> professional, full time infrastructure administration.
> 
> And these could be addressed with the data I've been asking for.

I don't think that request is going to go anywhere because again, such 
data doesn't really exist and there's entrenched perceptions about how 
useful full time professional IT support is.

>> I don't understand the argument you're making here, why shouldn't they
>> simply fund upstream infrastructure when they have an easy opportunity
>> to do so instead of standing up their own mirrors?
> 
> Because enlarging upstream infrastructure so they can continue to pound
> on it is an *inferior long-term technical solution* to reducing the
> pounding, and the standard technique for reducing pounding on shared
> read-mostly, data-changes-slowly services is local caching.

The "inferior" solution is separation of read and write repos with 
geo-local caches.  It's far more scalable than you're imagining.

>> Most companies find it easier to support upstream projects through
>> consortiums like LF or Linaro because it's streamlined for them.
> 
> Sure, LF as fiscal middleman streamlines things.  But what's stopping
> LF from writing checks to fund full-time sysadmins and additional hardware
> for sourceware?  Why is "money pipelined through LF" a package deal with
> "services provided by LF"?  This is the second-biggest reservation I
> personally have about your plan as it is now (first-biggest is moving
> things in the wrong order) so I'd like as much detail as you can here.

Our request was to have funding for sourceware hardware and professional 
IT support, which is what they came up with.  We had to walk that back 
to hardware and professional IT support for critical services given that 
sourceware overseers refused to come on board.  The "lets pay the 
sourceware overseers to build out hardware and hire full time sysadmins" 
never came up in our negotiations with LF because we don't see that as a 
viable option for critical services given how sourceware infrastructure 
is run.

>> This is precisely why we're focused on making our setup fork-liftable.
> 
> Ok, so is there documentation of what has been done to that end?
> (I don't insist on that being posted to the mailing list, links would
> be fine.)  And is there a plan to implement those changes on the
> sourceware side *before* any move, so that the forklifting procedure
> is tested by the move itself, and thus known to work before we need it
> in a hurry?
The separation of services, distinct URLs (the transition plan wiki 
page[1] has this) are part of this.  I'll raise the question of testing 
this, that's a good idea.

Thanks,
Sid

[1] https://sourceware.org/glibc/wiki/service-transition-plan