[Ns-developers] ns-3.3 Release Planning -- Code Freeze isinEffect

[craigdo@ee.washington.edu]

> > [ ... ]
> >
> > > If I may offer a suggestion, I think it might be better to
> > > have a ns-3.3 branch besides a ns-3-dev:
> >
> > [ ... ]
> >
> > We have talked about this and I suspect it will happen; but to be
> > completely
> > and absolutely blunt, there was enough chaos in the last 
> major release that
> > I pushed back hard at the idea of adding to this release yet another
> > opportunity for confusion regarding what was checked into 
> which repo and
> > when and how and when it was all sequenced, integrated and tested.
> >
> >
> There is plenty of time to think on this, since Gustavo 
> suggests this for
> ns3.4.  But, we have been snapshotting the dev branch as a 
> release since we
> started, with the exception of 3.2.1, which was released as Gustavo
> suggested.  It keeps things simpler.  We can hold our patches 
> in our pockets
> (or start "experimental" branches to track our changes) until 
> the freeze is
> over.

Well, there are more issues than just how you propagate changes.  Of course,
we've decided that the details of the release process are up to the release
manager, but I have my reasons for holding ns-3-dev hostage for a short
while every release cycle.  Here are a few  justifications off the top of my
head:

1.  There is one place for code to go and therefore it is impossible to lose
synchronization between repos;
2.  A corollary is that it is impossible to lose track of dependencies
between patches going to multiple repos;
3.  It is impossible to mess up while applying different combinations or
subsets of changes to multiple repos;
4.  There is one place to document what is in the code (CHANGES) and the
release mgr won't have to play merge games there;
5.  There is one place to final test the code and one goal for everyone --
to make the release directory (ns-3-dev) work well;
6.  There cannot be a state where one branch is a step-child that undergoes
less testing or love;
7.  There are automated tests running on ns-3-dev already;
8.  Being release manager is already painful enough without adding more
time-consuming details.

I realize that from a developer or maintainer perspective, the ideal
situation would just be to commit to ns-3-dev and leave the details of how
the release is put together and tested to the release manager.  I'm not
going to sign up for that, though.  I am looking for a replacement, though,
who may be more easily convinced :-)

-- Craig