Skip to content

Figure out a workflow for merge requests that needs modifications to be done by the maintainer

Background:

There is an use case that is missing currently, or at least we didn't find a way to solve it smoothly.

It's when a merge request is "old" and needs some small adjustments to be made by the maintainer. For example fix ups of commits, adjustment to some commit message, or some small code adjustment on top of the merge request. In those cases, either the changes are small enough that the maintainer doesn't bother the contributor with them and do the changes directly, or the maintainer request the changes but the contributor doesn't answer anymore. In both cases the issue is that the maintainer needs to modify part of the merge request.

This could be split in two cases, one for modifying actual commits inside the merge requests and another one for fixups on top of some merge request. However it looks like the solution could be the same, so worth to explore both cases at once.

This use case is quite common in our free software organization, where the majority are community contributors and there is no immediate synchronization between contributor and maintainer.

Existing solutions

In Bugzilla, since it's not based on branches or merge request, the common workflows are two:

  • Modify the patch that needs modification and upload the new set of patches (to preserve order) to the bug report.
  • Create a set of patches on top of the other patches and upload those to the bug report.

Possible solutions for GitLab

  • Allow collaboration of code in merge requests from different people. This sounds like a good solution, but at the same time I'm not sure how it would look like and the complexity of it.
  • Allow to create a merge request on top of another merge request. So this would address the use case for fixups on top of an existing set of commits. However you would have two merge requests, when the discussion, etc. should probably happen in only one.
  • Allow to push to the branch associated to the merge request. This is what GitHub does, although more like a hidden feature given that is quite dangerous. Although the contributors needs to set on a setting and there are few safety measures, I have the feeling this is probably something that better to avoid.
  • Allow to select a different branch associated with a merge request. This one is quite simple, and would address also most of the use cases. I guess there will be some UX corner cases with this approach, but probably nothing major. Personally, I see this one as the best choice with the smallest complexity code and UI wise (and seems doing this is already possible when the original source branch is deleted).
Edited by Carlos Soriano