Our dist-git stack has a bunch of customization and personalization that are not currently available on gitlab nor any other opensource forge, and some of them will collide with gitlab's CE vs EE edition model, so they'll be hard to get to upstream. Right now we have at least a custom auth provider, unusual ACLs for the standard user, system-wide powerusers, group syncing to the instance, branch ACLs, mass-branching and many more features already implemented that are not going to be easy (or they'll be impossible) to merge on upstream's CE edition. They're working and they're critical on our use case. Almost all the auth privder and ACL things are EE features on gitlab, CE just support basic authentication from providers, no more, and we need a bunch of weird rules there, and we already have them implemented!
So, we would have to develop & carry all those things on custom patches, without being able to push them to upstream, so there will not be nor outside contributing to them nor support nor anyone outside fedora will take advantage of our work either, so implementing, maintaing and rebasing all this customization will burden the team again. So, where is the point here? On the other hand, pagure needs a lot of improvement, specially on interface. Internals are decent and they work, we have more problems on UI/API exposition etc. From 400 issues that are right now open on pagure, 200 are RFEs, and the vast majority of them are about UI/API enchancement and similar features. Can we work on this from the community? Would be possible to continue using pagure for dist-git if we go polishing all this things? We don't need a gitlab clone, let the developers host their developing on the forge they want, github, gitlab, event subversion or darcs, it does not matter, our focus should not be cloning gitlab but making a better packaging experience for the packager community, mainly a decent frontend for our packager workflows and there pagure vs cgit is a great improvement. And where is pagure.io with this? Well, if we continue using pagure for dist-git, the development costs of pagure.io should be minimal or zero, since we would be developing it for src.fp.o and other dist-git instances as well, and then we should just have the maintenance costs. Are the pagure.io maintenance costs a big burden for CPE? Let share them with the community. -- Julen Landa Alustiza
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
