Tipping the apple cart?

[Nate Graham]

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