[Ns-developers] roadmap for ns3.2.1
sam.jansen at gmail.com
Tue Oct 7 15:24:49 PDT 2008
I was also hoping to have ns-3 depend on a specific NSC release rather than
the mercurial repository by default. I think this is a worthwhile goal,
because otherwise the ns-3 release depends on a development NSC release,
which might be end-user visible, completely broken, and fixable (by relying
on the tested, released NSC version). I'm not sure how this ties in with the
build system rework that is going to come later.
I could possibly try and make a patch for this, this week, depending on how
others feel about its inclusion in the release.
2008/10/7 Raj Bhattacharjea <raj.b at gatech.edu>
> During our last conference call, we decided to do a ns3.2.1 release to
> address some of the major issues with ns3.2. Primarily, what we found
> was that due to a lack of testing and code coverage, some things
> stopped working between ns3.1 and ns3.2. The following is a list of
> issues that I have identified for potential inclusion in this
> incremental release.
> 1. According to http://www.nsnam.org/bugzilla/show_bug.cgi?id=370
> there are extra, private headers installed on a system when you
> install ns-3, but removing these cause --python-scan problems. This
> might not be user visible though, so I wanted to solicit some more
> discussion here.
> 2. In http://www.nsnam.org/bugzilla/show_bug.cgi?id=371 it appears
> that an example program has undergone a regression (and since it
> wasn't a part of the regression framework, it wasn't caught).
> 3. In
> another example program was reported to contain a mistake. This needs
> to be fixed.
> These are the specifics that seem to qualify. I think the metric for
> determining whether or not a fix should be in ns3.2.1 is "is something
> end-user visible, completely broken, and fixable".
> In addition, we had spoken about increasing unit test coverage of the
> codebase. I looked at the lcov report from running our unit tests,
> and it seems to me that the following portions of our code base
> require more testing.
> I would like to ask that the respective maintainers of these pieces of
> code have a look and propose some ideas for how to increase code
> coverage in the unit tests. We could then roll the above fixes and
> increased unit tests into ns3.2.1 within say, 2 weeks.
> Raj Bhattacharjea
> Georgia Institute of Technology
> School of Electrical and Computer Engineering
> Ph.D. Candidate
> Systems Analyst
More information about the Ns-developers