Dne 01. 04. 20 v 8:42 Clement Verna
napsal(a):
On Tue, 31 Mar 2020 at 22:41, Robbie Harwood <rharwood@xxxxxxxxxx> wrote:
Clement Verna <cverna@xxxxxxxxxxxxxxxxx> writes:
> Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>> Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote:
>>
>> As for Pagure itself, I think this is where we fundamentally
>> disagree. I think it behooves us to own and provide an experience
>> tailored for our community from beginning to end. That's why we have
>> Koji, Bodhi, Dist-Git, and many other tools in that part of the
>> lifecycle. The packager experience is literally the lifeblood of the
>> project, and our contributors are the core of what makes Fedora
>> successful. Pagure gives us an opportunity to do right by them that I
>> *really* don't think we can do with any alternatives.
>
> I am not convinced that having a custom git forge is mandatory to
> provide an great experience to the community. I wasn't really around
> the community before Pagure, but I as far as I understand it the
> experience was better before Pagure and people were able to do more
> self servicing. I believe that there is an alternative to having the
> packager workflow tightly coupled to the git forge, this is also maybe
> a good opportunity to rethink some of that workflow and explore
> different solutions.
Well, this continues to conflate "git forge" and "solution for
dist-git".
Yeah sorry I was not very clear, communication is hard and communication via email is awfully hard. Personally I do not think that git hosting is a problem. In today's world it is very easy to find solution to host a project on a git forge and there are plenty of solution available. Also I think it is important to note that the plan is to keep pagure.io running as long as there are people willing to do the maintenance and based on that thread I don't think that will be a problem.
Before pagure, we had a (no-webui) git serving dist-git with other
services (e.g., pkgdb) stapled on. More self-servicing was possible
because it was a more mature project. In my opinion, the move to pagure
happened prematurely due to lack of feature parity - a problem we're
still dealing with today, which I think is what your "self servicing" is
in reference to.
Before pagure, we also had fedorahosted, which was our solution for
hosting projects, combining trac and a few other things. Migration was
*painful*, and there have been many rocky parts along the way, but the
experience now is definitely better than fedorahosted. It's far less
pleasant than a github project, though.
My impression is that most folks on this thread are more worried about
dist-git and its integrations than a general git forge, while it feels
like all CPE wants to talk about is the git forge. You can't just use a
git forge as a dist-git: it takes a lot of integration work, which is
invisible because right now it's been done and just works™. The refusal
to consider that this work exists in the decision worries me .
I think this feeling comes from the mixing of git forge and dist-git use case that you have pointed out. In CPE there is awareness of the amount of work needed for migrating dist-git and all the integration you are mentioning. My personal opinion is that this will not be a small or easy project but I still think that this is worth it on the long term. I also agree with what Kevin Fenzi said earlier in this thread that we should take the time to rethink that integration layer around dist-git and minimize the dependencies to the git hosting solution, so that git hosting would simply be git hosting and it would not really matter if this was done by Pagure, GitLab, or any other solution.
This was actually done when Pagure was introduces as a dist-git frontend, because Pagure at that time was generic git hosting. Due to that, we lost all the PkgDB functionality. As soon as the functionality is almost back after more than two years, we are going to loose it again. This is saddening.
Vít
_______________________________________________ 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
