[Opensim-dev] to branch or to break?

Sean Dague sean at dague.net
Thu Nov 1 14:16:03 UTC 2007


On Thu, Nov 01, 2007 at 12:04:39PM +0000, Michael Wright wrote:
> As some people know there has been some talk on what needs done for
> decent Communications. And also the partly related work on dynamically
> creating and removing regions at runtime. 
> 
> Trying to just make some changes to fix some problems with creating
> new regions (at other times than startup) is showing how hard it is to
> do much without the risk of breaking other things, like grid mode. And
> I think removing regions will be even worse as we don't have any way
> in place to tell the grid servers that a region has been removed. Two
> related things here are I most likely don't have the time to get all
> my changes working in grid mode straight away, so would like to be
> able to test them in standalone mode first. 

There is some mechanism in place today, because I've seen it work.
Where a region goes offline because it crashed, and the restarting it
pops it back into view in the client.  This is in grid mode.

> Also I am really not in favour of doing much work on the current grid
> mode code without at least some plan of how we want to take it
> forward. I think most of us are in agreement that the current protocol
> needs redesigning or at least big changes.

It might help in the discussion and the design to state what we have,
and where it is deficient.  Previously we haven't had design discussions
on list, but previously we were also a small enough group that you could
always get a quorum on IRC, and that each others work was issolated
enough that it wasn't colliding very often.

Especially given that this is going to have massive implications on
physics integration, which is still quite flakey.

> Just trying to decouple some of these things is proving very hard. So
> I'm starting to think we are in a situation like we were with the move
> from 0.2 - 0.3. Where we need to either say that trunk may have some
> things broke in it for a while or we create a branch. Last time we
> went with a branch but think we all felt that we should have went with
> breaking trunk and creating a "stable" branch. 

Unfortunately, as history has shown, branches don't really work in
subversion.  Every previous branch has forced whole sale replacement of
trunk.  In 0.2 - 0.3 there were 4 or 5 committers?  Now we're at 13.
I'm concerned that a branch model means that a lot of other people's
work on the project effectively has to freeze.  

We already saw a bunch of Tleiades work lost because he took more than 2
days to commit a chunk of code, and as such assets stalled out for a
bit.

> So I think we need to decide, then we can get on with the talk about
> what actually needs done and how.

I'd really like us to collectively try to figure out a way that we can
do this without branching, and without breaking the tree.  Perhaps I'm
naive, but we've done some pretty reasonable interitive major switch
outs over the last couple of months without that kind of breakage.
Defining some new interface up front, plumbing that interface into the
existing code paths, then switching out the code paths may take a bit
more time, but it does have the advantage of letting everyone continue
to plunge forward and not sacrificing momentum.

     -Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071101/6d9cb510/attachment-0001.pgp>


More information about the Opensim-dev mailing list