Dne 01. 04. 20 v 8:42 Clement Verna napsal(a):
On Tue, 31 Mar 2020 at 22:41, Robbie Harwood <rharwood(a)redhat.com
<mailto:rharwood@redhat.com>> wrote:
Clement Verna <cverna(a)fedoraproject.org
<mailto:cverna@fedoraproject.org>> writes:
> Neal Gompa <ngompa13(a)gmail.com <mailto:ngompa13@gmail.com>> wrote:
>> Clement Verna <cverna(a)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.
This was actually done when Pagure was introduces as a dist-git
frontend, because Pagure at that time was generic git hosting. Due to
that, we lost all the PkgDB functionality. As soon as the functionality
is almost back after more than two years, we are going to loose it
again. This is saddening.
Vít