MaintainersApr2026
Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects
HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers
Dates/Times
Two follow-ons to the March meeting are planned:
Friday April 3, 15h00 UTC, Jitsi Meet: https://meet.jit.si/moderated/289f92cf76787daa78b8795a8ccf0d18455992a127b6c346403797734281de0d
Friday April 24, 15h00 UTC, Jitsi Meet: https://meet.jit.si/moderated/f77dc878bc2167da942669fe1bc99804dd706a60a97752c6773d1afd1fdaaf3b
Agenda for April 3
Update on strongly-typed units (Tom)
- Proposing to adopt the mp-units MR and quickly port the wifi module for ns-3.48
Minutes for April 3
Attendees: Tom Henderson, Stefano Avallone, Peter Barnes
Minutes taken by Tom Henderson
The meeting discussed the mp-units MR and si-units-v2 MR. Tom intends to close the nholthaus proposal in favor of mp-units.
Tom expressed his interest in adopting the mp-units MR due to potential alignment with the future standard, and to avoid the project having to maintain its own units library. He is happy with how the wifi port turned out, and aside from cppyy alignment, he would be inclined to push it now and finish further work in-tree. Peter mentioned that our experience with Waf to CMake migration suggests that there is a long term maintenance benefit of aligning with external best practices rather than doing our own thing. Stefano expressed interest in future (potential) standard library alignment and found a Reddit post about a recent presentation to the standards committee by the mp-units lead author, suggesting that it is still on track.
We discussed potential ns3::Time compatibility; we would have to give up runtime resolution setting and make it instead a compile-time setting, which might create some inflexibility if ns-3 is distributed as a library package, and might force people to document which resolution the simulator was compiled with.
ingering issues:
- how much backward compatibility to support? Stefano raised one such issue in the tracker (whether we support StringValue() on value classes without providing the units suffix in the string). Do we want to keep the trace sources exporting double types, or give this up? What about ChannelSegments() types? Tom tested backward compatibility of our current wifi examples and 37/51 would still work after the port, if we kept things as they are now.
- cppyy doesn't yet support std::format (which is included by mp-units), and Gabriel is inquiring upstream about this. We can probably work around this with wrappers like Gabriel already introduced for ns-3 Time but Tom hasn't discussed the alternatives much with him yet.
- whether people agree with the decisions taken on naming, which new headers to introduce, how the mp-units namespace is being brought into ns3 namespace, etc.
- would we want to add library-independent syntax for Wi-Fi to ease rebasing for your out-of-tree code? Stefano brought up supporting "MHz_t{20}" in particular and wanting to be able to define constants in a way that they would work for both si-units and mp-units in the near term. With regard to this particular issue, Tom will post options and constraints in the tracker, but Peter was open to defining wrappers if we localized them to wifi module specifically (and use the mp-units library's idiomatic syntax elsewhere in ns-3).
Agenda for April 24
Please propose agenda items for this meeting.
Some items left from the March meeting:
1) How to promote smaller MRs for review? Should our CI system fail (perhaps as a last stage of testing) a MR that exceeds a certain number of lines of code changed? (Tom)
2) General roundtable on roadmap/priorities (what does each maintainer want to prioritize for ns-3.48 and beyond?)