Meeting Minutes - Office Hours for CTI - 2026-05-29
Andrew Pinski
pinskia@gmail.com
Fri Jun 5 18:06:29 GMT 2026
On Fri, Jun 5, 2026 at 10:55 AM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 5/29/26 8:55 PM, Andrew Pinski wrote:
> > On Fri, May 29, 2026 at 12:10 PM Carlos O'Donell <carlos@redhat.com> wrote:
> >> * Carlos: We just finalized an updated SOW with LF IT that is the same as the previous 2024 SOW, and next steps are to start public discussions about service transitions and dates.
> >
> > The SOW in 2024 didn't have enough about the transition and who was
> > going to do the work and acceptance criteria of the move. So Why reuse
> > it? I made a mention about this before. But it seems like nothing has
> > changed here.
>
> Andrew,
>
> The SOW is intended to provide the high level structure to the contract
> and what is being provided, by whom, and how much it costs.
That is what a SOW is or should be. It is a "statement of work". It
describes acceptance criteria, what if something goes and the full
outline of everything.
>
> That hasn't changed, so the SOW hasn't changed.
>
> There are provisions in the cost structure for the initial bootstrapping
> and onboarding to support the transition and update of services.
>
> Do you have a reference to what you previously requested?
I mentioned acceptance criteria many times and you keep on skipping over that.
What is the acceptance criteria of accepting that we should preceed
after a trail transition has happened?
What if the community rejects the trail prediod? etc.
This is the full SOW should contain. NOT just a high level. It needs
to contain who is doing what and very much specifics. Not just saying
the community will help out here. It needs to spell out everything.
That is how normal SOW works. It should spell out point of connects on
both sides; which I didn't see. Etc.
>
> May you please restate here what you were looking for and I can see if
> the CTI TAC can answer those questions?
>
> I think the upcoming breakdown we'll be working on with glibc, CTI TAC,
> and LF IT, may be what you're looking to review?
>
> > I sitll think glibc should start thinking about using the forge before
> > any other dicussion going forward with respect to hosting.
>
> I disagree that we should start with that.
Why? Does the glibc community disagree or just you? Does the CTI TAC
disagree or has this not been put forward as an option? I have not
seen any consense on if it is NOT the way forward except for you
disagreeing.
>
> I do agree that we should be talking about using a Forge for development.
>
> I'm happy for the glibc developers to start working on the Sourceware Forge
> to experiment and develop work flows that everyone can use.
>
> I expect that experimentation to take time.
>
> --
> Cheers,
> Carlos.
>
More information about the Libc-alpha
mailing list