|
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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
