ROOT Team Meeting
Shift handover
DVS -> GP
Week went well, everything answered and assigned. Some intermittent failures, all reported. Hit in Ubuntu for ttree-evolution-make
. We might have to increase the timeout.
SH: I say we split it into more tests. It's invoking 20 ROOT macros and invoking them with different arguments. I can have look into splitting them (to be discussed further offline with PC).
Action items
Merging root
and roottest
Proposal of merging root
and roottest
after branching for 6.36. We had some consensus during last meeting, let's decide this meeting.
JH: In favor, but we need to decide when and where we put the tests, when is something a unittest and when does it go to roottest?
VV: Do we have an idea on the binary sizes?
DP: Yes, see status doc of last meeting.
VV: Are we comfortable merging all the dependencies and technologies? This could become problematic. Roottest also has a lot of duplication and leftovers from the ROOT 6 migration, which could make the repo much more messy. I'm not sure people are fully aware of what is in roottest
.
PC: In terms of the building and testing behaviour, there wouldn't be any change.
VV: I'm worried about dumping largely unmaintained code in the main repo.
PC: The CI is running all non-explicitly disabled (which are rare) tests.
VV: Half of the tests are not running throug CMake.
PC: We hope that merging it helps push forward the modernisation.
VV: I'm not against merging, but this is something I'm wary about.
DP: Very good points, it's true we are buying into putting code maybe not at the level we expect for ROOT in the main repo, but this way the barriers to remove and modernise this code is hopefully reduced. We don't have the resources to sanitize before porting, so I propose we do it the other way around.
An option would be to include roottest
as a git submodule.
VV: Also consider rootbench
.
ACTION VV: make a proposal for next meeting about the merging of rootbench
.
We decide to merge roottest
, exploring the option to add it as a git submodule and creating conditions for which tests should go where.
ROOT Internal documentation
CERN offers GitLab pages, so far this can be put behind SSO but not yet linked to a specific egroup (a ticket has been opened).
ACTION everyone: Take a look at the GitLab docs and give feedback.
Issues
We are at the same level as last year.
ACTION everyone: check out the issues assigned to you, see which ones still make sense, are related, etc. Discuss with DP in case of doubts.
VV: Do we have a way of prioritizing stuff beyond the experiments/PoW? There is a lot grey area.
DP: Start by looking at the issues you have, then we can decide the criteria to assign priorities. The assignee usually knows best what is important. We may not have a clear view on everything, in this case we should discuss with more people as well.
HiLO project introduction meeting
January 31st 9h15-12h30. Attendance is encouraged but not compulsory. The link to the meeting will be sent soon.
Suggestions and proposals
Make the ClassImp preprocessor macro a no-op to then remove it from ROOT
Proposal to turn into no-op for 6.36, remove in 6.38.
VV: We should issue a warning about the deprecation.
BB: Complete removal means people have to adapt their code.
DP: That's why we first deprecate and issue a warning.
GP: Is this something people were encouraged to use or something more internal?
BB: You could use it to generate documentation for THTML, I think people did this. THTML is going to go away in 6.36 anyways.
VV: When you say no-op, does that mean it's a no-op forever or just this one release?
DP: We make it a no-op until we romve it. Maybe removing in 6.38 already is a bit too aggressive. It won't be a no-op forever.
Remove PROOF from ROOT
Proposal to remove in 6.36. It has been deprecated since a long time, but there are still traces, e.g. in RooStats.
PC: Do we have alternatives in all places it's still used?
BB: Should ask Gerri if there are still some small experiments or something that still use it.
We mark all PROOF-related things for deprecation in 6.36, removing in 6.38 at the earliest.
JR: PROOFLite in RooStats has already been deprecated (broke it accidentally a few years ago and no one has complained).
VV: Is taking down all the posters part of the deprecation process?
DP: This has been set in motion.
Meeting summaries and plans
PPP
Stephan presented thread-safe histograms (Histo3D) for RDF. Discuss pros and cons of the implementation, leading to a proposal for an interface to be used by analysists. There are clear improvements to be had, but we need to reconvene with updates on both the implementation and interface to make sure it addresses all requirements.
I/O
Shortest I/O meeting in recent history. Almost all discussion happened during the week already.
Stats
Simulation based inference (ATLAS) set for next meeting.
Talked about general updates with RooFit devs, mostly HS3. People see this as an emergent standard, we have to lift our part of the weight. Discussed next steps. There is already a big list of publications using this standard. There is a risk when we evolve it that we break the published likelihoods. It's not in the PoW but maybe we should add the monitoring and regression of these likelihoods.
DP: Take a look at the CMS O&C week agenda, we could go there and discuss.
Also discussed what to do with RooFit AD. Want to write a blog post for February about the 10x workspace speedup. There will be a toy demo workspace.
PoW presentation
For the people that couldn't attend the SFT meeting, tomorrow.
LIM
Very short, nothing reported.
ML4EP
Nothing relevant to report.
Topics
Upcoming experiment weeks
We have a good package of slides from conferences and other talks. We should present them at these weeks to make ourselves visible. We have been invited to present to Alice, in May. CMS is coming soon. The agenda is already packed but we will see if there's a slot. ATLAS has been contacted, LHCb will be contacted this week.
Everyone is invited and encouraged to propose something to present.
GSoC projects
One project, from GP. Needs some final polishes but then it can be submitted.
CMake find_python_module
Follow-up of the Stacks presentation from recently.
Used to get test failures for tests depending on missing Python packages. SH presents a new to detect these missing packages at config time. These tests are now shown as disabled. After installing these packages, some action is needed to then re-enable them (see slides).
Round-table
RNTuple need to leave, meeting ran long so we exceptionally skip this point.