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

[Kyle Hamilton]

I wish trunk would be incrementally more useful and incrementally less
unstable at every revision.  Unfortunately, this is obviously a
pipe-dream.

I'd like to see a 'stable' branching system of some kind, and every
time there's a new stable candidate I'd like to see a diff produced
and examined for Justin's 2 weeks to see if there's anything that's
obviously broken between the former stable and the new candidate.
Once it's determined to be stable enough, it would get committed to
trunk and a new -stable branch forked from that revision.

Two downsides to this suggestion is that it means that everyone's
going to need to become really familiar with the process of re-basing
their local copy, and everyone's going to need to listen to the
release coordinator to know when to re-base their locals.  The former
is a documentation problem (write a page on the wiki to describe how
to do it); the latter is an announcement problem.  (I'd suggest the
creation of a new opensim-announce list that only the release
coordinator(s) can send to, and which has a membership list precisely
equal to the opensim-dev list?  This would allow the announcements to
be handled separately, but allow memberships to be handled only by a
single administration request... but I don't know how good of an idea
it is.)

+1 to additional unit tests.  (In fact, I really like the idea of
writing a test that's first guaranteed to fail, and only then write
the code to make it pass.)

+1 to a many-branched trunk.  The fewer revisions between branch and
trunk, the more easily integrated it is when it comes time to bump it.
 Otherwise, it becomes a nightmare.

-Kyle H

On Mon, Dec 15, 2008 at 12:52 AM, Stefan Andersson
<stefan at tribalmedia.se> wrote:
>> > I can see some people being hesitant to commit to supporting this
>> > because they don't want to worry about committing to two branches each
>> > time they have a fix, or they don't want to maintain two slightly
>> > different code bases.
>
> This would be 100% optional, and probably done by a small group of devotees
> (like me and Darren, as in the case of the last stable) whose only humbly
> wish is to get a heads-up from peple whenever a good, clean bug fix has been
> committed.
>
>> > Bug reports could also become more of a hassle as
>> > some users will report bugs against the trunk, while others against the
>> > stable branch.
>
> My concept will not work if we don't re-branch new stables reasonably often
> - the heart of the concept is that 'stable' should not deviate from trunk
> very far at all, just minor bug fixes and changes deemed 'harmless'.
>
> The reason, of course, is exactly that we should be reasonably certain a bug
> exists in both branches.
>
> Apart from that, we have that same problem on every revision. The user needs
> to tell us what revision (or trunk) the error is on.
>
>> > Having said that, I can see a benefit for having a stable branch.
>> > Ideally it would follow trunk pretty closely, and when it becomes
>> > challenging to apply patches to both trees without too much massaging,
>> > it's time to do final stabilization on that final branch and release.
>
> That was the general idea. Bu tI would say, given the agile nature of the
> project, that we just _define_ that, "when bug fixes does not apply cleanly,
> it's an indication we should bump the number".
>
>> > I would like to encourage you to give this a try.
>
> We already are. At the moment, I'm just waiting for people to tell me we
> have a reasonably stable revision that I can branch again.
>
>> > In the meantime, don't expect too much
>> > commitment from all the devs, and be prepared to take responsibility
>> > for this stable branch. After some time, we can all look back at how
>> > things went and decide what to do in the future.
>
> This is basically what happened with 0.6.0-stable. Only thing we need is
> help with finding the revisions, and to get tipped about good
> stabilizing fixes in trunk.
>
>> The problem with stable branches... is they aren't. If you add code to
>> a branch, you have the potential to break it, especially on a source
>> base as complex as OpenSim.
>
> True as that may be, of course it depends on what type of code you add, and
> how much.
>
> If we were talking doing serious work on a 'real' branch, I would be much
> more inclined to agree, but the point of this is to keep it ligth, agile and
> to a minimum of deviation.
>
>> Personally, I'm going to stay focused on trunk, that's where my time and
>> interest lies.
>
> Then do. I'm not trying to rally resources devoted into this, I'm merely
> trying to work out a process that would work given the nature of the OpenSim
> project.
>
> From working with 0.6.0-stable I'm more convinced than ever that it's
> needed,
>   * for the people wanting to do public beta grade services based on OpenSim
>   * for developers that want to code on modules without sudden mysterious
> breaks
>   * and for the devs that want to debug without new parameters being
> introduced.
>
> Now of course, vendor branches is one other way to do this, but what we at
> Tribal realized, was that since we're coding in modules, all we used the
> vendor branch for was for stabilizing fixes.
>
> And since that work would otherwise be duplicated in a number of dev teams,
> it makes sense to share that work.
>
>> A better approach to stability than stable branches is
>> to help create unit tests for trunk.
>
> Which of course not only is a totally untestable assertion, but also has to
> be weighted against a pragmatical timescale.
>
>> This helps contain behavior, and
>> drives towards code correctness for parts of the tree.
>
> +1 to extended testing.
>
>> I'd encourage people
>> spend time on enhancing automated testing instead of doing point in time
>> stable branches.
>
> I'd encourage people to do both, as I believe compairing the efforts would
> be like compairing apples to pears. One is about testing the correctness of
> the code in a point of time, the other is to provide an aggregate of
> experience to facilitate a work process.
>
> At heart, I'm an agile coder. I do believe that trunk should always be in a
> shippable state, but to think that that means you should always ship trunk,
> is to over-simplify.
>
> /Stefan
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>