Choose timezone
Your profile timezone:
ROOT Team Meeting
ROOT Team Meeting
Zoom Meeting ID
63815034196
Host
Danilo Piparo
Alternative host
Philippe Canal
Useful links
Join via phone
Zoom URL
### News
- Everyone should update the POW, for Danilo to present at the LHCC review
- Regarding CHEP
- The input we have so far is that everyone who got accepted will travel and we can start making our travel arrangements
- We will have internal rehearsals for ROOT, not with everybody but within smaller committees, Danilo will circulate the date and infos
## Proposals
- Danilo: We didn't have a security policy so far, I added a minimal one on GitHub https://github.com/root-project/root?tab=security-ov-file
- Stephan: this would increase our spam because we couldn't find this address online before no?
- Danilo: it was on the website
- Jakob + Stephan: remove the word "reasonable"
- We're getting a lot of AI contributions and comments, I wonder whether you think we need an AI policy, or if you had an experience
- Vipul: I believe we need an AI policy, but reading that it feels like we don't want anyone to use any LLm at all, we should word it saying "you are allowed to use llms but you're responsible for the code and understand it, you shouldn't be a middleman between the reviewer and the llm"
- Aaron: on llvm they say they don't want "unwanted generated comment" and that is helpful, a PR should be minimal and not have a lot of noise and formatting around it
- Stephan: Same thing goes for the very long PR description, if you
- Jakob: I wonder if our template is not counter productive here, whether we should keep it blank
- Marta: Maybe we should keep it internally
- Jakob: I don't remember the last time i used the template
- Danilo: i can make a proposal for a new template
- Jakob: i think any template is food for the llm
- Aaron: should we have a "claude.md" file or similar that states instructions for the llm such as "don't format the code, don't write long descriptions, etc."
- Danilo: copyright issues?
- Aaron at least if they take the code from stack overflow you could say it was "taken from..." but that's not what happens with llms
- Jonas: adding a comment saying "i took it from.." doesn't solve your legal issues
- Aaron: yes but at least the reviewer knows
- Danilo: do you think it's an advantage to have an llm policy or not?
- Stephan: you can close PRs by referring to the policy which would save time
- Jakob: I would call it guidelines
- Aaron: can we state "no agent opened PRs"
- Danilo: in root we have built-ins, I spent some time difuring out our externals and how we were dealing with them, they are a bit scattered in the codebase, and I came up with this list https://docs.google.com/spreadsheets/d/1hAaRtezIUZxn8F0GlrPGWEEiSbhW9Ili587WdpObDKo/edit?gid=0#gid=0, these externals have some advantages: our comfort and the comfort of users, but they also come with some risk, for example we have already been hit by a CVE and this encouraged some people to use versions of ROOT older than 6.36, it's a good time to review what we have, it is also my personal opinion that the least "vendored" builtins the better
- Danilo: we could continue what we are doing (conservative position), we could go for the other extreme which is not to rely on any builtins (internal or not) and we expect the users to prepare those dependencies for ROOT, which would be uncomfortable for users who would have a big list of dependencies to check for, making root less usable
- Jakob: in my opinion we should clean this up, it's clear that the cases are different, there are some low hanging fruits which made sense in the past but not anymore, liek the compressions algorithms I would just pick those up from the system, I don't think on linux we lose much but we would have to see for mac and windows, for many good reasons I think this table should be small and manageable
- Bertrand: what if you update some library independently and with the upgrade it is no longer compatible with root
- Jakob: we tests for as much as we cna and if it doesn't work the tuff luck!
- stephan: usually no matter how many upgrades of the package, they still relatively work the same
- Bertrand: that might eb the case on linux, not for windows and mac
- vipul: i believe this can be done gradually, as in whatever we don't ship with our binary we pick it up from the system and if not found we download it
- Jonas/ danilo: it kinda already works this way, if the version you find is older you download the version you need
- Jakob: i think if we do this we still have to manage all the build configuration complications
- Danilo: i see an advantage in moving to LCG (even if it's not as beautiful as completely deleting it)
- Stephan: we also gain if we deduplicate the code in cmake
- Bertrand: we should be clear what is builtin and what is downloaded
- stephan: i would try not to vendor anything if possible, everything else should be a central mechanism that clarifies where everything comes from, with minimal cmake code
- Jakob: you already provide the .exe for those who want comfort, and if it's harder for the rest then it's fine
- Vipul: if you do this you won't have any more windows developers
- Jonas: good
- Bertrand: sometimes it's not good to restrict the users' options too much
- Danilo: if we can remove lines from this tables I would be very much inclined to listen to solutions, but I don't want to leave behind users that don't know anything but still want to use root
- Vipul: how about distribution? do we distribute with the builtins or without?
- Danilo: for the places where we have builtins already (linux) we're doing a good job at using what's on the system, for mac to be discussed
- Jonas: for the table, it would be nice to have a column that says which builtin works on which platform
- Bertrand: it would be good to know what builtin is used exactly for what
### Shift handover: Aaron -> Stephan
- all failures resolved, issues and PRs assigned
- pending issue was 6.36 mac-beta failues, dev is looking into it, danilo and dev will take a look after the meeting
- for the forum everything is being replied to
- there was a failure on ml-dataloader-tensorflow today
- dev: for 6.36 we need 9 backports
- Jonas: for me this is a no-go for a long term support release especially with the risk of breaking major gcc versions, this is not how we do backports
- Danilo: the implication of that is that root 6.36 will stop working on mac
### Meetings
- Statistical Analysis
- Jonas R attended two IRIS-HEP Blueprint workshops and gave two presentations - See Jonas R's section in the status report document
- PPP
- A person from lhcb presented their work on the ROOT-MCP server
- Python bindings
- NTR
- LIM
- NTR
- IO
- NTR
### Liaisons
- Stephan
- Questions about to extent at which RNTuple can be read via jsroot for an event display
There are minutes attached to this event.
Show them.