On Tue, Jul 2, 2019 at 6:42 PM Boudewijn Rempt <b...@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
