Hi everyone, As I am working on bringing pagure as a front-end to our dist-git, a question is troubling me.
Currently ACLs are stored in pkgdb, it allows having a per-branch ACL model, which in itself is quite cool, but I wonder: is it that useful? I know pkgdb brings us other things too and I am explicitely ignoring them here because I think we can find solutions for them, which may even have benefits over our current processes. So, does per-branch ACLs make sense to you? Have you had cases where you thought it was good/bad? More importantly, have you had cases where you would want to give someone access to just one branch and really really do *not* want them to have access to the other branches? Of course, EPEL vs Fedora comes to mind here, but I wonder: if the EPEL maintainer has also commit on the Fedora branches, is it really that much of a big deal? And vice-versa? Before I investigate what it would take to drop pkgdb entirely and let pagure handle the ACLs, I wanted to hear from you if you think this is a terrible idea or worth investigating. Thanks in advance for your feedbacks and ideas, Pierre PS: for full disclosure: pagure does not support per branch ACLs at the moment and in the current way we are syncing information from pkgdb to pagure, we are only taking rawhide into account. So if you have commit on rawhide, you will have commit access on pagure to all branches, if you do not have commit access on rawhide, you won't have commit access on pagure. Note that this concerns only commit access via the UI and the ability to merge PR as gitolite underneath (used when doing git push via ssh) still per branch ACLs. PS2: I am also considering this question having in mind the change in branching model the modularity work will bring (ie: branch no longer tied to a Fedora version but rather to upstream's version)
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
