Per git ref acls is not a common thing on git forges. If this is a final
requirement, we should start analyzing the viability of implementing and
maintain it on the different forges (and it should be feasible with all of the
rest of our strange ACLs on dist-git)
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
<ngomp...@gmail.com>-(e)k hau idatzi zuen:
>On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon
><pin...@pingoured.fr> 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@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
--
Julen Landa Alustiza <jla...@fedoraproject.org>
_______________________________________________
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
