[Opensim-dev] to branch or to break?

[Michael Wright]

I really think we have to do something. As I have spent the morning trying to do somethings but not getting anywhere because I'm so worried about breaking something else. I know Stefan feels exactly the same. It really is harming development with people running deployed grids and regions from trunk. Where it results in us not being able to do any thing major that has risks. I think this is even part of the reason that the project has slowed down in development over the last month. It feels like we are now in small bug fix/small change mode. When the code just isn't mature enough for that. We still don't know how a lot of things will need to work in the end. I think this project still needs to be in err more of a risk taking mode.

 By that I mean us programmers feel free do fix big things or make big restructoring changes when needed without thinking that they can't because it will take more than one commit and that means that its hard to add half the implementation and still have everything working. I actually think this is what most likely lead to Tleiades loss (which I am sorry for being the one who did the commit that caused him to lose that work), in that he was working on quite big changes and it was hard to make commits before it was all finished and still leave trunk in a fully working (as much as it every does) state. If we said trunk can be broke then he could have made those commits. 

I really strongly urge us to come up with a way of us being able to not feel scared of making changes. Else I worry for the future. I am very much in favour of Trunk being the place for active development, we just need to get people off the idea of updating to every new version of it. And just release "stable versions" in some way (tag/branch/ full binary release/whatever) every week or two (or three). 



Sean Dague <sean at dague.net> wrote: 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.
__________________________________________________________________
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


       
---------------------------------
 For ideas on reducing your carbon footprint visit Yahoo! For Good this month.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071101/fecd30a8/attachment-0001.html>