What to do about src.fedoraproject.org - a long term planning discussion

Continuing the discussion from Fedora-Council/tickets ticket #473: Git Forge Evaluation 2024:

Beginning a more focused topic to talk about src.fedoraproject.org specifically, as this seems to be the best place to start from. What are the pain points we need to address when looking at the current way we use pagure as a dist-git? Is there potential vulnerability we need to resolve? Are there features we need but dont have? I believe one of Kevins questions was

I like this question, and I think we should try to answer it before spending too much time examining other git forges as potential solutions. Then we will have a common goal, and then we can spend some time on the investigation part :slight_smile:

What are your thoughts?

2 Likes

Thanks for soliciting some pain points. Below is one.

Identity integration friction. Identity is not seamlessly integration between forge components, especially bugzilla and pagure. If I am authenticated with one component, I have to authenticate with the other when I switch to it. Add to that the two factor step in FAS and the irritation factor mounts up quickly. Especially when compared to the user experience in github or gitlab.

1 Like

This isn’t inherent to Bugzilla and Pagure. This is an aspect of how our SSO works, where it doesn’t reuse the authentication to log into other components when you click the login button. I find it irritating too, but everything uses OIDC or SAML2, so the login experience is chiefly in Ipsilon, our SSO system.

You shouldn’t have to re-authenticate if you have a valid kerberos
ticket.

Run ‘fkinit’ from fedora-packager-kerberos, and then just clicking login
with fedora on bugzilla or login on src.fedoraproject.org should just
log you in using your kerberos ticket with no further interaction needed
from you.

Of course tickets are only valid for a day + can be renewed for a week
(if you set this up in gnome-online-accounts it will take care of
renewing the existing ticket for a week for you).

Most of Fedora’s desktops don’t have the GOA FAS integration. There’s no KAccounts integration, nor is there a way to do this for desktops that don’t have either GOA or KAccounts or something similar as far as I know.

Indeed, although you can also configure sssd_kcm to automatically renew.

But of course you need to know to do this, it’s not default.

The Community Platform Engineering team did an initial investigation into what services are used for Fedoras dist-git. The findings are posted here Dist Git Move — ARC notes documentation

Does this investigation represent the critical requirements for Fedoras dist-git use? If it does, perhaps our next steps as a community is to decide on a few (maybe max three?) dist-git alternatives to evaluate our needs against the requirements outlined in this investigation.

I envision this evaluation to be done by folks who have experience in using dist-git and some time spare with the support of the CPE team.

What are your thoughts?

1 Like

I like the idea someone else mentioned that we try and form some teams
around proposals. ie, small groups that would put together a plan for
their preferred solution and then present it all to the council/fesco.

So, a ‘keep pagure team’ a ‘forgejo team’, etc?

But I’m not sure there are enough interested parties to form such teams
I guess.

Well… that’s a decent way to see which options really have meaningful support.

That assessment primarily represents the way software interacts with dist-git — various other applications like Bodhi, Copr, etc. I think humans may be under-represented — current packagers, people doing drive-by PRs, potential new packagers, and advanced users looking for more information.

There is: Pagure Dist Git Interactions by Fedora Packagers — ARC notes documentation, but I don’t think it really covers more than a few basic actions.

Also, Pagure Dist Git Interactions With fedpkg — ARC notes documentation … that seems a bit short, too.