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

Reply via email to