L1 Trigger Offline Software: requirements for submitting new L1 Trigger tags to integration builds

Goal of this page

This wiki page documents the procedure to be followed by the L1 trigger software developers when requesting the integration of new tags in the integration builds and release.

This page, as well as the linked pages, are under active restructuring.

Introduction

Before developing any CMSSW code for L1 trigger, any developer must read the CMSSW Developer's Guide in detail.

Requirements for submitting new L1 Trigger tags to integration builds

First, follow the procedure outlined in CMSSW Developer's Guide to develop the code. After the development is ready and tested, tag your package (CVS tag) and publish it in CMS Tag Collector according to the following publication recipe.

The integration in IBs or release by the release coordinator is done only at the request of the L1 trigger offline coordinator(s), so package administrators must ask the L1 trigger offline coordinator(s) explicitly for integration. Direct requests from package administrators are ignored by the release coordinator. The list of L2 offline coordinators for CMSSW packages is maintained in the Association Packages-L2s.

Tag must be published before asking the L1 trigger offline coordinator to ask for integration. If the administrator of the package is not available, please contact the L1 offline software coordinators, they have the right to publish any L1 trigger package.

For every new tag, published in TC, the administrator of the package sends to the L1 trigger offline software coordinator(s) a mail with:

• the detailed motivation for the new tag
• the description of the code changes (list of files changed, short explanation of the changes). No diffs between the tags is needed, this can be obtained by every developer.
• the relevant plots / numbers showing the situation before the code changes.
• the exact recipe to reproduce these plots / numbers
• the same plots after the code changes, proving that the bug is fixed or the improvement performed. If the bugs/improvements are revealed/visible in another subsystem, the involved subsystems must work together to produce the plots.
• the recipe to produce these plots, if not identical with the previous recipe - if identical, it must be mentioned
• the validation plots for the subsystem - every system must have a standard set of validation plots.
• the commands which were used to test the new tag(s) with cmsDriver on RelVal samples and on data
• the estimated effect on other L1 subsystems depending on this subsystems

The L1 software coordinator has to be able to reproduce the plots, check that the bug fix or the expected improvement is indeed performed and that no other subsystems are negatively affected. None of the above requirements is optional!

The reasons for these requirements are:

• after the data taking starts, we have to be able to quickly fix the possible (critical) bugs, to test the bugs properly and to deploy the tags online without significant data loss. For this, we should have in place a clear procedure, exercised well. We should also have the code and the tools to produce the relevant plots by independent developers. Whatever tests we will perform before deploying the software online, we can not exclude bugs revealed during data taking - and "reprocessing" the data is not an option for the L1/HLT trigger, if we fail to take them.

Review status

Responsible: Vasile Ghete