[gmx-developers] updating merge requests

[Eric Irrgang]

Hello Contributors and Reviewers,

In keeping with the theme from the telco on finding effective GitLab practices (ref https://gitlab.com/gromacs/gromacs/-/wikis/home#gitlab-workflow-basics and https://gitlab.com/gromacs/gromacs/-/issues/3472), here's another tip that may reduce review overhead:

Don't believe GitLab when it says "Rebase the source branch onto the target branch or merge target branch into source branch to allow this merge request to be merged."

Or, rather, take it with a grain of salt.*

Instead, try to only update the source branch if it is truly necessary to account for non-trivial upstream changes.

Once a merge request has the required approvals (2, including at least one core developer), a GitLab developer with Maintainer privileges can start the automated process that performs more automated testing and queues the submission to be merged. If necessary, the Maintainer can click Rebase and then immediately trigger the merge train (which will ultimately result in deleting the source branch).

Note that even once this process has started, the GitLab warning and tempting green Rebase button may (re)appear on the merge request page, but I urge you, Dear Contributor, do not be tricked!

However, Dear Maintainers, please take note!

A merge train you think you have triggered may be canceled in the 20 to 50 minutes that  may elapse while pipelines are running if any other merges hit the target branch in the mean time. You will then have to click Rebase and start the merge train AGAIN! In my experience, GitLab will not send a notification if it cancels the merge under these circumstances.

Therefore, if you click Rebase for someone else's branch and may not be able to confirm that the merge train succeeds, please leave a comment in the merge request to clarify the status of the merge request / the reason for the rebase, and whether you will be following up or whether another Maintainer should finish what you started.

*
Rebasing a merge request source branch that is still under review (and potential modification) reduces our ability to collaborate effectively. Alternatively, adding merge requests (just because the source branch is behind master) creates complexity, triggers CI testing pipelines, and may invalidate existing approvals, delaying the review process further.

I have not noticed whether MR approvals are invalidated by pushing a merge commit for upstream changes. Has anyone else noticed?