Document ActivityRegistry signals

[makortel]

PR description:

This PR adds a README.md file documenting the ActivityRegistry signals

Resolves cms-sw/framework-team#747

PR validation:

None

[cmsbuild]

cms-bot internal usage

[makortel]

@Dr15Jones @wddgit Could you take a look?

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-51277/49886

[cmsbuild]

A new Pull Request was created by @makortel for master.

It involves the following packages:

• FWCore/ServiceRegistry (core)

@Dr15Jones, @cmsbuild, @makortel, @smuzaffar can you please review it and eventually sign? Thanks.
@fwyzard, @wddgit this is something you requested to watch as well.
@ftenchini, @mandrenguyen, @sextonkennedy you are the release manager for this.

cms-bot commands are listed here

[wddgit]

I did some work related to making the behavior after exceptions consistent across begin and end transitions in 2024. That behavior was documented here:

https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideExceptionsInBeginEndTransitions

Is the information on that 2024 TWIKI page still valid? Or did this behavior change? If I go through the list carefully checking, should I comment if they are not consistent or assume that changes are intentional? I didn't do that, at least not yet.

Is the new page meant to complement that old page? Or is it meant to replace it and we no longer maintain the old page? I would like to keep that old page in existence so I could still access it. But if it is not valid or not being maintained, then I could put a comment to that effect on the top of the page. I could also add a link to this new page on the TWIKI. It would help me at least. We could also update that page if we decide to maintain it if it is necessary.

Are we headed to a day when the TWIKI is shutdown completely?

There is also an older TWIKI page. We could edit that one also. Add a link to the new page in GitHub and delete the information that is both wrong and duplicates the new documentation.

https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideEDMServiceDocWriting

[makortel]

I did some work related to making the behavior after exceptions consistent across begin and end transitions in 2024. That behavior was documented here:

https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideExceptionsInBeginEndTransitions

Is the information on that 2024 TWIKI page still valid? Or did this behavior change?

This behavior should still be valid. Or at least we did not intentionally change it.

If I go through the list carefully checking, should I comment if they are not consistent or assume that changes are intentional? I didn't do that, at least not yet.

I think it would be good have another set of eyes going through the list carefully, and comment inconsistencies. I have went through the code a few times, but could have mistakes.

Is the new page meant to complement that old page? Or is it meant to replace it and we no longer maintain the old page?

This README and the twiki above are complementary. This README tries to be strictly about the behavior of Pre and Post signals around one transition (covering more signals than the twiki), and not about the behavior of Begin and End transitions. There is some overlap of course. I should probably add a link to the https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideExceptionsInBeginEndTransitions page "for more information on Begin and End transition behavior).

Are we headed to a day when the TWIKI is shutdown completely?

Maybe eventually but there is no set schedule at the moment from CMS/CERN side.

There is also an older TWIKI page. We could edit that one also. Add a link to the new page in GitHub and delete the information that is both wrong and duplicates the new documentation.

https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideEDMServiceDocWriting

I think that would be a good idea. This README is really a replacement for the (outdated) signal table there, and trying to provide more useful information about the signals.

[Dr15Jones]

I think it might be better to organize these by the grouping them in the time order that they are likely to be called in. I.e. group construction/job setup first, then group by calling order within the processing loop.

[makortel]

I agree. I also want to keep the order in README and in the header the same, so the order in the header should be changed as well.