Difference between revisions of "MaintainersMay2022"
|Line 17:||Line 17:|
Meeting ID: 979 1081 9004
Meeting ID: 979 1081 9004
Revision as of 13:26, 16 May 2022
- 1 Date/Time/Venue
- 2 Agenda
- 3 Plans/priorities
- 4 Minutes
- 5 Recent maintainers meetings
Topic: ns-3.37 planning
May 11, 2022 08:00 AM Pacific Time (US and Canada), 15h00 UTC
May 12, 2022 08:00 AM Pacific Time (US and Canada), 15h00 UTC
Additional session on whitespace/coding style:
- May 19, 2022 08:00 AM Pacific Time (US and Canada), 15h00 UTC
Meeting ID: 979 1081 9004
- ns-3.36 maintenance release?
- ns-3.37 (date??) release coordination
- Any other topics
Contributors list their priorities here.
- DCE 1.12 for ns-3.35 release
- Issues: anything with a 'bug' label
- Whitespace/style (clang-format, clang-tidy)?
- New features: !918 (lte HO failure), !370 (net device state), !821 (circle mobility), !546,!648-!650 (clipping), !431 (full duplex CSMA), !529 (distributed MPI), Flent application
- DCE 1.13 for ns-3.36/CMake, Linux 5.10 kernel
- Move unmaintained modules to app store (e.g. wimax)
- Update tutorial (with Mohit Tahiliani)
- architecture for multi-link (multi-phy)
- 11be items
- preparatory changes for 11be (Queue !891)
- Idiom for Ptr boolean tests (!948)
- MinGW/MSYS2 Windows support (!437)
- Find dead URLs (!933)
- Performance improvements (!941, !943)
Attending: Tom Henderson, Peter Barnes, Biljana Bojovic, Ameya Deshpande, Uzoma Onunkwo, Michael Scoggin, Stefano Avallone, Gabriel Arrobo, Gabriel Ferreira, Mohit Tahiliani
- Gabriel Arrobo: Need to clean out old issues/MRs? Tom: perhaps a post-release task to find stale/'no longer relevant' tasks? Peter: don't want to lose some of these; can we tag them somehow?
- Peter: when issues are closed not by merged, can't determine whether 'fixed' or 'not relevant'... need to mark them.
- Tom: Should MRs be put on a schedule (for maintainers to review/merge)? Any other workflow improvements?
ns-3.36 maintenance release
- Tom: probably could use one (sooner rather than later). Scratch directory improvements, some cherrypicked Wi-Fi commits.
- Gabriel Ferreira: Debug build flags as suggested by Gabriel Arrobo
- Stefano: latest patch !948 fixes issue with recently released g++12
- Sqlite support? Lengthy discussion (issue #644). Gabriel Ferreira favors header macro such as before, to limit the scope of linking. Peter favors build-system detection and compilation flag-- argues that it is less confusing to users. Biljana reported some uncertainty about how it works (related to nr module). Tom had also favored the compilation flag in the past-- suggested to go with that. Still an issue to decide (scope of compilation flag).
ns-3.37 release goals
Stefano expressed goals around 11be support (listed above). Peter's top priority seems to be !732. We agreed to pick this topic up again tomorrow (meeting ran out of time for further discussion).
Attending: Tom Henderson, Peter Barnes, Biljana Bojovic, Ameya Deshpande, Michael Scoggin, Stefano Avallone, Gabriel Arrobo, Gabriel Ferreira, Mohit Tahiliani, Sebastien Deronne, Eduardo Almeida
macro for sqlite3 conditional code
Discussed Tom's proposal to issue #644. Gabriel leaned towards options 1 and 2 due to the principle of limiting clutter and including only what you need (in compiler commands). Peter expressed desire to avoid the bad Boost experience of having different handling of these libraries across modules. Peter also said that he has seen other projects avoid clutter of build commands by adding a configure step that gathered all of these defines into a file. Tom voiced support for consistent handling of these kind of macros. In the end, Tom proposed to align with existing GSL and libxml2 macro definition; see the #644 tracker.
Tom proposed to revive the Bugzilla 'status' and 'resolution' labels to avoid lingering issues with no status, and proposed that stale issues be moved to closed state (perhaps automated). Gabriel F. had pointed out GitLab.com's 'triage' bot service in this regard. There was general support expressed for the labels but less support for moving open issues to closed simply due to lack of progress, due to fear that they would never be found there. Michael cautioned against automatic tooling for closing issues, and if they are moved to Closed, to consider to keep a list that is periodically reviewed. Eduardo also said that only people and not scripts should close issues. Tom also suggested assigning people if they take ownership of an issue or MR. Someone pointed out that not everyone can be assigned via the GitLab.com interface (but there are workarounds to this). Biljana voiced support for assigning every issue to an individual (rather than leave any unassigned), and to perform periodic issue review among maintainers. In the end, Tom said he would take a revised proposal to the list.
ns-3.37 release plan
Tom asked maintainers whether they wanted to make a release in June before WNS3, or July before summer holiday? Biljana expressed support for having more frequent releases. Stefano suggested that the real problem is having ns-3-dev frozen for too long and suggested using a release branch if a lengthy testing phase is needed. Since wifi module may be driving some changes to ns-3-dev now, Tom said he would check with Stefano and Sebastien about their plans (and whether it might require a long release cycle).
We ran out of time to discuss. Tom suggested separate meeting with Eduardo and others interested to hash out a proposed design and process, and then another meeting to review. There wasn't any disagreement voiced on the need to do this, but Tommaso suggested that the changes could be widespread. Tommaso suggested that maintainers should be given some scripts so that they can experiment on their own modules, and that some solution integrated with CI system is necessary to keep maintained.