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

[Siddhesh Poyarekar]

On 2026-09-26 15:27, Zack Weinberg wrote:
> On Fri, Sep 11, 2026, at 9:37 AM, Siddhesh Poyarekar wrote:
>> On 2026-09-10 19:33, Zack Weinberg wrote:
>>
>> 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'm going to have to ask you to provide message-ids or mailing list
> archive links to back that up.

OK, I'm not going to keep digging into the archives for you, please do 
that yourself now.  If it helps, go through committers in git and 
cross-reference them with emails to the list in that time period.

>> 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.
> 
> Whether to remove two sentences from the reference manual was not
> remotely as important a decision as whether to move the entire project's
> hosting infrastructure.  I do not think that incident can stand as
> precedent for majority-rule decision making on issues of substance.

I think it does, because it's not just about the two sentences, it's 
about an irreconcilable difference preventing consensus.

>> blocking points are essentially ideological/personal biases
> 
> I must remind you that I do not feel the urgency that you do.  You are
> coming from the position that glibc urgently needs new hosting, but as
> far as I can tell, on a technical level, everything would more or less
> be fine if glibc stayed on sourceware for the foreseeable future.

5+ years does not count as urgent.

> As such, I am *perfectly okay* with the decision process taking as long
> as it needs to take to come to a conclusion that everyone is satisfied
> with *even in the face of* ideological/personal biases.  In fact, I

The decision process is done and we're in the process of implementing 
the changes.  What's left is discussion on specifics, i.e. naming, 
schedule, etc. that we're working on as we get to them.

>> 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.
> 
> Indeed.  It is my position that you do *not* have enough agreement
> to proceed with migration of essential services.  You can change my
> mind about this; I have already said what it would take.

I don't think I have to change your mind about it.  I'm approaching the 
conclusion that we're going to have to live with this difference in 
perception.

> For the record, I do not, myself, object to the mere idea of having
> glibc be hosted on LF infrastructure.  My objections are only these:
> 
> 1. The current proposal does the migration in the wrong order.
>     If glibc moves anywhere, essential services ought to be moved *last*,
>     after an extensive shakedown period (at least a full calendar year)
>     with only non-essential services on the new infrastructure.

Considered and rejected, primarily because it has come in too late in 
the discussions and secondarily because it just doesn't make sense.

> 2. There is no legitimate basis for major decision making in glibc other
>     than consensus reached *exclusively* on libc-alpha.  The process so
>     far has not achieved such a consensus.

Considered and rejected, again because we have a different, potentially 
irreconcilable difference in perception about how decision making works 
in glibc.  You can have a separate discussion about this with the GNU 
maintainers if you're unhappy with how things have gone and try to 
influence a formal framework for future decisions.

>> maybe there's scope to have a discussion within the glibc community on
>> a decision framework when there's no consensus.
> 
> That would be a good thing to do in the long run, but any such decision
> framework could only be legitimately used for decisions that come up
> *after* the framework has been agreed upon.

Sorry, no, but you can talk about it for future decisions, including 
that of moving any future services to LF IT, if any.  I personally don't 
see a need to move anything more than git and email at least for the 
coming years.

>> 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.
> 
> Again, I do not feel any urgency here.  I acknowledge you believe there
> is a "critical service scaling issue" which needs to get fixed ASAP, at
> the expense of just about everything else, but *I do not agree with your
> priorities*. I believe it is *more important* to test out the migration
> procedures on non-essential services first, and in fact I would *still*
> believe that even if I did agree that the existing servers were overloaded!

See above, we've meandered for 5 years.  It's a miracle that the CTI 
budget proposal has actually lasted that long.

> And I also believe it is more important to let people get experience with
> LF hosting.  Maybe they still won't like the idea of moving the essential
> services, but maybe they'll come around.  You don't know, because we haven't
> tried it yet!

I can see that you genuinely believe that this is a middle ground of 
some sort, but it's based on a fundamental misunderstanding of how 
corporate funding prioritization works.

>> "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.
> 
> I think you are being far too pessimistic about the chances that
> sourceware infrastructure could change in a direction you like, especially
> if there were substantial funding on the table, and I would suggest
> that you go back to LF and ask for this now.  At least find out if they'd
> be open to the possibility.
I am not interested in influencing sourceware infrastructure of funding. 
  I am only interested in improving the infrastructure maintenance and 
scaling story for the GNU projects and I think the *best* solution here 
is to have the LF IT maintain git and email for the project.

Sid