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

[Siddhesh Poyarekar]

On 2026-09-04 14:42, Andrew Pinski wrote:
>> 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.

I mean I literally responded to you in January :)

https://sourceware.org/pipermail/libc-alpha/2026-January/174462.html

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

This wasn't a problem the larger community even cared about, so having 
broad discussions about this were not even something that was consdered 
necessary.  At the point where we thought we actually had something in 
place, we reached out to overseers first and made the crucial error of 
not making a public announcement immediately after, which led to the 
confusion at 2022 Cauldron; I'll place part of the blame on the 
overseers too, who misrepresented things by pretending that they had 
never heard about GTI.  That whole scene was just stupid and 
regrettable.  I wasn't there, so I can't claim direct involvement but I 
think that set the stage for the fractured communication since, which 
we're now trying to fix.

Since January though, we've tried to be more proactive and held office 
hours and posted minutes weekly.  I've been relying on Carlos doing all 
of the outward comms, but I think I need to step up here and ease his 
burden given the number of things he's covering at the moment.

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

Carlos and I did send out emails about office hours being cancelled due 
to us not being around, but I agree, we could have also noted that we're 
not going to be able to make the August target since there are a number 
of unresolved questions.  We'll do better.

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

The lack of communication is not the *cause* of your trust issues, but I 
accept that it may have exacerbated any uncertainty you may have had.  I 
think we need to cross-post minutes of the monthly meeting too that we 
have, which literally had the record of everything you've been asking 
about.  I had made a note to do that some time back, but we dropped the 
ball on it.  They're all here btw:

https://lore.kernel.org/cti-tac/

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

I don't think there's a technical dependency as long as the same 
canonical repo is used for direct commits as well as the forge.

>> 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/
Like I said, I'm not sure any mailing lists on sourceware accept html 
emails based on my past experience.  I don't see any recent overseers 
tickets regarding html email policies, where was these requests for 
changing email policies made, for gcc as well as the rollback request 
for glibc?

Sid