[Opensim-dev] Stable Branch pt III Was: RFC: Changing default script engine to xengine

[Justin Clark-Casey]

Mike Mazur wrote:> Hi,
> 
> On Wed, 10 Dec 2008 14:38:35 +0000
> Justin Clark-Casey <jjustincc at googlemail.com> wrote:
> 
>> I'm actually much more drawn to the idea that Adam proposed about a
>> month ago (and which I was negative on at the time) that we start
>> labeling odd minor versions as unstable and even versions as stable
>> (please correct me if I misinterpreted this).  Therefore, when we tag
>> 0.6.1 on the trunk this could perhaps be labeled as 0.6.1-unstable.
>>
>> The idea would be that the period between 0.6.1 and 0.6.2 would be as
>> short as possible.  In that period we would refrain from making any
>> changes that we think could destabilize the build, and preferably
>> concentrate on those which would improve stability.  Once we're happy
>> that the trunk is in a reasonable state then we would tag
>> 0.6.2-stable and move on with the next set of somewhat riskier
>> changes.
> 
> This worries me in that it imposes some rules on what work we can be
> doing on OpenSim. What if I have a great idea that I'd like to work on
> before the details become murky in my mind, but we're in a "stable
> patches only" phase? Given the distributed and varied nature of the
> development team, I wondering how this would benefit the project as a
> whole.

I would anticipate that a 'stable patches only' phases would be of about 2 weeks, assuming no stability problems.  This
is based on the amount of time that it seems to take for some problems to come out that only occur with long-running and
high traffic simulators and grids.  Stability problems would push this period out until we were happy that we had them
reasonably nailed.

Personally, I would hope that if you have any great ideas then you'd be able to write them down and come back to them
later when we've made the release.  The intervening period might even help you to see any flaws or better ways of coding
it (as is sometimes the case with me ;).

And to be honest, I think it's okay to have stuff which isn't stability related in the 'stable' period.  It's more that
people would hold back from making changes that they think could promote instability (e.g. a complete overhaul of the
Linden client stack, changes to the scene heartbeat code paths).  And even these would be fine as long with stuff such
as unit tests in place to catch mistakes - it really would be up to the individual to judge.

> 
> One way of achieving this is having two branches going on at the same
> time (the stable one and the unstable one), so that there is always
> somewhere I can commit my changes, regardless of their nature. Doesn't
> this bring us back to Stefan's original suggestion of having a stable
> branch?

Yeah.  As you've probably seen I'm quite a fan of unit tests, for the reasons that Sean outlined in a later reply.
However, I acknowledge that they aren't a panacea - for instance, they won't be able to catch deadlock problems and may
miss issues with long running high traffic simulators (possibly more advanced automated testing would help, though I
think this involves another order of complexity).  That's why I am sympathetic to the idea of an independent stable
branch where perhaps more long term testing and very controlled bug fixing could take place.

The problem, perhaps, is one of will, manpower and OpenSim maturity.  To do a really stable branch one would have quite
a few testers and developers pounding on it.  At the moment there is perhaps too much temptation to follow trunk since
that's where the shiny is (and the implementation of features 'missing' from the LL viewer's point of view).  I do think
that this will start to change as OpenSim code matures further.

For me personally, I probably need to keep concentrating on trunk for a while yet.  But I can see a point in the future
where having a stable release branch that only accepts bugs fixes and not new features could be a very valuable thing to
have for me.  Others might reach the stage where this becomes valuable much sooner.

-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com