2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna <cverna@fedoraproject.org>-(e)k hau idatzi zuen:
>On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
><jlanda@fedoraproject.org>
>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.
>>
>
>It depends on the use case, doing development work projects hosted on
>pagure.io is not great in my opinion. In particular working with pull
>requests.
>
I don't have excesive problems with pagure on PR workflows. Right now for me centos-ci is a much bigger problem for PR workflows on pagure.io than pagure itself for example.
Things that I would in my opinion improve Pagure PRs :
* It should be possible to display a few lines of code before or after the diff to help having more context when making the review
Things that would be really nice to have
* Have a way to suggest changes directly while reviewing PRs
Some unrelated to PRs improvement:
* Being able to rename, move projects
* Full Text search projects, users, groups
* Be able to select which event you want to send on the webhook, ie everything or nothing
A lot of these a not necessary things we *really* *really* need to have, but they would make using Pagure much better in my opinion.
>In terms of issue trackers, it is missing the ability to visualize
>issues
>in a board for example.
>Again this my opinion and maybe these are maybe not *really* *really*
>needed.
Is a great forge the beste solution for this? Or are there other solutions for issue tracking/kanban/boards etc that could better suit this use cases?
Possibly but having the feature available at least gives you one more option.
>
>
>> 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? :)
>>
>
>I personally don't think we can release Fedora without people across
>the
>project doing heroics and a crazy amount of hours which seems to have
>become a norm rather than an exception.
>
+1. But is this a git forge problem?
We are again on the same place: we have different use cases hosted on pagure. Some of them could need a big effort on pagure side to compete with other options (on technical features), some others could benefit of migrating to other solutions, and some others could not have a better solution than our own custom one
--
Julen Landa Alustiza <jlanda@fedoraproject.org>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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