[Ns-developers] ns-2.29 release, and moving to a new forge

[Tom Henderson]

I propose for discussion the following next steps:

i) release of ns-2.29 and ns-2.29-allinone on ISI web site, and tclcl 
and otcl on sourceforge, by Oct 1.  This would be primarily a 
maintenance release (OS X 10.4, gcc-4.0 support, and relicensing) with 
also new HDLC, error, and energy models, and various bug fixes.  Full 
x86_64 support probably needs to wait for next release.  I would 
volunteer to lead this, hopefully with some assistance particularly in 
checking whether the conf/ files are up to date on different platforms 
(following release_steps.txt in the main ns-2 directory).  Full changes 
can be viewed at: http://www.isi.edu/nsnam/ns/CHANGES.html

ii) immediately thereafter, move source code and cvs history to a new 
forge after the ISI release, make an equivalent release ns-2.29.0, tag 
that release, and branch cvs for 2.29.x releases.  Leave ISI web site up 
for interim period then have it point to new project site once established.

iii) on this new forge, maintain in parallel a stable ns-2.29.x branch 
and an unstable ns-3.0 for new features and refactoring (this approach 
was suggested by Mathieu)

We can discuss ns-3 and future ns-2 feature sets in separate (future) 
threads.

As for a new forge, there are a few options
- Sourceforge
- GNU forge (savannah.nongnu.org)
- custom forges (such as gforge.inria.fr)

There are various issues with these sites, including performance (speed 
and availability), resources (e.g., disk quotas), mailing list and 
tracker capabilities, source code control system, etc.

I propose sourceforge, using cvs (importing cvs history from ns-2), 
bugzilla or sourceforge tracker for tracking, one or more wikis, and new 
mailing lists.
- cvs is all they support, and should be sufficient and comfortable for 
most developers
- cvs history should be importable (although I don't know if we could 
ever reclaim cvsroot if we wanted to move in the future)
- Sourceforge has a bug tracker (i've never used it)-- an alternative is 
bugzilla.  I'm familiar with bugzilla.  I don't know how much of a pain 
it would be to set up bugzilla there on the hosted space, and whether it 
would be limited functionality (i.e., allowing patch uploads).  I'd be 
interested in hearing feedback on sourceforge's trackers.
- each project has up to 500MB of disk available (is this enough?). 
This could be used for bugzilla, documentation, and wikis.  If more were 
needed in the future, disk-intensive items could be hosted outside.
- otcl/tclcl is already hosted there

Comments?  Other options to host and support the project?

Tom