- 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
- Coding style and whitespace
- Tooling (scripts and programs) to enforce style
- How/when to perform an update across the codebase
- Open issues: #279, #437, #522, #629
- Open merge requests: !732, !734, !905, !906, !912
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.
May 19 whitespace/style meeting
Attendees: Ameya Deshpande, Peter Barnes, Eduardo Almeida, Tom Henderson, Gabriel Arrobo
- Need maintainable solution to avoid post-commit fixes to style and to divergent results on different platforms
- will need a flag day to clean up, then hopefully avoid in the future
- apply to CI pipeline
- need to exclude selected code from style (whole files, portions of files)
- what about documentation and other non-code files?
- bash script for whitespace: https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/839/diffs
- deleted constructors: https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/906
- remove 'using namespace std': https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/912
Tom/Gabriel: Looked at (and confirmed) different clang-format versions cause different output
Eduardo: clang-tidy may remove many of those cases
Eduardo: clang-format works best with applying an underlying style rather than ad hoc style
Gabriel: Agree, but used default template GNU format and applied customizations; still some small differences.
One example is different C++ versions, angle closing bracket '> >' in C++03, but later standard is '>>'
Eduardo: do not think there will be major out of tree issues; rebases will not be hard...
Peter: agree that end of line whitespace in principle are different from enforcing coding standards, but in practice, all have the issue of needing to specify the tooling to avoid conflicting results. Doxygen has improved the CI process but still haven't done a good job helping maintainers with good feedback when something fails.
Eduardo: if CI fails, whitespace script just needs run; just a bash script- no dependencies on clang-format
Peter: recent clang-format can handle whitespace
Tom: (changing topic) do we want a single flag day with everything (style and whitespace changes), or just handle whitespace separately (now)?
Eduardo: All MRs definitely need rebased, but majority of conflicts handled automatically if users haven't touched those lines
clang-format/clang-tidy will cause users more problems to resolve, however.
Tom: what about different versions of tools; how to handle? Docker container? Wrapper script/virtual env?
Eduardo: have GitLab check and fix it? 90%ish of issues can be fixed by clang-format/clang-tidy
Peter: opposed to automatic changes by the CI/commit hooks. Not wild about VM/Docker solution. Could perhaps test and allow a set of compatible versions.
Tom: Can these tools handle exclusions with some kind of guards?
Eduardo: yes, both tools provide this
Tom: How to avoid version differences? mongoDb used custom script to download specific versions: https://engineering.mongodb.com/post/succeeding-with-clangformat-part-2-the-big-reformat/
Eduardo: Such a solution would cause problems with IDEs
clangformat/clang tidy needs more testing
Ameya: which tools integrate with the IDE?
Gabriel: clang-format typically does.
Ameya: precommit script on developer side? Avoid late CI discovery of problems.
Tom: Yes, we would like this to be part of the solution.
Eduardo: may need to fine tune coding style to better fit the predefined gnu template
- Eduardo to extend !839 with a CI job, then Tom to ask maintainers to test run and provide feedback
- issue last call on !906 and !912
- Eduardo to continue work on clang-format/clang-tidy proposal