MaintainersApr2026: Difference between revisions
(add minutes for April 24 meeting) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 47: | Line 47: | ||
2) General roundtable on roadmap/priorities (what does each maintainer want to prioritize for ns-3.48 and beyond?) | 2) General roundtable on roadmap/priorities (what does each maintainer want to prioritize for ns-3.48 and beyond?) | ||
Alberto proposed: Use of CMake presets? | Alberto proposed: | ||
1) Use of CMake presets? Yes or no | |||
2) Inclusion of DTN models in the mainline | |||
== Minutes for April 24 == | |||
Attendees: Anders Martinsson, Tom Henderson, Eduardo Almeida, Alberto Gallegos Ramonet | |||
Minutes from Tom Henderson, edited by Alberto and Eduardo | |||
Agenda: | |||
1. Use of CMake Presets | |||
2. Inclusion of DTN models in the mainline | |||
3. How to promote smaller MRs for easier reviews | |||
Anders introduced himself as the submitter of a recent patch series to update DCE environment. He said that other developers were involved at his company and they were using it to test a secure reliable transport protocol. Tom said that he was planning to get to DCE patches once mp-units work died down. | |||
Alberto and Eduardo discussed the history of the CMake Presets to Tom who does not use VScode and wasn't fully aware of the issues. Eduardo mentioned that we currently use .ns3rc for this kind of configuration control but it would be nicer to use CMake Presets since it is the standardized way. | |||
An initial attempt to use CMake Presets was introduced last month in !2763 by the CTTC team as a way to use configurations that allow the use of Sionna spectrum models. However, as described in !2822, the introduction of CMake Presets forced users using the VsCode IDE to chose one preset (VsCode default behavior when using CMake Presets) without the possibility of choosing different build variants or compilers outside the established presets. Gabriel reverted the situation by renaming the CMake Presents configuration file to use a different extension but more work is needed on a better solution if the use of presets are to be introduced. | |||
We discussed DTN and the pros and cons of adding this to the mainline or to the app store. Alberto is in favor of adding new models to the main line assuming that they are for the common benefit ( e.g., based on specifications, standards, current RFCs, etc) and have a maintainer. In the same line of thought, he thinks that models in the main line that do not have a maintainer or have unresponsive maintainers should be moved to the app store. Accepting new contributions has the possible side benefit of attracting more long term maintainers. If the maintainers of those models become uninterested in maintaining or unresponsive, it is possible to move them to the app store. | |||
Eduardo pointed out that the app-store have evolved and serve multiple purposes, among them: A place where worthy unmaintained projects are stored and where private groups keep visibility of projects actively maintained outside of the main line. | |||
However, the general sentiment is that when possible, we ought keep ns-3 mainline lean, and it is not clear where DTN lands as a result of these tensions. | |||
Tom mentioned that a second benefit of having MRs submitted to the mainline is that they obtain code reviews; the ns-3-contributed-modules review site has never taken off and is ignored by maintainers. Still, it seems that the attendees were possibly in favor of reducing the modules in ns-3-dev, adding more to the app store, and making it easier for users to discover and clone modules of interest (kind of like 'bake' is doing for DCE, but possibly through extending the ns3 script or CMake). | |||
Tom mentioned his difficulty with reviewing large MRs. Eduardo said he wasn't in favor of a hard CI requirement on MR size and Tom said he wasn't serious about this and agreed that softer reminders (please regenerate your MR in smaller chunks) would be better. Tom said that he also wants to see the overall plan of where things are going, rather than having the new module revealed to him piece-by-piece with small MRs, so having a fully built-out branch that is publicly available for review to accompany the MRs is also needed. Eduardo volunteered to review our contributing documentation to see if there is an opportunity to emphasize "one MR per topic and make as small as possible." | |||
== Recent maintainers meetings == | == Recent maintainers meetings == | ||
Latest revision as of 16:26, 1 May 2026
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.
Lingering 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?)
Alberto proposed:
1) Use of CMake presets? Yes or no
2) Inclusion of DTN models in the mainline
Minutes for April 24
Attendees: Anders Martinsson, Tom Henderson, Eduardo Almeida, Alberto Gallegos Ramonet
Minutes from Tom Henderson, edited by Alberto and Eduardo
Agenda: 1. Use of CMake Presets 2. Inclusion of DTN models in the mainline 3. How to promote smaller MRs for easier reviews
Anders introduced himself as the submitter of a recent patch series to update DCE environment. He said that other developers were involved at his company and they were using it to test a secure reliable transport protocol. Tom said that he was planning to get to DCE patches once mp-units work died down.
Alberto and Eduardo discussed the history of the CMake Presets to Tom who does not use VScode and wasn't fully aware of the issues. Eduardo mentioned that we currently use .ns3rc for this kind of configuration control but it would be nicer to use CMake Presets since it is the standardized way. An initial attempt to use CMake Presets was introduced last month in !2763 by the CTTC team as a way to use configurations that allow the use of Sionna spectrum models. However, as described in !2822, the introduction of CMake Presets forced users using the VsCode IDE to chose one preset (VsCode default behavior when using CMake Presets) without the possibility of choosing different build variants or compilers outside the established presets. Gabriel reverted the situation by renaming the CMake Presents configuration file to use a different extension but more work is needed on a better solution if the use of presets are to be introduced.
We discussed DTN and the pros and cons of adding this to the mainline or to the app store. Alberto is in favor of adding new models to the main line assuming that they are for the common benefit ( e.g., based on specifications, standards, current RFCs, etc) and have a maintainer. In the same line of thought, he thinks that models in the main line that do not have a maintainer or have unresponsive maintainers should be moved to the app store. Accepting new contributions has the possible side benefit of attracting more long term maintainers. If the maintainers of those models become uninterested in maintaining or unresponsive, it is possible to move them to the app store.
Eduardo pointed out that the app-store have evolved and serve multiple purposes, among them: A place where worthy unmaintained projects are stored and where private groups keep visibility of projects actively maintained outside of the main line.
However, the general sentiment is that when possible, we ought keep ns-3 mainline lean, and it is not clear where DTN lands as a result of these tensions.
Tom mentioned that a second benefit of having MRs submitted to the mainline is that they obtain code reviews; the ns-3-contributed-modules review site has never taken off and is ignored by maintainers. Still, it seems that the attendees were possibly in favor of reducing the modules in ns-3-dev, adding more to the app store, and making it easier for users to discover and clone modules of interest (kind of like 'bake' is doing for DCE, but possibly through extending the ns3 script or CMake).
Tom mentioned his difficulty with reviewing large MRs. Eduardo said he wasn't in favor of a hard CI requirement on MR size and Tom said he wasn't serious about this and agreed that softer reminders (please regenerate your MR in smaller chunks) would be better. Tom said that he also wants to see the overall plan of where things are going, rather than having the new module revealed to him piece-by-piece with small MRs, so having a fully built-out branch that is publicly available for review to accompany the MRs is also needed. Eduardo volunteered to review our contributing documentation to see if there is an opportunity to emphasize "one MR per topic and make as small as possible."