Core Toolchain Infrastructure - Update on glibc service SOW

[Andrew Pinski]

On Tue, Jul 9, 2024 at 7:35 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 2024-07-07 07:42, Sam James wrote:
> >>> AFAICT, all issues raised in the sustained opposition were addressed
> >>> with concrete actions like the CTI website, GNU ethical repository
> >>> guidelines adherance and regular audits.  What remains is feelings,
> >>> i.e. someone not liking the LF or not liking that the TAC members that
> >>> have been attending the calls are all IBMers (note that the TAC itself
> >>> is not).  How do you try to garner consensus in such a situation?
> >
> > I don't feel like this is a fair representation of my reluctance and
> > I've never made any such conspiracy handwaving noises.
>
> Sorry about that, I only tried to summarize my observation from the ~6
> years that these discussions have been going on and attempted to dispel
> the perception that it's all doom and gloom.  Sure, 2022 Cauldron is
> when the entire thing unceremoniously stumbled out and unfortunately set
> the tone for discussions after but everyone, including sourceware
> overseers have been involved in discussions since long before that.

Here is my problem with what happened after 2022 Cauldron.
The other TAC members should have distance themselves from the
violence that happened but that didn't happen. The person who did the
violent act didn't have any repercussions of their actions at all. And
they were kept in a situation of power which signaled to many folks
(including myself) that kind of behavior is acceptable by the TAC
members. So why should I join meetings which has members (in power
even) that use violence to get their way? That alone is one of the
reasons why I have not joined any of the TAC members and still will
not join and even think LF will always be the wrong solution because
there is no place for violence at all.

Thanks,
Andrew Pinski

>
> > (That said, now it's been brought up: why aren't other TAC members
> > attending? Are all the glibc stewards attending? If not, why not?)
>
> I would guess for reasons similar to why very few people attend the
> Monday patch review meetings: time constraint.  They've been reachable
> on email.
>
> >> 1. What concerns do you still have about the *long term viability* of
> >>     hosting glibc, specifically, on LF-managed infrastructure?  Not just
> >>     technical; for example, if you do not believe LF will still exist
> >>     twenty years from now, that would fall in this category.
> >
> > I don't understand the structure / governance of the new model. It
> > sounds like the community-led TAC only gets one seat on the board and
> > the rest are from sponsors?
> >
> > Are the sponsors only willing to provide funding in this model? Why?
>
> AFAICT all LF projects follow this model, so it's not something special
> (or not) that is being done for the CTI project.  My position as TAC
> member is that we only need enough representation on the GB to ensure
> that the technical justification for spending requests we make are
> portrayed correctly.
>
> Also, the GB does not decide project direction, the TAC does.  GB only
> gets to decide if they want to spend money on a certain project or not.
> For example if we ask for a beowulf cluster of machines to run
> build-many-glibcs for pre-commit CI, they GB may decide it doesn't want
> to spend money on that, and we then look to SFC through Sourceware to do
> that.
>
> >> 2. What concerns do you still have about *moving* from where glibc has
> >>     been hosted for the past umpteen years?  Again, not just technical.
> >>     If your position is that the switching cost is too high, for whatever
> >>     reason, speak up under this point.
> >
> > I'm particularly concerned about losing Bugzilla history. Having it all
> > in one place and being able to cross-reference it is important.
> >
> > Somewhere, I think I saw Carlos speak about how not all services
> > necessarily need to be on LF, just some. (Apologies if I'm
> > misremembering or if that's outdated.) If that's the case, Bugzilla at
> > least doesn't feel like it's worth moving at all. Then what else is there?
> >
> > But otherwise, I just don't see any described benefits here as
> > outweighing the status quo. i.e. I haven't seen a compelling case for
> > moving.
>
> For a recent anecdote, we've had more than a few instances of git access
> being hampered because someone's spamming bugzilla or moinmoin.  The
> reason why this cannot be addressed in the context of sourceware is
> because it's just one machine that hosts everything.  With CTI we're
> going to scale this out into isolated instances for git, patchwork,
> bugzilla and mail handing so that it's not possible to compromise
> security (and developer experience) with git if, e.g. patchwork was
> somehow compromised.
>
> > If there are particularly new services that we need which Sourceware
> > cannot or won't provide (and I'm not aware of any), why not stand those
> > up on LF infra first to see how it goes? What are those services?
> >
> >>
> >> 3. In both cases, what would satisfy you?  What would need to happen for
> >>     you no longer to be concerned?
> >>
> >
> > I'd need to see a list of tangible services or improvements the current
> > setup can't provide - with citations for where the Sourceware team rejected or
> > accepted they couldn't meet the community's needs.
> >
> > I'd also need to know the list of sponsors and know that the governance
> > of the new body is community-led.
>
> The TAC is completely community led:
>
> https://cti.coretoolchain.dev/tac/index.html
>
> The GB only provides fiscal oversight and consists of sponsors.  At the
> moment CTI is an affiliated project at OpenSSF, i.e. it's sponsored
> directly by the OpenSSF.  We don't have big enough funding requirements
> at the moment for glibc:
>
> https://cti.coretoolchain.dev/gov/index.html
>
> > I would need to also feel the community is being listened to, which I
> > don't feel so far.
>
> Would it help if monthly meeting minutes were mirrored to libc-alpha too?
>
> Thanks,
> Sid