20/4/1 08:42(e)an, Clement Verna igorleak idatzi zuen:
>
>
> On Tue, 31 Mar 2020 at 22:41, Robbie Harwood <rharwood@redhat.com
> <mailto:rharwood@redhat.com>> wrote:
>
> Clement Verna <cverna@fedoraproject.org
> <mailto:cverna@fedoraproject.org>> writes:
>
> > Neal Gompa <ngompa13@gmail.com <mailto:ngompa13@gmail.com>> wrote:
> >> Clement Verna <cverna@fedoraproject.org
> <mailto:cverna@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-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
>
--
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