[Ns-developers] release planning meeting minutes

[Tom Henderson]

Attached are some meeting minutes from the previously announced chat last Friday.  

In short:
1) we are updating the release process to avoid major merges later in the 
process (like we had with nsc) and to give the release manager more authority 
to manage the release and checkins
2) we are planning for ns-3.3 in December timeframe.  Craig is going to be release manager.
3) we are planning for an ns-3.2.1 release in October.  Raj is gathering
requirements this week.

Please send any comments on the below to the list.

- Tom

Minutes of Sept 26 ns-3 conference call.

Meeting hosted by Tom Henderson.
Participants:  Craig Dowell, Mathieu Lacage, George Riley,
Raj Bhattacharjea, Michele Weigle, Joe Kopena, Sam Jansen   

Agenda:

1.  ns-3.2 post-mortem
2.  ns-3.2.1 release planning
3.  ns-3.3 planning
4.  Bug triaging
5.  Future directions


1.  ns-3.2 post-mortem

Tom:  Things to work on:
1) do a better job with requirements and architecture
 -- bridging code was merged although it wasn't completely thought out for
   all interfaces, and it did not play well with global routing.  Caused
   problems during release process.
 -- different people had different views of the requirements during the
   release process (e.g., MinGW, offline behavior)
2) do not merge major modules (ns-3-nsc) so late
3) give release manager more control/authority over the release

Sam:  Shouldn't have merged nsc without some sort of test

Tom:  Will circulate a suggested revised release process, to try to
remedy the above.

Mathieu: Date driven release schedule is the way to go (instead of
 feature-based release schedule).  

Side discussion on regression testing infrastructure:
- would be nice to have results of nightly validations on a webpage
 (Tom to take action item)
- Mathieu suggested looking at Tinderbox
- Tom noted that there are some features of existing regression infrastructure
 that users could use to test their own code on the same tinderboxen.
  (Tom to document and post)

2.  ns-3.2.1 release planning

We could fix a few things and issue a .1 maintenance release
- fix optimized build problems on ubuntu
- make nsc download a tarball
- a few miscellaneous bugs?

Consensus was that another goal for making a 3.2.1 release is to
improve our code coverage in the examples and unit tests.  We have
some gcov/lcov tools that will at least let us diagnose our current
coverage, and prioritize.

Raj was nominated as release manager and took the action item to
try to gather suggested roadmap for the 3.2.1 release by Oct 3 timeframe.

3.  ns-3.3 planning

Tom listed his "feature wish list" for ns-3.3, regarding existing
simulator models:

1) Decide on build system requirements and make revisions
2) Fix IPv4 problems that are blocking other work
3) Fix existing routing protocol (global and OLSR) limitations
4) Michele's random variable proposal
5) helper API and usability (node names patch)
6) tag cleanup

Mathieu expressed that IPv4 API (header) is one of the main priorities.

Mathieu also expressed that pulling off a date-driven release, on schedule,
was a very important goal.

Raj volunteered to help Michele with a random variable patch.

These are new modules we can start to merge for ns-3.3:

1) IPv6 
2) emulation support

Tom noted that the above list was ambitious.  Mathieu said that ns-3-simu
was not going to be ready for ns-3.3.  

Craig agreed to serve again as release manager, and to start to put together
a merge schedule assuming that we try to get these features or major merges
done in the month of October:
- IPv4 
- build system revisions
- ns-3-ipv6-1st
- emulated/tap net devices for ns-3-emu

4.  Bug triaging

How to handle the fact that bugs are coming in faster than they are being
closed?

Mathieu suggested that weekly or biweekly, the main developers chat
about bugs.  This may help us make progress on lingering bugs that never
get committed because they cross maintainer boundaries.  Tom suggested that 
this topic was good for the Tuesday IRC session that has already been
coordinated.

All bugs should be triaged to a maintainer.  Bugzilla does not have any
current capability to default assignment of bugs to different components 
to different maintainers, _and_ keep ns-bugs at isi.edu cc'ed on every one.

Mathieu agreed to look at a bugzilla patch to fix this limitation.  Tom 
said he'd go through the existing bug list in the next few days and 
assign them out.

5.  Future directions

What has been feedback on ns-3 that we have received to date?

Common questions or comments at our Sigcomm demo:
- didn't realize ns-3 was out of pre-alpha mode
- does ns-3 do inter-AS (interdomain routing) simulations, with BGP?
- does ns-3 have model <insert model here>?
- lots of questions about Phy-level modeling of 802.11 simulations
- how can I get training (multi-day training courses, even) for ns-3?

What can be done to get more models?  Tom suggested that it would help
to have some examples of how to port ns-2 models to ns3.  Mathieu
suggested that, for application models at least, it would be nice
to get some more help/support for ns-3-simu.  Joe mentioned that he
was going to help to teach a class again this fall, where ns-3 model
development was to be a class option.