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

[Andrew Pinski]

On Fri, Sep 4, 2026 at 11:21 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> 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.

This was not disclused or even discussed :). My point still stands
about community and the lack of 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.

This seems like you are misunderstanding my points about communition.

>
> >>> 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.

That might have resolved with the folks directly involved but not the
overall trust.  I even have trust issues with part of the way the CoC
issue was handled; I did raise it at one point and my concern was shot
down as a non one.   But as I mentioned below this about CTI here only
because we are discussion trust around CTI.

>  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.

Yes and I do think that is an issue with the steering committee too.
And NOT just with CTI but since this discussion has been around CTI I
didn't bring up the other orgs the person was involved with at this
point.

>
> > 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.

Again the problem is communication.  A quick email would have resolved
that.  BUT nothing.  Vacations are an excuse.  So is release cycle for
the lack of simple 1 or 2 line emails saying August is not dueable.
The lack of communication is a trust one.  And yes I read the office
hours emails but there was no update on that August was not being
done.

>
> 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.

Again there was a lack of communication that this was being done.
Instead I am left with thinking this was all dropped.  Just a simple
email saying we hashing out the final details on how long each of your
items would take would have been better than nothing.  Again lack of
communication of working through the TBDs; feels like things are
dropped.  This is why I am now even more opposed to this move; lack of
communication causes huge trust issues.

>
> > 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.

YES. The last time it was brought up moving in August. Oh it looks
like you missed that part of the discussion.

>
> 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.

First time; I asked about this when it happened.
https://inbox.sourceware.org/libc-alpha/CA+=Sn1mGhEjnDqvB2YJXzBouYJHqB6+s4hmF9a06fdXV-k1Fmg@mail.gmail.com/


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