On Wed, 1 Apr 2020 at 09:34, Julen Landa Alustiza <jla...@fedoraproject.org> wrote:
> > > 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. Yes I think this is the plan, I don't believe that this would be done in a silo within CPE. I am pretty sure that if this the way forward we (as Fedora) want to explore this will involve a lot of iteration and solicitation for contribution and feedback. > 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. > Indeed I think this is fair for the people that are involved in that work to make the decision. I recognized that the communication and the transparency of the decision has not been good, but I still think that making a decision was a good thing. > > > > > > > > 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 >
_______________________________________________ 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