Difference between revisions of "MaintainersApr2023"
(create maintainer meeting for April 3) |
(add minutes) |
||
| Line 5: | Line 5: | ||
Topic: ns-3.39 and future plans | Topic: ns-3.39 and future plans | ||
| − | + | Zoom meeting. | |
| − | + | * April 3, 2023 08:00 AM Pacific Time (US and Canada), '''15h00 UTC''' | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
== Agenda == | == Agenda == | ||
| Line 27: | Line 21: | ||
== Materials == | == Materials == | ||
| + | [https://www.nsnam.org/wp-content/uploads/2023/maintainers.040323.pdf Slides] | ||
== Minutes == | == 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 the balance of effort (disincentives) we place on new submitters to update documentation and tests, vs. the effort that falls on maintainers to handle reports without easy ability to reproduce. Alberto stated that he felt that asking for a working example is a good balance of these concerns. | ||
| + | |||
| + | There was some discussion on the burden of submission on new submitters (students) needing to install and configure clang-tidy, documentation packages, etc. to be able to pass submission checks. Eduardo felt that integrations were now good enough that it was less of a burden to ask people to use these tools, and proposed, in the past, a settings.json to help with VS Code integration. Alberto said that for students and inexperienced programmers, this may also 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. | ||
== Recent maintainers meetings == | == Recent maintainers meetings == | ||
Revision as of 22:28, 3 April 2023
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 the balance of effort (disincentives) we place on new submitters to update documentation and tests, vs. the effort that falls on maintainers to handle reports without easy ability to reproduce. Alberto stated that he felt that asking for a working example is a good balance of these concerns.
There was some discussion on the burden of submission on new submitters (students) needing to install and configure clang-tidy, documentation packages, etc. to be able to pass submission checks. Eduardo felt that integrations were now good enough that it was less of a burden to ask people to use these tools, and proposed, in the past, a settings.json to help with VS Code integration. Alberto said that for students and inexperienced programmers, this may also 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.
