Re: [ns] improving the ns development

[John Heidemann <johnh@ISI.EDU>]

I'm coming somewhat late to this discussion, but I'll try to catch up.

Thanks for the comments on the ns development process.

In general, we try and make ns some combination of

1. inexpensive and open
2. featureful
3. clean
4. relatively easy to use

Obviously these goals are OFTEN in conflict.  For example, ns would be
much easier to use and cleaner if we stopped adding features and just
documented and cleaned up the code.  We try to balence these goals,
with our priorities are roughly in that order.

To address goal 1, we have always made ns CVS available (as daily
snapshots for years) and as anonymous CVS for a couple of months.  (Ns
has always had a completely open code-base, unlike some other research
simulators where part is kept closed source.)

For goal 2, we try to make it easy to post contributed code on our
contrib code web page.

Goals 3 and 4 require that there be some care taken as to what goes
in to ns.  This, combined with severely limited resources, is the
primary limit on what goes in to ns.  For more discussion, see below.

Neundorf Alexander wrote:
> I want to suggest a different development model for ns2. Don't
> expect anything fancy now, just the "let's do what everybody
> nowadays does" ;-) So, to make it short, let's put ns2 on a cvs
> server (whereever, if there is no other choice SourceForge). This
> way we would have more people who really know the code, more fixes
> would be committed to the code, more new features, new introduced
> bugs would be found more or less instantly and so on (speaking
> from my experience from kde cvs :-)

As was pointed out, ns is already under CVS.  We've made daily
snapshots available for years, and anonymous CVS access for the last
couple of months.

There would be some advantage to pick up Source Forge's bug and patch
tracking services.  Other than that, is there much at source forge
that isn't currently already provided?

(We are currently moving otcl and tclcl to Source Forge.  When we have
more experience with that, I can judge better.  So far my biggest
gripe is that the bug form doesn't force users to include details like
OS and version.)

>On Tue, 7 Aug 2001, Neundorf Alexander wrote:
>
>> 	Well, most people (at least me) start with small patches,
>> which are not really worth posting if there is a more or less high
>> barrier :-(
>
>Yes, they are. Post these small patches to the mailing list, which
>gives you the right to bitch about how they weren't committed the next
>time the problem is encountered. At least the information is there for
>others to use.

I hope that we pick up small patches (that fix specific bugs) pretty
quickly.  If we miss them, please remind us.  (Developers here should
send mail to patch authors when the patches go in.)

>> 	One example: the gsm/gprs extension from Richa Jain would be
>> a very good candidate for ns, or the BlueHoc from IBM,
>
>those are large extensions adding new functionality rather than useful
>fixes/patches.

None of these are at all "small patches".  We've looked very seriously
at some of these.  We hope to get a bluetooth implementation in.

To use that as an example, though, Bluetooth's wireless model is
fairly different from the existing 802.11 code since BT has clusters.
To do this properly requires blending the two models.  This is a fair
amount of work, but it's required if ns is to be maintainable.  Ns
doesn't need two parallel wireless network architectures!

Also, to integrate ANYTHING big requires that we be able to maintain
it.  Thus getting code involves also getting test suites and
documentation (if possible).  This also takes time and interaction
with the authors.

(The example that Lloyd brought up was Snoop.  It went in, but without
a test suite it got broken.  Since then we've raised the bar about
what gets integrated.)

>> > Couple that with a bsdish model (knowledgeable few doing little after
>> > careful thought) rather than linux development model (clueless many
>> > doing lots - ns isn't a kernel, and spotting simulation errors needs
>> > greater clue than whining that the latest kernel wouldn't boot) and
>> > lack of available time to test and commit patches posted to the
>> > list... goodbye, third-party synergy. 

It's easy to wax rhapsodic about the cathedral vs. the bazaar.
Like most projects (tcl, python, etc.) we're trying to cut a
reasonable path somewhere in the middle, subject to very limited
resources (ns has never had more than 1-2 people working on it full
time).

That said, we're very open to constructive criticism about the
development process.

   -John Heidemann