Skip to content

CR process

@lecompte and @fevold discussed in issue #1 how the CR process should look like. Let's use this separate issue to discuss that in detail.

Our view is that we should try to use Gitlab to improve the CR process and to make it more convenient. Especially, we don't think that we should toggle between Word and Gitlab when preparing/commenting/discussing/approving CRs. CRs and the handling thereof should happen in Gitlab.

To @lecompte's question regarding the cover page: Our traditional "CRs"had a "cover page" and the actual "CR body". In Gitlab ...

  • CR body: the changes you make and commit in the git branch
  • Cover Page: The merge request that you fill in on the Gitlab web-page.

As @heoyo mentioned, the Gitlab settings should preferably enforce setting necessary meta data on the merge request in Gitlab. Things like the targeted Release, the WI code and the CR type can be reflected by tags. Searching and filtering the list of merge requests by those is convenient. It would become much easier for everyone to filter a list of CRs that you intend to review or of all CRs for a certain WI.

Currently, anyone can "approve" a merge request in the trial repo. One can even merge it without such approval. In the actual repository approval must be a mandatory prerequisite for merging onto official branches (e.g. main, release). A useful setting could be that only chair-persons and MCC can give approval. And maybe one should require that a CR (merge request) got approval from one chair persons and one MCC person.

As @lecompte noticed, a merge request refers to a branch which will typically contain several commits in time domain. This is similar (but easier) than making revisions of a traditional CR, which occurs in a separate file. That made it difficult to compare revisions of CRs and to check whether all comments had been addressed. In Gitlab a reviewer can compare the differences of the latest commit to the main branch... or any other two versions of the CR to each other.

When agreeing a CR during a discussion and when ultimately approving it (by chair/MCC during plenary), it should also be noticed which commit (version) is being approved. But of course, small changes may still need to be done (by MCC) upon merging the CR into the main branch to resolve potential collisions. Also this will be visible in the commit history of the merge request.

The exact details require of course more discussion and trials. But the Gitlab platform seems to offer plenty of tools and settings that could greatly simplify our ways of working.