Re: Tipping the apple cart?
Am 01.07.19 um 15:37 schrieb James Ramsay: Is it primarily the previous discussions so that you can better respond directly via email? If so, this proposal to include entire discussion thread in email notifications (https://gitlab.com/gitlab-org/gitlab-ce/issues/40557) which Zsolt is looking at might meet your needs. What do you think? GitLab does support leaving review comments in bulk rather than one at a time but it is currently in the GitLab Premium tier. There is a proposal (https://gitlab.com/gitlab-org/gitlab-ce/issues/60690) to move it to the Core tier (free, GitLab CE) being considered. Do you have any other feedback about GitLab? I would be very interested to organize a video call to hear any wide ranging thoughts on what it would take to make GitLab code review better than Phabricator and Reviewboard for your needs if you can spare the time. Best, James Thanks for being willing to engage, James! It's very much appreciated. Backporting the Merge Request Reviews feature [1] will be a big improvement to address email overload and I look forward to that. In my own trial use of KDE's GitLab instance, the other source of email overload is the fact that it sends one email per action, rather than offering a web-based notification center capable of batching up notifications that all pertain to the same Issue or Merge Request (proposed here: [2]). The problem with the "one email per action" approach is that it implicitly assumes a workflow where everyone is sitting at their computers all day waiting for emails to come in, and triaging them accordingly [3]. This doesn't describe most members of the KDE community. The vast majority of KDE contributors are volunteers who can devote a few hours a week to the project, and are virtually never sitting in front of a computer all day handling KDE-related emails in real time as they come in. Even those who can are generally developers who find handling email a distraction during periods of time when they're trying to write code. We already have a problem with people filtering, auto-deleting, or ignoring emails. The more emails people get, the more acute this issue becomes. Some implementation of what's proposed in [3] would be hugely helpful to remedy the issue originally described in this thread, and would be a big step up from Phabricator rather than a downgrade or side-grade. Nate [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/60690 [2] https://gitlab.com/gitlab-org/gitlab-ce/issues/64183 [3] https://gitlab.com/gitlab-org/gitlab-ce/issues/29488#note_25414909
Re: Tipping the apple cart?
Hi James, thanks for the info, that sounds great! I think the lack of context and bulk review are really my main issues. Other than that I can't think of any right now. I also only just now realized the filename shown in the mail is actually a deep-link to the actual comment. Cheers Kai Uwe Am 01.07.19 um 15:37 schrieb James Ramsay: Is it primarily the previous discussions so that you can better respond directly via email? If so, this proposal to include entire discussion thread in email notifications (https://gitlab.com/gitlab-org/gitlab-ce/issues/40557) which Zsolt is looking at might meet your needs. What do you think? GitLab does support leaving review comments in bulk rather than one at a time but it is currently in the GitLab Premium tier. There is a proposal (https://gitlab.com/gitlab-org/gitlab-ce/issues/60690) to move it to the Core tier (free, GitLab CE) being considered. Do you have any other feedback about GitLab? I would be very interested to organize a video call to hear any wide ranging thoughts on what it would take to make GitLab code review better than Phabricator and Reviewboard for your needs if you can spare the time. Best, James
Re: Tipping the apple cart?
On 7/2/19 3:53 PM, Valorie Zimmerman wrote: Please lets keep in mind that this is not a thread to complain about Gitlab. No platform is perfect, and we're not yet on production machines. This thread is about how to make our review process great for both newbies and experienced developers, *and reviewers* - on Gitlab. Unfortunately the original topic is intertwined with current GitLab deficiencies. The ease of merging patches with one click in the web UI is a significant improvement over Phabricator, but from a reviewer & project management perspective, I must admit that I have not had a pleasant experience with GitLab so far. For the originally-discussed topic regarding automatically adding reviewers to Phabricator patches, it's not even applicable because our GitLab instance doesn't have the "Merge Request Reviewers" features. So compared to with Phabricator, it is not as clear when a patch is actually ready to land or when specific changes are required. Regarding the topic of how to encourage people to pay more attention to submitted patches rather than filtering/deleting/ignoring the notification emails, GitLab seems much worse. Like Phabricator, it adopts the deficient "one notification per action" approach, rather than the far superior GitHub-style "one notification per issue/pull request" approach. I also haven't found a way to turn off emails and instead receive notifications only via a built-in "notification center" page in the website, as I can with both Phabricator and GitHub. As a result, when 10 issues or patches on GitLab receive 10 comments each, I get 100 emails. This is compounded by the problem of inline comments in patch reviews generating one email per comment. For merge requests with many inline comments, I get a flood of 10 or 20 emails over a short period of time. The email overload problem is therefore worse than it is currently for Phabricator projects, and hugely worse than it is for the GitHub-hosted projects that I follow. While we're on the subject of things that impact the patch reviewing usability, when an inline comment is marked as resolved, the context surrounding it does not change and it continues to show the old diff rather than the latest diff, so it's impossible to tell what changes were made to mark the comment as resolved. This is also a regression compared to Phabricator. I'm also disappointed by the impending loss of Phabricator Tasks, which I use extensively on Phabricator for project planning and tracking. GitLab doesn't have a "Task" feature at all, so you need to use Issues for developer task discussions. If we ever migrate Bugzilla to GitLab Issues, this will result in zero separation between developer discussions and user-submitted issues, which will become very disruptive. Issue/Kanban Boards are not really a replacement because they're just an organized collection of existing Issues. There's only one of them per project, they aren't cross-project, and there's nowhere you can discuss an overarching goal. I have no idea how I would use GitLab to do something like https://phabricator.kde.org/T10891, with its task graph and centralized discussion. And yes, I did bring up all these issues during the initial evaluation etherpad document: https://notes.kde.org/p/gitlab-evaluation-notes I hope these issues can be resolved prior to the full changeover. Nate
Re: Tipping the apple cart?
In our move to Gitlab, we can do better. Given Gitlab emails contain even less information and context than Phabricator which themselves contained even less information and context than Reviewboard back then, I don't see how this will change or improve anything. Thanks for the feedback Kai. As the Product Manager for Git and Code review at GitLab, I am interested to know which information from Phabricator and Reviewboard you miss in email notifications from GitLab? Is it primarily the previous discussions so that you can better respond directly via email? If so, this proposal to include entire discussion thread in email notifications (https://gitlab.com/gitlab-org/gitlab-ce/issues/40557) which Zsolt is looking at might meet your needs. What do you think? Phab sends out an email for every event and comment And Gitlab even unexpectedly submits the comments as soon as you close the editor rather than in bulk as I would have expected from a proper reviewing workflow. GitLab does support leaving review comments in bulk rather than one at a time but it is currently in the GitLab Premium tier. There is a proposal (https://gitlab.com/gitlab-org/gitlab-ce/issues/60690) to move it to the Core tier (free, GitLab CE) being considered. Do you have any other feedback about GitLab? I would be very interested to organize a video call to hear any wide ranging thoughts on what it would take to make GitLab code review better than Phabricator and Reviewboard for your needs if you can spare the time. Best, James
Re: Tipping the apple cart?
Please lets keep in mind that this is not a thread to complain about Gitlab. No platform is perfect, and we're not yet on production machines. This thread is about how to make our review process great for both newbies and experienced developers, *and reviewers* - on Gitlab. On Sun, Jun 30, 2019 at 2:53 PM Valorie Zimmerman < valorie.zimmer...@gmail.com> wrote: > Hello folks, as you know, I'm not a coder. However, I'm interested in our > code quality, and there has been some observation that "lots of patches get > missed, and submitters get confused due to a lack of auto-populated > reviewers" on Phabricator. Nate Graham has been adding groups to the > reviewers by hand, and would like to not do that any more. > > However, many developers simply route all Phab emails to folders where > they sit unread, because Phab sends out an email for every event and > comment! This is far too spammy. In our move to Gitlab, we can do better. > Right now, the devel email lists get these emails -- but it is assumed that > they are often not read, because of the number of patches sitting > unreviewed, and unused. This is bad for our community, and very > discouraging to newcomers. One of our best recent initiatives has been the > improve our onboarding process, and this needs to be part of it. > > Improving the workflow on Phabricator is almost pointless, since we're > leaving it. However, please give your ideas, thoughts and even opinions on > how best to improve this in Gitlab. I think if we engineer this well, we > can get more newbie contributors and more new *reviewers.* > > I'm ok with starting Yet Another discussion which threatens to tip the > apple cart, because right now, the apples are already on the ground, > rotting. > > Valorie >
Re: Tipping the apple cart?
El dimarts, 2 de juliol de 2019, a les 8:42:26 CEST, Boudewijn Rempt va escriure: > On maandag 1 juli 2019 23:34:14 CEST Albert Astals Cid wrote: > > Or were you mostly getting patches sent as plain diffs uploaded to > > phabricator instead of by using arc? > > Yes, nearly nobody uses arc. As a data point i went over the 50 most recent phabricator code reviews, stats say 48 uploaded using arc 2 uploaded not using arc Then i went over the 20 most recent phabricator Krita code reviews, stats say 15 uploaded using arc 5 uploaded not using arc Then again this is counting MRs not counting people, it could be that all the 15 arc MR where made by 2 people and the other 5 by 5 different people, i was bored enough to check that. I understand that you have the impression that nearly nobody uses arc, but it'd seem to me that stats show otherwise (but would need more investigation about it). Anyway, didn't gitlab have the "send patch by email to create a MR" functionality? Would that solve your issue? > > > > > * 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. Yes, when i write "I find it of adequate size" i thought it was clear it was "I" stating that "find it" of "adequate size". > > > * 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". Right i see. Would using the "thumbs down" to say "needs changes" make sense instead of using the label? I guess it was more the original idea they had. Cheers, Albert
Re: Tipping the apple cart?
On dinsdag 2 juli 2019 13:07:02 CEST Ben Cooksley wrote: > I assume this means most of your new users are people who have never > worked with Github/Gitlab before in that case... I don't know; it might mean that, but I cannot be sure. I can only report the reactions from my newbies :-) > 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? yes, that's what people tend to want, it seems. > (This is a critical distinction, because there has been an enormous > amount of criticism of the pain Arcanist causes) I've never been able to use arcanist myself... I just could figure out how to make it work for me. > 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. Weirdly enough, gitlab never seems to remember the side-by-side setting for me :-( 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? Is there a place where we can assign multiple reviewers? I haven't found one. -- https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Tipping the apple cart?
вт, 2 июл. 2019 г. в 14:07, Ben Cooksley : > > On Tue, Jul 2, 2019 at 6:42 PM Boudewijn Rempt wrote: > > 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, Hi Ben, We discussed GitLab performance a few months ago on kde-devel mailing list, then the discussion stopped. You can re-read it below. I believe all my statements there are still valid, and I still believe 20 seconds of loading time is very painful. = = вс, 24 февр. 2019 г. в 00:47, Ben Cooksley : > > On Sun, Feb 24, 2019 at 10:30 AM Alexander Potashev > wrote: > > > > сб, 23 февр. 2019 г. в 12:44, Ben Cooksley : > > > Based on all of the above we'd like to propose migrating towards > > > Gitlab. Comments? > > > > Hi, > > Hi Alexander, > > > > > 1. We migrated from github.com to self-hosted GitLab when I worked > > full-time in a team of 4 developers. A major drawback we noticed back > > then was slow page loading when browsing a large diff (e.g. in a merge > > request). For example, this commit takes around 15 seconds to load: > > https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 > > That commit is massive and is far beyond what would be routine for a > project to commit, so I think it's quite reasonable for the system to > take a bit of time to process it. > Loading that page right now using the web inspector shows it takes > about 8 seconds to generate, followed by a further 4 seconds to > download, which doesn't seem unreasonable for 3200 lines of changes, > plus context, over 187 files - especially given it syntax highlights > it. Hi Ben, The thing is, it's much slower than github - that's why we noticed the issue. I'm not sure if GitLab is slower than Phabricator, but at least it tries to feel fast and loads the whole diff incrementally, so that the first portion is available in less than 1 second. For reference, here is that same commit in 4 different web UIs: - https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 - https://github.com/KDE/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 - https://phabricator.kde.org/R158:aadd9305b0467fa39e5c84af606c7d9eb1568533?show_all=true - https://cgit.kde.org/kdenlive.git/commit/?id=aadd9305b0467fa39e5c84af606c7d9eb1568533 (cgit also has syntax highlighting :)) You are right merge requests as large as this commit are not common, but 1. Once you have a large merge request, maintainers will probably spend some days reviewing it and may be open the same diff page many times, thus multiplying the suffering. 2. Diffs that are 10x smaller that this one are common, and a 1.5 second loading time (15s / 10 = 1.5s) is still not very comfortable. 3. A merge request may comprise multiple commits (e.g. 20 commits) and it's handy to browse/review a squashed diff for the whole merge request, making the diff 20 times longer that an average commit diff. Reviewing of multi-commit merge requests is also available on GitHub, and it's still fast there unlike GitLab. -- Alexander Potashev
Re: Tipping the apple cart?
On Tue, Jul 2, 2019 at 7:09 PM Kai Uwe Broulik wrote: > > Hi, > > > What are you missing? > > The description of the change (Review Board had that, Phabricator > doesn't, so I got used to it, I guess...), the context of the comment > (i.e. the code snippet a comment was added to), so I don't need to open > GitLab to figure out what's going on. > > On Phabricator you get: > > Subject: D12345: Do something amazing > "Foo added inline comments > INLINE COMMENTS > > somefile.cpp:123 [View Inline] > - void foo(); > + void bar(); > > "Do you think this change is neccessary?" > > REPOSITORY > Foo Repo > > To: Addressees" > > Whereas with GitLab all you get is: > > Subject: foo-repo | Do something amazing (!12345) > "Project:Branches: someperson/foo-repo:featurebranch -> kde/foo-repo:master > > "Do you think this change is neccessary?" > > [View it on Gitlab]" So what you're saying here is, you'd like it to include the lines of code in question to provide context to the comment? > > > Most of the "modern" systems do this > > Doesn't mean it's better. When I review code I start reading it top to > bottom, commenting on every detail that I find fishy, convoluted, or > broken. Sometimes after having added a comment I find an explanation > further down, or I realize I have misread something or I just want to > rephrase a comment to be somewhat nicer, or I don't want to be overly > pedantic and remove a comment again, etc. > > > against the fact that people made comments on phabricator and then > never submitted them because you had to scroll to the bottom and press > the "send" button. > > Ideally, you'd be able to just "Add" with a banner saying you have "n > pending comments" or "Add and submit" for a one shot immediate comment. It sounds like you are after Merge Request Reviews (see https://about.gitlab.com/2018/10/22/gitlab-11-4-released/#merge-request-reviews) This is an Enterprise Edition feature of Gitlab and therefore not available on invent.kde.org, because per Community guidelines use of non-free software is not permitted. While we can potentially ask them whether they'd be willing to move that to Community Edition, we would have to put together a user story and some other bits and pieces around why it's highly impactful on our workflow (including examples). > > Cheers > Kai Uwe Regards, Ben
Re: Tipping the apple cart?
On Tue, Jul 2, 2019 at 6:42 PM Boudewijn Rempt 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
Re: Tipping the apple cart?
On Dienstag, 2. Juli 2019 09:08:44 CEST Kai Uwe Broulik wrote: > Doesn't mean it's better. When I review code I start reading it top to > bottom, commenting on every detail that I find fishy, convoluted, or > broken. Sometimes after having added a comment I find an explanation > further down, or I realize I have misread something or I just want to > rephrase a comment to be somewhat nicer, or I don't want to be overly > pedantic and remove a comment again, etc. This describes exactly my way of doing reviews. -- Regards Thomas Baumgart https://www.signal.org/ Signal, the better WhatsApp - The words GUESS and KNOW when used in the context of flying may produce entirely opposite results. - signature.asc Description: This is a digitally signed message part.
Re: Tipping the apple cart?
Hi, What are you missing? The description of the change (Review Board had that, Phabricator doesn't, so I got used to it, I guess...), the context of the comment (i.e. the code snippet a comment was added to), so I don't need to open GitLab to figure out what's going on. On Phabricator you get: Subject: D12345: Do something amazing "Foo added inline comments INLINE COMMENTS somefile.cpp:123 [View Inline] - void foo(); + void bar(); "Do you think this change is neccessary?" REPOSITORY Foo Repo To: Addressees" Whereas with GitLab all you get is: Subject: foo-repo | Do something amazing (!12345) "Project:Branches: someperson/foo-repo:featurebranch -> kde/foo-repo:master "Do you think this change is neccessary?" [View it on Gitlab]" > Most of the "modern" systems do this Doesn't mean it's better. When I review code I start reading it top to bottom, commenting on every detail that I find fishy, convoluted, or broken. Sometimes after having added a comment I find an explanation further down, or I realize I have misread something or I just want to rephrase a comment to be somewhat nicer, or I don't want to be overly pedantic and remove a comment again, etc. > against the fact that people made comments on phabricator and then never submitted them because you had to scroll to the bottom and press the "send" button. Ideally, you'd be able to just "Add" with a banner saying you have "n pending comments" or "Add and submit" for a one shot immediate comment. Cheers Kai Uwe
Re: Tipping the apple cart?
El dilluns, 1 de juliol de 2019, a les 9:42:34 CEST, Boudewijn Rempt va escriure: > On maandag 1 juli 2019 09:10:59 CEST Valorie Zimmerman wrote: > > > > This tells me that Gitlab can be worse, which is not surprising. > > > > And can it be better? Will some folks who have a good experience with this > > on Gitlab speak up? > > > > This is something that all of us want and need to know. > > > > 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) Or were you mostly getting patches sent as plain diffs uploaded to phabricator instead of by using arc? > * 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 > * gitlab is slow That's not the perception i have at all. > * 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. > * using the label system for approving a MR is cumbersome What does this mean? Cheers, Albert
Re: Tipping the apple cart?
El dilluns, 1 de juliol de 2019, a les 8:46:39 CEST, Kai Uwe Broulik va escriure: > Hi, > > > In our move to Gitlab, we can do better. > > Given Gitlab emails contain even less information and context than > Phabricator which themselves contained even less information and context > than Reviewboard back then, I don't see how this will change or improve > anything. What are you missing? > > > Phab sends out an email for every event and comment > > And Gitlab even unexpectedly submits the comments as soon as you close > the editor rather than in bulk as I would have expected from a proper > reviewing workflow. Most of the "modern" systems do this, i very much like this against the fact that people made comments on phabricator and then never submitted them because you had to scroll to the bottom and press the "send" button. Cheers, Albert > > Cheers > Kai Uwe > > > >
Re: Tipping the apple cart?
On maandag 1 juli 2019 09:10:59 CEST Valorie Zimmerman wrote: > > This tells me that Gitlab can be worse, which is not surprising. > > And can it be better? Will some folks who have a good experience with this > on Gitlab speak up? > > This is something that all of us want and need to know. > 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. * 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, and that means scrolling and hunting for a very small button. * I haven't managed to make Gitlab remember to show me the diffs side-by-side, though that seems to work for others * The code review tools are crap, with every little comment being a separate thing, as Kai noted. * gitlab is slow * it's much harder to follow my gsoc students who work in a fork instead of a branch, for some reason I could only enable email notifications for one out of four students. * you cannot have more than one reviewer for a MR * using the label system for approving a MR is cumbersome Good: * sometimes, the merge button works, and then that's nice. * the on-line editor is very handy for the docs.krita.org project. * gitlab is actively maintained My takeaway: Gitlab might be maintained, and phabricator not, but when it comes to making life easier for newcomers, it's not working (1). We can live with it, but it isn't a huge improvement. When it comes to email, phabricator worked better for me, but yes, sometimes I got too much mail. Now I don't get enough. Right now, my biggest email problem is bugs.kde.org, but that's because we get too many bug reports. -- https://www.krita.org (1) Which reminds me -- we ought to have a discussion on whether matrix actually achieved its goals of making life easier for newcomers. signature.asc Description: This is a digitally signed message part.
Re: Tipping the apple cart?
On Sun, Jun 30, 2019 at 11:47 PM Kai Uwe Broulik wrote: > Hi, > > > In our move to Gitlab, we can do better. > > Given Gitlab emails contain even less information and context than > Phabricator which themselves contained even less information and context > than Reviewboard back then, I don't see how this will change or improve > anything. > > > Phab sends out an email for every event and comment > > And Gitlab even unexpectedly submits the comments as soon as you close > the editor rather than in bulk as I would have expected from a proper > reviewing workflow. > > Cheers > Kai Uwe > Thanks, Kai. This tells me that Gitlab can be worse, which is not surprising. And can it be better? Will some folks who have a good experience with this on Gitlab speak up? This is something that all of us want and need to know. Valorie
Re: Tipping the apple cart?
Hi, > In our move to Gitlab, we can do better. Given Gitlab emails contain even less information and context than Phabricator which themselves contained even less information and context than Reviewboard back then, I don't see how this will change or improve anything. > Phab sends out an email for every event and comment And Gitlab even unexpectedly submits the comments as soon as you close the editor rather than in bulk as I would have expected from a proper reviewing workflow. Cheers Kai Uwe
