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

Reply via email to