Tweaking merge request flow

Development
1

From discussion on !1509, some points came up:

  1. How to avoid very large merge requests?
  2. What is our merge request workflow?

I argued that splitting merge requests does not add a lot of value. I provided the following arguments:

  • A reviewer can choose to review only some of the patches in the merge requests. Many project that distribute patches on mailing lists do this and Gitlab has UI that allows this.
  • The reviewer could cherry-pick some patches and leave comments on the rest.
  • Actual effort for the reviewer is not reduced if merge request is split (it is reduced when patches are logically organized).
  • Testing effort is increased when merge requests are split.
  • When merge requests are split and they depend on one another, Gitlib anyway shows large changes for merge requests that depend on others. This gets complicated when there are multiple dependencies.
2

Splitting merge requests is not desirable, but we should be thinking about why merge requests are getting so big in the first place.

One reason I can see is that our GitLab issues are usually at an epic level and not broken down into individual stories. This ties back to us not having the bandwidth to play the business analyst role (Additional Roles for the project).