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
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.
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.
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.
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.
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.
