Reflecting PPD new groups in cmssw signatures

[vlimant]

I open this issue so that we work towards changing all categories related to ppd, to match better the restructuring that happened in 2025 and that will live on.

We currently have:

• alca
• db
• dqm
• pdmv

matching somehow PPD original structure while the L2 structure does not totally reflects this any longer. We are shifting some of the signatures to the PPD technical support team, as such.

Things to be discussed to harmonise things for CMS

• Some of the "db" related items could be considered as "core" ; as "this is the framework to consume calibrations in cmssw".
• Some of the "alca" related items could be considered as "reconstruction" ; as other configurations and such.
• Some of the "dqm" related items could be considered as "core" ; as "this is the framework to produce monitoring in cmssw".
• Some of the "dqm" related items could be considered as "reconstruction, the same way some dqm for xpog are signed by xpog ; as "monitoring strategy for reconstruction quantities"

maybe people have already thought of how these should look like for phase 2.

Code/repo that would needs sign-off from PPD are:

• the pdmv category can trivially be mapped to Offline Validation L2 area (validation) and Realtime Dataset L2 (skims) could be rename
• tier0/skims related code/configuration
• code/configuration that drives conditions derivation (PCL/MRH/...)
• code/configuration for monitoring clients

this is not an exhaustive list but initial thoughts that we need to work on and come up with a coherent organisation of signatures for PPD related matters.

[cmsbuild]

cms-bot internal usage

[cmsbuild]

A new Issue was created by @vlimant.

@Dr15Jones, @ftenchini, @makortel, @mandrenguyen, @sextonkennedy, @smuzaffar can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[makortel]

• Some of the "db" related items could be considered as "core" ; as "this is the framework to consume calibrations in cmssw".
• Some of the "dqm" related items could be considered as "core" ; as "this is the framework to produce monitoring in cmssw".

I am very much against in taking responsibility of code that was developed not following the recommendations of core.

[makortel]

@stlammel @srimanob

[makortel]

@cms-sw/core-l2 @cms-sw/reconstruction-l2

[vlimant]

@makortel ; I would actually agree with you, and actually we should think how to migrate/evolve db and dqm to a codebase that follows recommendations from core ; I was under the impression that things were not too orthogonal, as there has been OK interaction of alca/dqm with core.
LS3 and phase2 is our chance to move to sustainable and reliable software for these functionalities

[jfernan2]

@vlimant since signing so far is organized following cmssw package names (i.e. WhatEver/WhatEver ) as defined in the categories file, how do you plan to organize it without moving things around? Thanks

[srimanob]

I find the current ticket quite unclear, and it gives the impression that all infrastructure-related code would be moved under O&C responsibility. At the moment, all (or at least most) of this code is not maintained by the O&C area. The PPD restructuring in 2025 did not include a transfer of responsibility to O&C. My preference would therefore be to first organise and clarify this within PPD itself, before considering any broader changes. I would also like to avoid a situation where responsibility for maintaining and developing infrastructure is implicitly shifted to O&C without a high-level discussion at the collaboration level, as this has direct implications for both person-power and budget.

I would propose not to continue this discussion on Git. Instead, it would be better to bring it directly to a meeting for a focused discussion. We may start by PPD first present the current System/Subsystem of CMSSW, together with a concrete proposal for what should change. This would be much clearer than referring in general terms to “some” components or responsibilities.

[vlimant]

@vlimant since signing so far is organized following cmssw package names (i.e. WhatEver/WhatEver ) as defined in the categories file, how do you plan to organize it without moving things around? Thanks

the package names are already doing some separation, to a large extent, and there's a bit of work to figure out what is what.

[vlimant]

As you have noticed, this is an issue (discussion) and not a pull request (concrete implementation), and I intended it as such, with discussion on how categories are organised within cms code base.
This was intended also intended as a start of a discussion on reorganising things for the best, and I was not expecting that you'd recommend a unilateral proposal from PPD on how things could get done. And I'd rather not do it this way.

[srimanob]

I would like to avoid situation of deciding something that move effort from one area to other area without discussion in the management level.