On Thu, Sep 26, 2019 at 7:11 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
>
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every changes to dist-git is done via pull-requests
> >
> > IMHO Have to stay optional, making this mandatory being a terrible headache.
>
> What makes it a headache? What can we do to not have this be a terrible
> headache? Can we fix/improve the tooling?
One of the reasons I push directly to branches in Pagure instead of
opening Pull Requests is that the workflow is too clunky and slow. I
have to toggle between the browser and the console, make sure I have a
Fedora Kerberos ticket, etc.
Please get a stopwatch app and try the following workflows in GitHub
and Pagure, and compare the speed at which you can do these:
- Create a new personal fork of a repository
This is almost instant on GitHub, and much slower in Pagure,
sometimes hanging entirely at the "waiting..." web page.
- Push a hundred commits to a topic branch
GitHub can accept the ref updates very quickly, and Pagure has so
many hooks and operations that I've seen my Git client hang for
seconds or sometimes even minutes. I'm not sure what is going on, but
I suspect it involves ACL checks, Fedmesg, etc. I've seen this one
several times: I forked a project a year ago and I did not update my
forked copy of "master". I push a new topic branch to my clone, and
this topic branch has all the changes from todays' upstream master,
plus my new changes for the topic branch. When I run "git push" for my
new topic branch, Pagure.io will process all of those commits
one-by-one and emit fedmsgs for all of them *according to my old
version of master, not upstream*. I have no idea if that is single
reason for why I see my "git push" commits return very slowly, but it
is probably one of the reasons.
- Open a new pull request
The GitHub web UI provides a lot of different buttons in a lot of
different places, allowing the user to fall into the "pit of success"
and submit the change upstream. GitHub always immediately knows "hey
this branch is ready to go upstream, do you want to open a PR?" With
Pagure, the UI to open a pull request requires many different clicks,
and if I open it from certain pages (like the origin repository), the
web UI makes some AJAX calls that just hang forever. GitHub also has a
really mature CLI ("hub") that makes opening PRs lightning quick
because the GitHub's REST API responds very fast.
You might wonder why I've not opened tickets for these, and it's
because I am not sure it's worth piling on your team when you guys are
already extremely overloaded. The UX problems I've encountered do not
strike me as trivial issues to resolve in an afternoon. Sometimes I
ask in #fedora-admin if it really looks like I've broken something.
Maybe that's lame and I should just open the tickets. I also have a
bigger concern though: I've played around with pygit2 in some smaller
applications in order to learn it, and I'm beginning to think that
it's simply not possible to get close to the performance and
functionality that GitHub has achieved.
I would like to hear if you see Pagure as still strategic, and if so,
how we can make these common user operations faster.
- Ken
_______________________________________________
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
