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

[Ryan McDougall]

I encourage some sort of stability policy, even if its only a 1 week
process of polishing up a be-knighted release.

I would also like to take this opportunity to propose time-based
releases, like GNOME or Fedora, where you work for X months, stabilize
for Y weeks, then tag what you got, and restart the process again. I
think it provides a lot of simplicity in planning, removes the
potential of having multiple active branches, and makes it easy to
identify where patches should go.

Cheers,

On Thu, Dec 11, 2008 at 1:23 PM, Mariusz Nowostawski
<mariusz at nowostawski.org> wrote:
> Sean Dague wrote:
>> Mike Mazur wrote:
>>
>>> Hi,
>>>
>>> On Wed, 10 Dec 2008 14:29:37 +0100
>>> Stefan Andersson <stefan at tribalmedia.se> wrote:
>>>
>>>
>>>> Since trunk is currently considered anything but stable, are people
>>>> feeling up for trying out branching a stable version before we do
>>>> this, and then actually work on that branch to stabilize it?
>>>>
>>> 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. Bug reports could also become more of a hassle as
>>> some users will report bugs against the trunk, while others against the
>>> stable branch.
>>>
>>> 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.
>>>
>>> I would like to encourage you to give this a try. If it works it's
>>> likely to convince the other developers to play along, and if it fails,
>>> we've learned our lesson. 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.
>>>
>>
>> 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.
>>
>> Personally, I'm going to stay focused on trunk, that's where my time and
>> interest lies.  A better approach to stability than stable branches is
>> to help create unit tests for trunk.  This helps contain behavior, and
>> drives towards code correctness for parts of the tree.  Over time,
>> that's the only way to have a truly stable tree.  It has prevented
>> dozens of bugs from going into the tree already.  I'd encourage people
>> spend time on enhancing automated testing instead of doing point in time
>> stable branches.
>>
>
>
> Hi,
>
> I agree with all that Mike said above (and, at the same time, I also
> agree with all that Sean said: it is good to have more tests, and it is
> easier for developers to just have trunk to commit to. However... ;)
> Regardless of its alpha status, OpenSim is already being used in a
> variety of deployments. This is the reality - OpenSim is being used, and
> users are part of the equation (officially or not, that's how it is
> today). The lack of any form of proper release system is making it
> difficult for those users to strike the balance between relative
> stability and the feature set of OpenSim snapshot that is being
> deployed. Each, so called, "OpenSim release", has its problems, and
> users tend to "fix" those problems by following the trunk, which makes
> the current "release" model pretty meaningless. New trunk revision often
> fixes some of the old problems, but introduces new ones. For users that
> maintain and manage any form of OpenSim deployment, this represents a
> major hassle, and it also makes OpenSim harder to use (and perhaps even
> somewhat reduces its perceived value). I'm not talking here about
> developers - I'm talking here about people that use OpenSim. E.g. we use
> OpenSim in the national virtual world grid that runs over research
> network in New Zealand. The project is all run by volunteers and
> university staff. We do not contribute much code, however, given enough
> time, interest and traction of the project itself, there is a growing
> users and developers base that study and gain experience with OpenSim
> technology. Following the trunk and maintaning a reasonable level of
> stability in the grid is pretty much a full time job. It wouldn't be, if
> there was a slightly better stable release system.
> Of course, one can say that the users are not important at this stage,
> that OpenSim is only for developers to have fun, work on the trunk, and
> do not spend time committing bug fixes into more than a single branch.
> But, I am not sure all of the developers would agree with that. I
> honestly believe that even at this stage, users are, somewhat, relevant
> to the entire process, and helping the users will ultimately benefit the
> project in the long run. Stable branches are of great help here. And
> also, one of the easiest solutions to a relative stability of releases.
> Users would use those stable branches, and potentially contribute back
> comments and perhaps even patches, that are made against those stable
> branches. Lots of open source project use that model successfully and I
> agree with Mike that perhaps you folks should give it a try.
>
> --
> cheers
> Mariusz
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>