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

[Siddhesh Poyarekar]

On 2026-09-04 13:02, Andrew Pinski wrote:
>> My personal lack of trust is limited to the conversations we've been
>> having about CTI because over the years I feel like the conversation has
>> been unfairly manipulated to paint the community into a corner and
>> giving the impression that there's no choice.
> 
> Let's ask ourselves why it is painted that way? Instead of just saying
> it.  Everytime it comes up; there are 2 very volocal folks seemly to

These conversations are exhausting and most people would rather just 
quietly hack on code.  I too stop responding to these threads from time 
to time to preserve my mental health.

> push all or nothing. Never what can be done right now to solve issues
> of sourceware; never alternatives; just move and move to LF IT. And

These conversations have been around for nearly a decade now and the LF 
IT move is only the second half of the decade.

> then let's talk about the threat of physical violance that was once
> used. That alone was something which pushed folks away from the move;;
> it definitely did it for me.
> 
>> That is not the basis of
>> the move proposal at all, which predates this whole thing.  I've
>> mentioned in those threads the main motives I support for the move: 1) a
>> lack of scalable funding to the levels that will actually support
>> growing resource requirements of the GNU toolchain projects 2) lack of a
>> real growth plan for the sourceware overseers volunteer group.
> 
> I find this interesting here because you didn't think to help out on
> the growth plan either; or the level of funding. Or anything instead
> you right away decided it was not fixable.

At risk of repeating myself: this has been a sticking issue for a long 
time and we've been trying to get funding for the infrastructure for 
nearly a decade.  This is not something that came up in the last 5 
years.  We've had to build from a position where there was denial that 
there were any funding, maintenance or security issues to begin with, to 
a point now where we actually have a position where we (the glibc 
community) has better control over infrastructure through multiple 
vendors (LF IT, Sourceware/Red Hat).  Through the move we're also trying 
to ensure that deployments are nimble, i.e. in future we should be able 
to simply forklift services to another vendor if needed.  While we don't 
want to do this all the time, we also don't want to be in a position 
where we're held hostage by an infrastructure vendor.
>> My personal lack of trust in the individuals is also not broad, it is
>> specific to the conversations we've been having about CTI.  I routinely
>> work with Mark and Frank on a day to day basis on other things, in my
>> day job as well as on sourceware stuff.
>>
>> Finally, the proposal at the moment is limited to moving critical
>> infrastructure (git and email) to LF IT, not replace sourceware.  Since
>> some of the overseers decided to continue supporting sourceware (and we
>> came to terms with it) we realized that it's better to have the use of
>> both infrastructures.
> 
> Except that is replacing all of sourceware.

No it's not.  We've realized that there's no value in moving all of our 
eggs into one (LF IT) basket, only the ones where we want to be able to 
scale and have a dedicated IT team manage it.  For example, I don't see 
the point of ever moving buildbots (primary or workers) or bunsen over 
to LF IT.  The LF IT doesn't want to host a wiki, so that'll likely stay 
until the community decides that an alternate solution (e.g. git + 
sphinx) is better and further, decide that it's worth moving to LF IT.

Bugzilla is important infrastructure, but with git and email out into 
independent systems after the move, it's less of an infrastructure 
problem.  We do need to figure out what needs to be done with bugzilla 
overall since the project is not well maintained, but again, that's a 
glibc community question, not a CTI question.  Patchwork is non-critical 
but useful given how the glibc community works currently.  It's not a 
candidate for moving to LF IT though, I'd rather see us use the 
sourceware forge instead.

I hope this gives a better idea of what stays on sourceware and what 
moves in its current form; it's just git and email.  Everything else is 
an evolution decision, not just a question of moving services and it is 
out of CTI scope.

>>> people's personal lack of trust in the Linux Foundation.  (Speaking for
>>> myself alone, back in Jan 2026 I had no particular reason *not* to trust
>>> the LF and its funders, but today I very much *do not* trust them, on
>>> account of their embrace of the LLM bubble and its adjacent hard-right
>>> political advocacy groups.) You said at the bottom of that message
>>
>> I don't think any commercial organization is immune from the LLM
>> garbage.  I "trust" the Linux Foundation as much as I trust Red Hat (my
>> employer, although that hat is strictly off when I communicate upstream)
>> or even SFC or FSF, which is limited.  Over the years I've realized that
>> every commercial (including non-profit) organization is more than
>> willing to bend and manipulate public emotions and sometimes even facts
>> to their benefit.  I've been training myself to work through that
>> distrust to try and get what I think is the best result for the glibc
>> community.  I do trust individuals in the community more than
>> organizations (maybe because my involvement in the GNU toolchain is as
>> myself and not as a Red Hat employee), to the extent to which I can
>> trust their ability to act independently of the organization that they
>> work for.
> 
> There is also a trust issue of how a member of CTI used the threat of
> physical violence once.  And that person didn't fully step away from

Firstly, my understanding is that the CoC issue that came out of that 
was resolved between the parties involved.  I don't have the privilege 
to know the details, but bringing this up repeatedly in the context of 
CTI only shows your bias, since the individual is also a gcc steering 
committee member.

> CTI. Mending that trust here would have been step one, 3 or more years
> ago but nothing.  The other trust issue with CTI is how the proposals
> come up and then there is dissent and then nothing about the proposal
> is delayed or anything; just quiet until a new date is proposaled. So
> the dissenter think the proposal is gone and not to bring up again.
> 
> A recent example is the proposal to move in August. There was some
> dissent and then nothing until September. How can we trust this when
> this kind of communitation happening like this?  I made this an issue
> before and will still make this a bigger issue here again. I dissented
> based on the timeline not being doable and even asked for better
> dates.  But no communication there; instead there was an update to the
> wiki with some TODOs and then nothing.  THere was no communication to
> the list so nobody else knew was going on for the whole month of
> August.

We've been sending out weekly office hours emails regularly, and I 
appreciate you reading and responding to them.  There hasn't actually 
been any movement in August since we had to wait for the release window 
and then had cascading vacations, meaning that nothing could really be 
done.  The August target was unreasonable, I agree.

We're still hashing out the plan[1] and Carlos will edit the page and 
send out details from this week's office hours, which was the most 
significant progress we've made in the last couple of months.  For 
example we finally have the beginnings of an answer to your question re. 
the main hooks (email and bugzilla).  Carlos will send out meeting notes 
soon with the details.

> This is part of the trust issue here.
> 
> On a different subject, there has only been one dissent on moving to
> the forge for glibc and that has also a person who is very vocal on
> the move to using LT IT.  glibc has less than 50 commits a week.

I'm not sure which discussion or person you're referring to here.

> While glibc/binutils gets over 50 commits a week and GCC gets between
> 150 and 200 commits a week.  GCC has started to move some reviews and
> patches to the forge already. New folks are more likely to use the
> forge than email in patches.

Has there been a discussion on list about this?  I wouldn't object to 
people reviewing patches on the forge, as long as the patches and 
reviews are also mirrored to libc-alpha.

The only overlap I see with CTI is the location where the merge requests 
land.  That doesn't seem like an issue if the sourceware forge instance 
is able to write to a remote git repo.

> And yes this is based on actual data since I started the newsletter.
> 
> Oh and also bringing up email lists items; GCC mailing lists have
> allowed html emails while glibc just banned it recently based on the
> requests of overlapping folks of CTI and glibc community.  This has
> pushed away some folks in the past for GCC; this is why GCC allows it
> now.

??? this is the first time I'm hearing of this, do you have a reference? 
  In fact, I was under the impression that the gcc mailing list rejects 
html emails too, as I had found out when I had responded to an email 
from my phone (the phone gmail client is terrible and I've been too lazy 
to find and install a different one) some time back; my email never 
landed in the archive.

Sid

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