MaintainersJune2023
From Nsnam
Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects
Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers
Date/Time/Venue
Topic: ns-3 development discussions
June 30, 2023 09:00 AM Eastern Time (US and Canada), 13h00 UTC
Agenda
This day was used to discuss/coordinate next steps with ns-3 development, among the people who are hanging around after the Workshop on ns-3, and anyone who may want to join remotely.
Below is the list of proposed discussion topics.
- GSoC students will introduce themselves and their projects
- Tom Henderson would like to discuss next steps with educational support and usability.
- Reaction to feedback from WNS3 presenters
- TCP and tutorial troubles
- Ease of use
- "Runs slow"
- Need Wi-Fi that "just works", performs handover
- Lack of configuration GUI
- Alberto Gallegos proposes discussing these topics
- sudo ns3 #923
- Release packaging, bake, ns-3-allinone, Dockerfiles, downstream packaging, ...
- CI and other projects in namespace (modules, bake, etc.)
- Promoting usage of NetSimulyzer/NetAnim
- Website ideas
- Tutorial/training ideas
- General issues with documentation #882
- C++20
- Training: more regular sessions online. Poll ns-3-users for topics of interest, then prepare and perform a tutorial. Avoid waiting for another year.
Minutes
Attendees: Alberto Gallegos, Peter Detzner, Lars Tönning, Katerina Koutlia, Sharan Naroble, Jiwoong Lee, Sebastien Deronne, Evan Black, Tom Henderson Tommaso Pecorella, Peter Barnes, Mohit Tahiliani, Muyuan Shen, Giovanni Grieco, Raghuram Kannan
- GSoC students (Muyuan, Giovanni, and Raghuram) introduced themselves and their projects
- We briefly discussed the movement to C++-20, and confirmed the plan should be to first enable it in the build as the standard in use, but wait for a release cycle before using new features from it.
- Alberto raised the documentation for discussion. Is there guidance on using the INFO level of logging? Tom suggested that he would like to use the guidance that was listed in the issue tracker on this (try to log significant state-changing events). Is there a canonical/blueprint for writing documentation chapters, tutorials, or example programs? The create-module.py lays out an outline for documentation, but otherwise, there are not guidelines. Some modules or features have no Sphinx documentation. There was also some discussion on the order that we should assume people will read things (tutorial, manual, model library, or other?).
- Should we recommend one code editor and use one in documentation clarity? The meeting attendees used a variety (QtCreator, Eclipse, VS code, CLion) so there was no consensus to focus on one.
- suggestion to start making some 5 minute videos on how to debug a program, etc. Gabriel pointed out that he had started to make some videos related to CMake, debugging, and CLion: https://www.youtube.com/@gabriel65412/videos
- short discussion on Docker files--whether we should maintain and distribute them, and Docker images on DockerHub, and how to manage Docker volumes. I don't remember the resolution/outcome of this discussion.
- some discussion on Gabriel's Jupyter examples and how to make more of them, and whether to provide instructions on how to install bindings, how to run notebooks locally, etc.
- Allow to filter log outputs based on the context (node id, mac address or others) #83. It was discussed that this might be hard in general, but time windowing might be the lowest hanging fruit of log filtering.
- Default Time display precision (lack of max precision) #771. Discussed with Peter and may settle on a Time::ALL option for full precision logging in log statements.
- C++ namespace usage, are we enforcing any rules? Is the lower case naming convention ok?. On this point, Peter had a proposal in issue 707 discussion that might be as good as any to choose.
- Discussion on "sudo ns3" #923. Current restriction in ns3 program does not restrict Docker usage. Agreed with Gabriel that we will keep the block on running sudo and document to users how to comment out the 'refuse_run_as_root()' statement if they really want to install as root.
