Re: CPE Git Forge Decision

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




20/4/1 08:42(e)an, Clement Verna igorleak idatzi zuen:
> 
> 
> On Tue, 31 Mar 2020 at 22:41, Robbie Harwood <rharwood@xxxxxxxxxx
> <mailto:rharwood@xxxxxxxxxx>> wrote:
> 
>     Clement Verna <cverna@xxxxxxxxxxxxxxxxx
>     <mailto:cverna@xxxxxxxxxxxxxxxxx>> writes:
> 
>     > Neal Gompa <ngompa13@xxxxxxxxx <mailto:ngompa13@xxxxxxxxx>> wrote:
>     >> Clement Verna <cverna@xxxxxxxxxxxxxxxxx
>     <mailto:cverna@xxxxxxxxxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> 

-- 
Julen Landa Alustiza <jlanda@xxxxxxxxxxxxxxxxx>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux