[Ns-developers] ns-3.4 action plan

[Raj Bhattacharjea]

This email is lengthy, so I will try to clearly mark the headings.  This is
a status of what is being done for ns-3.4, and an outline of the release
procedure.

Here is an update of the latest status for ns-3.4.

**********Major Merge Items**********
The following is the status of the major merge items proposed.

=====Ipv4 Rework=====
Tom has proposed to pull this from the release.  He is going to follow up on
this list with more details.

=====Random Variables=====
This is presently blocked due to the repository not passing a sanity check.
The output of all of the example/regression simulations should not change
under the new API, provided they are seeded the same way.  The behavior
being seen is that even when seeded in the same way, simulations produce
different output than before the changes.  I am investigating, and when the
issue is resolved before the end of next week week, I will perform a merge.

=====Tap NetDevice=====
The discussion seems to have wound down, with most maintainers having
reviewed the changes.  If there are no more changes as a result of
additional comments, this is scheduled to be merged on Thursday of next
week.

=====Object Names=====
The discussion on this also seems to have come to a close, with most
maintainers having reviewed the changes.  If there are no more changes as a
result of additional comments, this is scheduled to be merged on Tuesday of
next week.

**********Bug List Procedure**********
The buglist will be the next thing to tackle after the merge phase.  Bugs
marked as P1 in the tracker are considered blockers for the release, and
MUST be fixed prior to the first release candidate.  If a maintainer feels
that a bug is not P1 worthy or cannot commit to having a fix by March 1st,
he will have to make the case for reducing the priority of the bug.

Prior to checking in a bug fix into the dev branch, the maintainer should do
the following:
1.  Locally test to make sure the change doesn't break the build.
2.  Ping me for a "token" to make changes to ns-3-dev, during which time I
will schedule time for a maintainer to patch ns-3-dev and test it, and
announce that no one else should be editing ns-3-dev for X amount of time.
3.  Run the full regression/test suite on ns-3-dev+changes, using the UW
regression machines.  When it passes, the token passes back to me, and the
next person in the queue will have their opportunity.

We currently have the following list of P1 bugs:
http://www.nsnam.org/wiki/index.php/Ns-3.4#The_ns-3.4_Bug_List
I will be working to fill in the status of these soon.

**********Contributions**********
There have been a number of contributions to ns-3 that are sitting in the
tracker.  We are going to start a seperate wiki page with summary
information to track these, and to help me pester people to look at the
patches.  It will be here:
http://www.nsnam.org/wiki/index.php/Contributed_Code

But is stubbed out as of now.

Comments or suggestions are welcome.
-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955