MaintainersApr2023
Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects
Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers
Contents
Date/Time/Venue
Topic: ns-3.39 and future plans
Zoom meeting.
- April 3, 2023 08:00 AM Pacific Time (US and Canada), 15h00 UTC
Agenda
1) ns-3.39 plans: schedule for release, and any plans by maintainers (that they wish to socialize in this meeting)?
2) Alberto Gallegos would like to discuss the plan for abandoned issues or MRs in the tracker; could dormant or abandoned issues and MRs be marked as such in the tracker, or closed?
3) current plans for the annual meeting (Washington DC and virtual, June 26-29)
4) longer-term issues (TBD)
Materials
Minutes
Attendees: Tom Henderson, Alberto Gallegos, Peter Barnes, Eduardo Almeida, Sebastien Deronne, Biljana Bojovic, Gabriel Ferreira
Introductions
Tom mentioned that he will be focusing on ns-3 annual meeting preparation, NR V2X model, and a DCE release in the next few months. Alberto discussed plans for Zigbee and his energy module proposal (!1329).
GSoC update
The project is participating in GSoC; student applications are due tomorrow (April 4).
WNS3 update
WNS3 will be hybrid with registration fees for both virtual and in-person attendance. June 26 and 27 will focus on tutorials, invited talks, and meetings, including the topics of NR V2X and also ns-3 integration with AI/ML frameworks. Paper presentations and lightning talks are scheduled for Wednesday and Thursday. Friday may be reserved for a hackathon. Accepted papers should be announced on Wednesday. Tom is still seeking volunteers for the artifacts evaluation committee.
Handling dormant issues and MRs
Alberto previously raised the question about marking issues and MRs as dormant, or closing them. Alberto pointed out to a few older MRs in which the submitter no longer responds to queries. Tom remarked that our issues list is ever growing and many have not been touched for over a year.
Tom suggested that some issues that are feature requests be listed in Sphinx documentation if there is no plan for anyone to work on it. Tom also mentioned that when we have longstanding bugs on some modules, and the issues are buried in the tracker, users keep reporting them over and over (e.g., recent TCP BBR issue reports). Eduardo expressed reservation of listing these explicitly in the Sphinx documentation because we will forget to update this second list, but instead considering to post a special link in the Sphinx documentation that links to module-specific (tagged) bugs.
Tom suggested possibly closing out abandoned MR code proposals from the tracker and listing them separately on a contributed code wiki page for archival purposes and future reference.
We discussed whether issues should be closed if a time limit (e.g. 6 months) elapsed. Eduardo said that GitLab.com has some automated tools that could be used for automating policies such as this.
Peter shared a concern about balancing 1) the amount of effort (disincentives) we place on new submitters to update documentation and tests with their patches and MRs, vs. the effort that falls on maintainers to handle reports without easy ability to reproduce, and the need for maintainers to do more work to finish off these MRs. Alberto stated that he felt that asking for a working example is a good balance of these concerns, but not necessarily documentation updates and new test case code.
There was some discussion on the burden of submission on new submitters (students) needing to install and configure tooling such as clang-tidy, Latex documentation packages, etc. to be able to pass submission checks. Eduardo felt that tool integrations were now good enough that it was less of a burden to ask people to use these tools, and proposed, in the past (!1103), a settings.json to help with VS Code integration. Alberto said that for students and inexperienced programmers, this may still be hard.
The discussion ended seemingly without a strong consensus on next steps, so Tom proposed to take a pass through the tracker and come back to the list and Zuiip with a concrete proposal.
ns-3.39 schedule and priorities
Tom listed a few bug priorities (test sensitivity to RV stream assignment, TCP bugs) and asked whether there were any other major issues (outside of normal ones being handled right now in the tracker). None were suggested.
Eduardo mentioned that he felt that the current modules that depend on external libraries (openflow, BRITE, and click) are troublesome because they tend to not be exercised by tooling and then issues crop up near release time, and suggested moving them to the app store. Tom also mentioned past discussions on the unmaintained modules (e.g., wave, wimax) moving there. Also, we should have discussion on moving in some newer modules like SigFox and Lora. There isn't a clear criteria for doing this. We agreed on the need of a separate meeting to discuss this.
Peter felt that it was important to clearly maintain the distinction between maintained (being exercised by our CI infrastructure) and unmaintained modules.
Tom asked about distributing an allinone with contributed modules such as 'nr' as part of the release. Biljana stated that there is a workflow issue in that 'nr' waits until the actual ns-3 release, and then makes a new 'nr' release to match. Again, this can be discussed in a future meeting.
The final topic discussed was schedule for ns-3.39-- June or July. In the interest of trying to get back on our originally planned schedule of three releases per year (January, May, September), we agreed to aim for a June release.
other topics
Alberto reminded of the need to discuss the use of C++ namespaces and naming in general--again, this should be a separate future discussion.
