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
