On pagure side, now that our downstream instances are not using gitolite, implementing them needs much less work that migrating all our toolings to other solutions.
2020(e)ko urtarrilaren 29(a) 15:37:36 (CET)-(e)an, Neal Gompa <ngompa13@xxxxxxxxx>-(e)k hau idatzi zuen:
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.
--
Julen Landa Alustiza <jlanda@xxxxxxxxxxxxxxxxx>
_______________________________________________ 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
