Tipping the apple cart?

[Ben Cooksley]

On Tue, Jul 2, 2019 at 6:42 PM Boudewijn Rempt <boud at valdyas.org> wrote:
>
> On maandag 1 juli 2019 23:34:14 CEST Albert Astals Cid wrote:
> > El dilluns, 1 de juliol de 2019, a les 9:42:34 CEST, Boudewijn Rempt va escriure:
>
> > > Krita has switched from Phabricator to Gitlab a while ago, so maybe I can add our experience. It's not that great, though.
> > >
> > > Bad:
> > >
> > > * For new users who want to submit one or two patches, gitlab is way harder to use. They need much more help and handholding.
> >
> > Really? It uses the workflow all the other major review systems use, arc is a really weird tool (on some distros even hard to install)
>
> Yes, really. I knew this comment was coming, but, yes, really.

I assume this means most of your new users are people who have never
worked with Github/Gitlab before in that case...

>
> > Or were you mostly getting patches sent as plain diffs uploaded to phabricator instead of by using arc?
>
> Yes, nearly nobody uses arc.

So in terms of workflow here, what you're saying is that for the
contributors Krita sees, submitting a classical patch file is what is
required to be viewed as non-painful?
(This is a critical distinction, because there has been an enormous
amount of criticism of the pain Arcanist causes)

>
> >
> > > * Gitlab has an exceedingly confusing UI where many options are very hard to find. The first thing I want to see when I get a MR is the diff,
> >
> > I guess that's your opinion, having the actual textual description and discussion is also very valuable, since you can get an overview on the MR quite fast.
> >
> > > and that means scrolling and hunting for a very small button.
> >
> > You mean the "Changes" button? I find it of adequate size
>
> I guess that's _your_ opinion.
>
> >
> > > * gitlab is slow
> >
> > That's not the perception i have at all.
>
> Try opening the changes tab for https://invent.kde.org/kde/krita/merge_requests/54. This makes my browser warn me two or three times that the page is using a lot of CPU and it takes ages before it succeeds.

I opened this just now on my system and it gave me no issues (using
both Google Chrome and Firefox).

It did take a little while to open (around 20 seconds or so from the
moment I hit refresh), but that's to be expected given it is a review
spanning 509 files, with circa 14,500 additions and 7,000 removals,
comprising 382 commits so I think it's doing quite well there to load
the whole lot up and display it nicely with some syntax highlighting
even.

The only time I managed to make it stall was when switching from
inline diff view mode to side-by-side diff view mode on that review.
Subsequent refreshes loaded fine, and remembered the preference to use
side-by-side view mode without issue. You can open reviews with
/diff?view=parallel appended to the URL to shortcut straight to the
changes view in side-by-side mode.

>
> >
> > > * you cannot have more than one reviewer for a MR
> >
> > You can have as many reviewers as you want, i guess you mean you can't have more than one assignee.
>
> Yes, and we need more than one assignee.

Can you please explain why your workflow is not suited to using
reviewers and requires use of the assignee field?

>
> >
> > > * using the label system for approving a MR is cumbersome
> >
> > What does this mean?
>
> Check that MR I linked above and you can figure out yourself how we're using labels. It's the only mechanism we've found that would get close to the workflow needed to pass a MR from "needs review" to "needs changes" to "approved".
>
> I can use gitlab, I will use gitlab, but it's not the huge newbie-enabler that it was touted to be. It sucks a bit, in practice.
>
>
> --
> https://www.krita.org

Cheers,
Ben