[Ns-developers] new ns-2 software contributions

[Gavin Holland]

As a long-time ns2 user, I agree more with Lloyd.  Most of my 
colleagues in school grabbed one version of the code and stuck
with it throughout their graduate career because it was simply
too time-consuming to keep porting personal modifications to
new releases.  Likewise, since most often these changes are 
research/experimental in nature there is no desire to see them
imported into a release until you've had a chance to exploit
and publish your work, which may be months or years after 
writing.

I would tend to favor a fall/spring/summer major release 
schedule, with bugs posted as separate "patches" to the major
release.  That way, if I'm working on a protocol and I notice
something's wrong, I can scan the "bugs" list and apply only
the patch(es) needed to fix that bug (hopefully avoiding a
major port of my code).  I know it's not the best solution as
a developer/maintainer, but I think it might be more practical
for the general ns2 user.

-Gavin




> -----Original Message-----
> From: ns-developers-bounces at ISI.EDU 
> [mailto:ns-developers-bounces at ISI.EDU] On Behalf Of Lloyd Wood
> Sent: Thursday, March 31, 2005 5:10 AM
> To: Mathieu Lacage
> Cc: ns-devel
> Subject: Re: [Ns-developers] new ns-2 software contributions
> 
> 
> On Thu, 31 Mar 2005, Mathieu Lacage wrote:
> 
> > > > 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
> 
> What, you can't put their work as a delta to a release into an
> individual branch off that release, then merge their code into the
> main trunk later? Why advocate tags and branches if you're not going
> to use them?
> 
> (The advantage of having few releases is that it's clear what old
> release contributors should start from.)
> 
> >   - 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.
> 
> Quite insulting to users, I've always thought. Really, open source is
> just externalising its costs here.
> 
> Technically, ns releases a snapshot every day. The main point of an
> improved release process, I think, would be to discourage people doing
> development work building off snapshots they've grabbed that seem to
> work for their purposes (everything I ever did with ns was with
> snapshots), and get them to migrate towards clearly-defined points in
> the process.
> 
> For teaching and much grad project work, one solid trunk release (with
> binaries, installers etc.) early in each academic year meets their
> needs and gives them much-needed stability throughout that year.
> 
> But, okay, that's no good for development. For interim trunk releases
> marked for 'research/development' (less hand-holding, no binaries), no
> less than three months should elapse between them imo.
> 
> > 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.
> 
> I think you underestimate the difficulties that will result from
> merging branches back into trunk with ns. Conflict resolution will
> require some effort.
> 
> At worst, branch development encourages and reinforces internal
> 'forking' of ns - feature A was developed separately of feature B, and
> they can't be configured together even after their branches collapse.
> 
> L.
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at eim.surrey.ac.uk>
>