[Ns-developers] new ns-2 software contributions

[Mathieu Lacage]

On Thu, 2005-03-31 at 14:10 +0100, Lloyd Wood wrote:
> 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?

Yes, you can do this but if contributors start working from the latest
stable release, their patches will necessarily be bigger and thus harder
to integrate if the latest stable release is older.

> (The advantage of having few releases is that it's clear what old
> release contributors should start from.)

What do you mean ?

> >   - 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.

Yes, the bad open source projects do this but this is not what I am
advocating here. My proposal is not: "release something, stop worrying
about it". My proposal is: "release X, wait for bug reports, fix bugs,
release X.1 asap, X.2 if needed, X.3 if needed, all this from a single
CVS branch". 

This will ensure that users help you with QA and that they get good
stable releases. Those who can't afford the testing will go the stabler
releases X.x. A lot of open source projects do this without too much
yelling from their users, including some very large projects with very
large user bases. I see no reason why it would not work for ns-2.

The alternative, is, of course to do all QAing internally but I fail to
see who would provide this manpower for ns-2. Furthermore, this kind of
"closed" (no negative connotation meant) environment rarely improves the
probability of external contributors doing something useful which might
not be a concern for you but which is a showstopper to me.
  
> 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.

yes.

> 
> 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.

I don't know much about the needs of teaching but I fail to see why you
could not get your users to stick with a given version number,
independently of the latest stable release of the ns-2 project. 

It is clear that the stability needs of various users are quite
different which is why you never delete the older releases from your ftp
server.

> 
> 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.

I have done this on some large(r) projects, and I see no reason why it
would not work here. I do not claim this will solve all problems but it
should make the process of timely releasing and maintaining release
stability/quality easier at the cost of more costly merges.

> 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.

I have never seen this sort of problem in the projects I worked on.

Mathieu