[Ns-developers] new ns-2 software contributions

[Mathieu Lacage]

On Wed, 2005-03-30 at 21:35 -0800, Tom Henderson wrote:
> Lloyd Wood wrote:
> > On Sun, 27 Mar 2005, Tom Henderson wrote:
> > 
> > 
> >>My recollection is that STL was avoided in the past because not all
> >>compilers supported it consistently-- I think those days are behind us
> >>now, though, and would support and prefer using the STL in the future.
> > 
> > 
> > STL should imo be avoided simply because very few people, and even
> > fewer graduate students, know how to use it correctly (including me)
> 
> > 
> > Using STL for retrofitting ns infrastructure and telling everyone else
> > to avoid it without very good reason would be fine; ns is not much use
> > if it's inaccessible to most (being C in C++ wrapping is arguably

I am not talking about starting to use the STL here. Parts of ns-2
already do this. I am merely suggesting dropping one of the two style of
containers (STL vs BSD-style macros) used in the code. As I said
earlier, I am not convinced that the STL is the best solution but I
doubt that the BSD-style macros are a better solution. In that context,
the choice is easy for me: STL.

[snip]

> > At the very least, I'd design a yearly release schedule that was aware
> > of of that, with new releases coming just at the start of the academic
> > year for staff and a new intake to get familiar with, 
> 
> These are good ideas.  In large part, what can be done will be 
> determined by the level of effort contributed.

I am sure that a single release a year will not help make the ns-2
codebase less of a mess: don't put all your eggs in a single basket.

  - the less you release, the more people work on old releases, the more
their work diverges from your release, the less likely it is they
contribute back their work

  - the less you release, the harder it becomes to integrate outside
code

  - the less you release, the harder it is to make sure that these
single releases are high-quality because you don't have QA ressources.
Usually, open source projects try to get the _users_ to be their QA.

Conclusion:
1) release often
2) use cvs branches and cvs tags
3) use your users as QA

If you do this, you should be able to converge towards high-quality
releases reasonably fast (reasonably means within 6 to 10 months). If
you don't, it will be much harder and will probably require much more
ressources in the long run.

> For now, in the absence of other suggestions, I think the following 
> basic steps would be sufficient for a new release:
> - move code to Sourceforge and clean up the licensing
> - add the new 802.11 models

I believe that the new 802.11 code should be developed on a branch in
the new cvs repository until it has been sufficiently tested/reviewed.
This would make it possible to do a release after the move and before
the new 802.11 code. Obviously, I don't mind handling the cvs
merge/conflict issues provided I get commit privileges on the cvs
branch.

As I said in another email, I would very much like to see a lot of small
regular releases with most new major developments done on cvs branches
rather than yearly releases with large changes done at the same time on
the main cvs trunk.

Mathieu