Meeting Minutes - Office Hours for CTI - 2026-02-27

[Carlos O'Donell]

On 3/6/26 6:17 PM, Andrew Pinski wrote:
> On Fri, Mar 6, 2026 at 7:23 AM Carlos O'Donell <carlos@redhat.com> wrote:
>> Is there anything you would like me to do differently?
> 
> Yes seperate out the branch discussion and NOT discuss it during the
> CTI open house at all.
People attending the office hours are free to ask any questions they want,
and as both a member of the CTI TAC, and as GNU Maintainer for glibc, I'll
answer those questions wherever they are asked.

If something is discussed that impacts the broader community, not just
answering a persons direct question, then I'll bring it to the list for
broader discussion.

For example all of the branch ownership discussions went to the list.

>> Is there something you think we're missing in the review of these branches?
>>
>> Would you like to see a different model for branch maintenance?
>>
>>>>     * Updated https://sourceware.org/glibc/wiki/SSDLC/Projects/gitolite#Branch_Structure_Evaluation
> 
> Why is this listed as part of gitolite movement? I don't see why this
> can't be done even without moving gitolite.

Thanks for the comments.

I've added it to the glibc SSDLC:
https://sourceware.org/glibc/wiki/SSDLC/Policy/glibc#Store_all_forms_of_code_based_on_principle_of_least_privilege_.28PS.1.1.2C_page_9.29

We should be reviewing top-tier ownership at least once a year to make
sure the docs still make sense and maybe even closing or adjusting the
ownership.

> So basically what I am trying to say is there should be 3 different
> discussions, branch maintaince discussion, gitolite discussion and
> CTI/LF SOW discussion.

Thanks for that feedback.

I'll work to split these out into conversations with narrower scope.

> So a secondary discussion is who is going to do the git hook development?
> Yes there was an audit, but the implementation from what I understand
> is not dependent on moving to gitolite or LF IT. Is there money put
> aside to hire someone to do it or has someone already volunteered to
> do? This is needed for the security side of things. Without this there
> is no movement to gitolite happening.
> If security is an important part of the move to gitolite, then this
> needs to be done as mentioned by JSM and others.
> From what I have seen the development of the new/changed git hook has
> not even started or put as an action item to do. Rather it has been
> the SoW of using LF IT for hosting.

The SOW has two parts:

 * Cost required to transition and improve security.
 * Cost to support ongoing services.

I agree with you that this is a key part of the transition and is part
of the fixed cost portion of doing the transition.

The original SOW has the text describing this here:
https://lore.kernel.org/cti-tac/2186f48a-12cd-4630-8944-26b9042e924a@redhat.com/
~~~
  c. LF will work with the glibc project community to analyze, port,
     and adapt the existing set of repository post-commit hooks to
     ensure that they are functioning after the migration, or are
     replaced with suitable alternatives if existing implementations
     cannot be used directly due to security or other considerations.
~~~

Reviewing an updated SOW is still the next step and the TAC would review
again that we have the same language to cover the work required for the
transition to hooks that execute without access to the repository.

Joseph Myers is on the the CTI TAC and part of reviewing the updated SOW
and was a key contributor to the requirements for the original SOW.

Are you interested in being involved in the work of porting the hooks?

-- 
Cheers,
Carlos.