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

[Andrew Pinski]

On Sat, Mar 14, 2026 at 3:22 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> 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?

No I am NOT interested in doing the work for porting the hooks. I was
asking if there is money to pay someone to do that work or is it
always going to be a volunteer and if there was a volunteer already.
I am also saying this should really be a paid position to do the work
of porting the hooks and improving security. This is real first step.
Without that the hosting part should not make a difference.

Thanks,
Andrew

>
> --
> Cheers,
> Carlos.
>