On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote: > > (snip) > > > > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen: > > >To me that's the all point of this process, let's put down what we > > >*really* *really* need and then look at the different options. > > > > > > > Do we *really* *really* need to compete with other full featured git > > forges on features? The ODF says that this is one of the problem. > > Well, imo we don't *really* *really* need to compete with them. > > > > Actually we already have the features that we *really* *really* > > need. Otherwise we could not release fedora using pagure as we are > > using, could we? :) > > So let's revert the question, pagure does the what it needs to do and enough of > it, otherwise we would not be using it. > > What does pagure miss that other solutions have and that could be considered a > requirement? > > It could be that we don't **need** pagure to do anything more than what it does > today, which moves the discussion off a technical ground. > >From a Dist-Git perspective, there is are two things I need: * per-branch ACLs * the ability to set bugzilla owners without granting commit access. The first thing is because I get nervous granting people access to the Git project who want to build EPEL8 packages but clearly aren't good at managing Git workflows. I don't want them breaking my workflows with Fedora packages. The second thing is because there are a number of packages that I maintain where upstream would like to be notified on bugzilla bugs but not otherwise be involved in packaging. Pagure itself has the ticket ACL for this, but I don't think this does anything in the Dist-Git setup. >From the Git forge perspective, the two big things I need are: * working self-service CI * workflow for self-service integration management per-user and per-repo The first item is because the current Pagure CI with CentOS CI Jenkins is inexcusably bad. Jenkins is often unresponsive and broken, and configuring it requires manual intervention from the CentOS CI folks. Part of the reason we have Pagure was to move to more of a self-service model, and our default offering for CI services fails at that. The second item is because there are an array of third party Free Software services out there that people should be able to use without having to talk to the Pagure admin to activate or enable. We do have webhooks for basic integrations, but doing authentication and authorization flows for generating app tokens and such is something we don't have today. Having this would allow far more sophisticated integrations than what we have now without always having to involve an admin over it. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
