20/4/1 08:42(e)an, Clement Verna igorleak idatzi zuen: > > > 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.
I agree with you that this is something to explore and rethink, but I wonder if the result won't be better if all that rethinking and redesigning process would be done together and with participation of *all* the community and looking for the best solution. Now we autolimited the possibilities, part of the community already chose a path to go forward for all the community, the rethinking and redesigning proccess is tied to and limited by that decision. > > > > So long as it's open and we host it, I don't personally care what we > choose - as long as we can actually use it. > > Thanks, > --Robbie > > > _______________________________________________ > 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
