Clement Verna <cverna@fedoraproject.org> writes:
> Neal Gompa <ngompa13@gmail.com> wrote:
>> Clement Verna <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 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.
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