Skip to content

Merge Review Shifter

Introduction

This page contains information about the software review process in ATLAS. It describes the tasks of merge request review shifters and provides some guidance as well as hints for common situations/problems. It is assumed that you are familiar with the general workflow for ATLAS software development as summarised in the Workflow Quick Reference. Furthermore, a solid knowledge of the C++ and Python programming language is mandatory. An overview of the ATLAS coding conventions and style guidelines (general C++ and Athena classes) is desirable.

Shifter roles

For every working day, there are two level-1 and two level-2 shifters on shift. Ideally, they work in different time zones (e.g. CERN and US) to provide developers from all timezones with a timely review of their merge requests. Please note that the shift times indicated in the OTP system are CERN times and may deviate from the actual shift times.

The current shift crew can be found on the OTP S&C Shift Crew page.

Level-1 shifter

As a level-1 shifter you are expected to have a thorough understanding of the C++ language and some basic knowledge about Python. You should be able to check the formal code requirements listed below as well as the criteria for good documentation and the adherence to the ATLAS coding conventions and style guidelines (general C++ and Athena classes).

If you feel confident about reviewing the changes go ahead. If the changes are more substantial and require a deeper understanding of the Athena code structure/workflows, you can escalate this MR to the level-2 shifter for review (but please make sure you explain why, i.e. write "Escalating to L2, because I'm not sure whether there is a memory leak in the bar() method of Foo.cxx" or "Escalating to L2 because Foo.cxx has been completely re-written"). If you are in doubt, you can always pass a MR on to the next level, but try to guide the next shifter to save them from re-reading everything.

Level-2 shifter

In addition to the knowledge required by the level-1 shifts, you have some experience with the usage and design of the Athena software and are able to comment on structural changes. A certain level of proficiency in git is helpful as well.

Your main task is the review of MRs which were escalated to level-2 by the level-1 shifters. In case that these changes require dedicated expertise in a specific software domain, you could always include an expert in the discussion (using the @username mentioning feature in GitLab, see the FAQ for a list of contact persons). Otherwise, you are expected to approve the MR or iterate with the developer on the proposed changes.

Reminder: review process

Your task as review shifter is to review the proposed changes to the ATLAS software and, if necessary, iterate with the developer(s) until these changes fulfil certain criteria outlined below. The outcome of the review process is the recommendation for the release coordinators to accept this merge request (or not). It is up to the release coordinators to finally accept or reject a merge request.

Upon creation merge requests are labelled automatically by the CI system. The labels relevant for the review process are:

  • review-pending-level-1: The review process has started and a level-1 shifter should have a look at this MR.
  • review-pending-level-2: The review process is with the level-2 shifter for further clarification/review.
  • review-pending-expert: The advice of a software domain expert on the proposed changes is needed.
  • review-user-action-required: The review shifters raised some comments which should be addressed by the developer(s).
  • review-approved: This MR is approved by the review shifters and is recommended to be accepted by the release coordinators.

For MRs that affect packages in the analysis releases there is an extra set of labels that are relevant for the analysis release shifter:

  • analysis-review-required: This MR affects packages in the analysis release and should be reviewed by the analysis release shifter.
  • analysis-review-expert: This MR was manually tagged as requiring review by an expert from the analysis domain.
  • analysis-review-approved: The analysis release shifter has looked at this MR and confirmed that there are no analysis specific issues in the MR that need to be resolved. There may still be general software quality issues with this MR and the shifters should go through their regular merge review process for approval.

For certain trigger menu changes, the MR will be labeled with menu-review-required. In this case the menu-review-approved will have to be applied by one of the trigger menu coordinators. They get notified automatically. If needed the trigger menu coordinators for 24.0 and the trigger menu coordinators for main can be found in Glance.

Once you are done with your part of the review process you update the review label as appropriate. In case further changes are required (not approved), add a comment with your findings. In case of approval without further comments, changing the label is sufficient.

Note

Your shifter review, the analysis-specific and menu-specific review are independent and should proceed in parallel. The release coordinator will ensure full approval before merging where necessary.

Question

GitLab has its own approval mechanism, which we are not using in our standard review workflow. Therefore you do not need to click the "Approve" button at the top of the MR.

Merge Request Workflow

Special case: output changing merge requests

Merge requests that change the output of the reconstruction are flagged by the CI system with a dedicated label and the CI will be marked as failed.

Depending on which output changed, take the following actions:

xyz-output-changed: The reconstruction output changed for one or multiple output types (e.g. !69732).

  • If the changes are intentional (check the MR description or ask the developer):
    • Add RC Attention Required label.
    • References can only be updated by RC (developers should not touch the reference files) after agreement from Reco or Software coordinators for the main branch, from PROC for frozen branches, from Simulation coordinators for Simulation and from AMG for Derivations.
      • See the release coordinator guidelines for more information about the procedure
    • Since the reference update is a delicate procedure it is advantageous for the code to be fully reviewed before. Proceed therefore with the code review as normal, ignoring the reference failures in CI but not any other ones. The "output-changed" labels remain on the MR.
  • If the changes are not intentional, apply the review-user-action-required label and remove all the "output-changed" labels. The developer needs to fix the MR until it passes without output changes.

changes-trigger-counts: The number of accepted events for one or more triggers changed (e.g. !70822).

  • If a MR changes the counts of any trigger without updating the reference files, this will cause the CI to fail the MC trigger CI test, data trigger CI test, or both of these. The MR should be flagged review-user-action-required if this happens, and the MR author must then update the references to proceed (or undo the code change causing the trigger count difference).
  • The CI logs print the diff with respect to the current in-repository references to make the updating of the references easier.
  • The act of modifying the references will cause the changes-trigger-counts label to be applied.
  • As the reviewer, you should use your judgement if the count changes shown via the updates to the reference files are reasonable and expected, given the intent of the MR. For example, if the MR modifies the TriggerMenuMT package then it is very likely the changes are directly related to the MR's goals.
  • You should ask the MR author for additional clarification if you are not satisfied that the changes are reasonable and expected.

For both cases, you can proceed with your usual code review before, or in parallel with, the reference file updates, but the final review-approved label should only be applied once the CI passes.

Special case: sweeps

Sweeps are merge requests that merge changes from one release branch to another (e.g. 24.0 to main). There are two types of sweeps:

  1. Automatic sweeps of one single MRs initiated by the CI system (e.g. atlas/athena!66591)
  2. Manual periodic merges done by the release coordinator (e.g. atlas/athena!71857)

As the code changes have already been reviewed when merged into the original branch, no further code review is required. If the CI succeeds, you can immediately approve the MR. In case of failure, apply the review-user-action-required label and in case of an automatic sweep, tag the author of the original MR that is listed in the description of the sweep MR.

What should you do...

...when you start the shift

  • Join the Mattermost atlassoftware team then join the shifter channel, which is used for communication among the shifters and experts. Say Hello and check whether there were any recent discussions (e.g. infrastructure problems or other news).
  • Check if there have been updates to these shifter instructions since your last shift (see the page history).
  • Check the CI Status Board to familiarize yourself of known problems affecting the CI.
  • Check on long-standing open merge requests. MRs inactive for >3 months should simply be closed. Do not ping older MRs unnecessarily, as this will make them appear active. Instead add a comment saying "Closed after 3 months of inactivity, as per shifter rules." and then close the MR.

...during your shift

  • Follow discussions in the Mattermost shifter channel.
  • Frequently check for newly created/updated merge requests and review them. First take care of MRs labeled as urgent. Then review MRs in reverse chronological order (from oldest to newest, use the "Updated date" sorting) for review-pending-level-1 or review-pending-level-2 depending on your shift. Review them according to the instructions below.
  • Watch out for failed CI jobs. In case they failed due to a transient infrastructure problem, restart them (as explained in the FAQ). If you are unsure about the source of the failure, do not restart the job but reach out to the developer and/or the Mattermost channel. Excessive restarting of CI jobs leads to unnecessary load on the CI system.
  • The CI Status Board lists known problems affecting the CI system. To report new issues on the infrastructure open an ATLINFR Jira ticket. For other problems open a ticket in the Core SW, Reconstruction or Trigger Jira project. If you assign the CI label to the issue it will appear in the status board.
  • Check the MR problems page for some suggested actions to take to make sure merge requests don't slip through the cracks. In particular try to check at least once during your shift whether there are any MRs in the "invisible" and "unlabelled" sections and add review labels to the affected MRs if there are.

...at the end of your shift

  • Say Goodbye in the Mattermost channel and mention any problems/open issues that may be of interest to the next shifters.

Checklist for reviewing a merge request

The review should encompass criteria from the following categories, ordered by importance:

  1. Code functionality
  2. Documentation
  3. ATLAS coding conventions and style guidelines

After the review and possible iterations with the developer, please make sure that all discussions are marked as resolved before approving a merge request.

Code functionality

  • Did the CI job run successfully?

    A successful build is indicated by:

    ✅ CI Result SUCCESS and ✅ Athena: number of compilation errors 0, warnings 0

    whereas a job with problems is shown as:

    ❌ CI Result FAILURE or ⚠️ Athena: number of compilation errors 0, warnings 8

    The detailed result table will tell you at what stage of the job (e.g. make or tests) the job failed.

    For a MR to be approved there should be no test failures and no compilation errors or warnings. In case warnings are clearly unrelated to the changes in the MR (see the build logs) they can be ignored.

  • In case of failed CI jobs, have a quick look to try to diagnose the issue and provide some guidance to the developer. In general, it is the responsibility of the developers to ensure that their MRs pass the CI system. However, new developers may not be familiar with the workflow and help is much appreciated.

  • In case there are test failures, they are most likely due to the changes made in the MR and need to be addressed. Sometimes it can happen that a unrelated unit test fails. If the problem is listed on the CI Status Board you can proceed with the review/approval without restarting the CI. If the problem is not listed, consult with the developer or on the shifter channel.
  • Do not approve incomplete MRs! Developers sometimes make MRs halfway through a bug fix/feature implementation and want this to be merged in (for various reasons). In this case, please tell the developers to mark the MR as Draft and request it only once it is final (i.e. it builds locally and has been tested).

Specific things to look out for:

  • Does the code logic look correct?
    • Watch out for logical comparisons in the wrong place, e.g. std::abs(some_value > 2)!
    • Watch out for single block statements and misleading indentation!
  • Does the code dynamically allocate memory?
    • Could memory allocation via new be replaced by stack variables or smart pointers (e.g. std::unique_ptr)?
    • If the interface requires bare pointers, are they deleted and is the ownership clearly documented? Suggest change to a std::unique_ptr where appropriate!
  • Are any strings, vectors or other large objects passed by value instead of reference?
  • Are there any uninitialised variables? Declare variables only when they are actually needed.
  • No printing to std::cout/cerr - use the Athena logging service through the message macros. Unit tests are exempt from this rule.
  • The hardcoding of conditions folder tags in the python configuration, rather than taking the version from the global conditions tag, is discouraged. Therefore, use of the addOverride(...) function (defined in IOVDbSvcConfig.py) should be queried (as this can be used to hard-code conditions tags).
  • UTF8 potentially allows developers to use non-ASCII characters in merge requests. However this can lead to very hard to read code, and could cause various other problems. So:
    • non-ASCII characters are forbidden in identifiers, that is function, class and variable names, irrespective of the language i.e. this applies to C++, but also to python, bash etc.
    • non-ASCII characters are permitted in log messages and comments, provided they are reasonable and improve readability (for example, writing Δϕ instead of deltaPhi, or μ instead of muon, or to correctly write someone's name).
  • The following files should not enter the git repository:
    • ChangeLog files as these create unnecessary merge conflicts
    • large binary blobs -- it's a code repository.
    • Source files that are > 100kB should probably be split.
  • If you notice that a commit is changing file permissions, please query this with the author. These could be deliberate, but more frequently this is by mistake.

Documentation

Functional code is important and so is maintainability. Therefore, please check that:

  • Is the MR description (and/or commit messages) informative and follows the guidelines, i.e. it has
    • a concise justification why the changes are necessary
    • possible implications/side effects for other parts of the code
    • link(s) to related JIRA tickets if applicable
  • For MRs with multiple commits, ideally each commit should be properly documented and the commit history should be clean. However, as we "squash" all MRs into one commit (unless the developer explicitly decided otherwise) the MR description should serve as the main documentation.
  • Auxiliary information (e.g. "Jane, can you comment on it?") should be added as comments.
  • Does the code have appropriate comments and Doxygen documentation?
  • Are the log messages useful and not too verbose?
  • Copyright statements:
    • Modifications, deletions or additions to the ATLAS copyright statement are a complete no-go. The correct copyright statement must read: 
      Copyright (C) 2002-2026 CERN for the benefit of the ATLAS collaboration
    • Make sure that newly added source code files (easily identifiable from the Changes tab) have this copyright statement! Trivial job option fragments and boilerplate files are exempt from this rule, usually found in share or in src/components.
    • The end year is not important as the copyright only expires many decades after the creation of the works. For you as a shifter this means you should only ask for an update if there are significant copyrightable changes and the end date lags by 10 or more years, or you are asking for other changes anyway.

ATLAS coding conventions and style guidelines

Sticking to the ATLAS guidelines for software development (general C++ and Athena classes) helps other people to understand your code better and faster and, thus, facilitates maintainability. As such, the following points should be mentioned as minor suggestions. Since these guidelines have not been followed too closely in the past, you will see a lot of code which could be improved. Some of it may not even been touched by the actual changes. This is a delicate topic and some developers may react huffish to these kind of comments. Therefore, the general strategy is to aim for gradual improvement than drastic changes:

  • be kind (even more polite than you usually are ;-))
  • suggest rather than request changes
  • focus on things which were touched (of course, you can still mention that your comments may still apply to other parts of the code)
  • in case the developer rigidly and repeatedly refuses to implement your suggestions, create a JIRA ticket with your findings (so that they can be addressed later) and approve the MR

FAQ

  • How should developers update their merge request?
    If developers would like to update their code changes (either based on feedback from the review shifters or for any other reason), they can simply add further commits to the source branch. The MR will be updated automatically. Since a new CI job is run on every update of the source branch, developers are encouraged to push only working sets of commits instead of pushing each commit individually. This helps reducing the load on the CI system and therefore gives the developers faster turn-around times.
    If developers want to update only the MR title, description or labels, this can all be done directly from the GitLab MR page using the Edit button in the top-right corner.

  • How do developers notify review shifters after they responded to comments?
    If a MR has been flagged as review-user-action-required, developers should answer and address the questions raised by the review shifters. In case they updated the source branch, a new CI job will reset the review label to review-pending-level-1 automatically. In the event that no code changes were required, developers should manually change the label back to review-pending-level-1 or review-pending-level-2 as appropriate.

  • Who should resolve discussions?
    Before a MR is approved, all discussions should be marked as resolved. In general, a discussion should be resolved by the initiator (which usually is the review shifter). If developers agree with a comment and they have implemented the requested change in an update of the MR, they should briefly state in the discussion that this suggestion was implemented and resolve this discussion directly.

  • How can I access atlas-sit-ci.cern.ch remotely?
    The Jenkins server is running at the above address which is only reachable from inside the CERN firewall due to security restrictions for our build machines. In order to access this machine which provides access to all the detailed Jenkins log files, you need use port forwarding or SSH tunneling (see here for instructions).

  • How to restart a CI job after a infrastructure failure?
    A CI job should only be restarted if there is a known temporary problem or in case the MR depends on another MR that has been merged in the meantime and updated CI results are required. To restart the CI write the following comment in the MR discussion:

    Jenkins please retry a build

  • Where are the per-package build log files?
    Once the CI job has finished, the ATLAS robot publishes a summary table with a link to the CI monitor view. On this page you can find the full log files for all stages of the CI job including the per-package build log files and the results of the individual CI and unit tests.

  • Are Draft/WIP merge requests processed by the CI system?
    No, merge requests marked as Draft are not processed by the CI system. But the CI can be triggered manually as described in FAQ 5. However, once the CI finishes the system will not add a review label (as of ATLINFR-2754) since the Draft status indicates that the change is not yet ready for review.

  • Which expert to contact?
    The CI system should automatically tag relevant experts using an expert watch list. If no one is listed as a watcher (or if this list seems out of date), please contact someone from the relevant software domain to fix it. A list of contacts for various software domains (and CP groups) can be found here. Make sure that you mention the expert in the GitLab using the @username notation.

  • Why is the pipeline status for a merge request not displayed?
    Make sure that atlasbot was added as a developer to the source fork as described here. In case you spot a MR where the source repository is lacking atlasbot as a member, you should make a comment like the one below

    @username, please add `atlasbot` as a developer to your fork as described
[here](https://atlas-software.docs.cern.ch/athena/git/gitlab-fork/#add-your-friendly-build-bot)
so that the CI pipeline status is displayed correctly for future MRs.

  • What is a reasonable number of changed files in one MR?
    This question is hard to answer in general. Replacing endreq by endmsg in the whole code base would be a valid MR touching thousands of files. It is not the number of changes (or modified files) which should be important but rather whether those changes are all logically related. The goal is that each MR addresses one issue (e.g. one JIRA ticket) and does not contain multiple unrelated updates. If this requires changes to many files, it does not mean it is a bad request. You may as well see it from a different perspective: A merge request is the smallest entity on release level which can be undone easily in case there is a problem. So if a merge request contains multiple changes where there is the hypothetical possibility that you only want to undo certain parts if a bug is discovered, it is better to split the merge request.

  • How can I cancel a running pipeline?
    Since our CI pipelines run in Jenkins, the GitLab UI cannot be used to cancel pipelines. Instead one has to use the Jenkins web interface. However, since aborting pipelines mid-job can lead to corrupted build nodes, we generally advise against canceling any CI jobs. For the rare cases where this is needed (e.g. a user triggers a large number of CI jobs), the release coordinator should be informed who can cancel the jobs and perform a node cleanup if problems arise.

Feedback

Please feel free to open an issue or improve the documentation yourself by following our contribution guide. For problems with the CI system open a ticket in ATLINFR.