Dne 01. 04. 20 v 8:42 Clement Verna napsal(a): > > > On Tue, 31 Mar 2020 at 22:41, Robbie Harwood <rharw...@redhat.com > <mailto:rharw...@redhat.com>> wrote: > > Clement Verna <cve...@fedoraproject.org > <mailto:cve...@fedoraproject.org>> writes: > > > Neal Gompa <ngomp...@gmail.com <mailto:ngomp...@gmail.com>> wrote: > >> Clement Verna <cve...@fedoraproject.org > <mailto:cve...@fedoraproject.org>> 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 <http://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@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
