[Opensim-dev] Status of presence refactor?

Mon Feb 22 23:27:22 UTC 2010

Devs,

I can setup 4 "sandbox" servers for tagged release bug testing:

Server 1:  Ubuntu Linux w/ SQ Lite
Server 2: Ubuntu Linux w/ MySQL
Server 3: Windows 2008 R2 w/ SQ Lite
Server 4: Windows 2008 R2 w/ MySQL

Then the dev's can decide which tagged versions they would like to install
on which boxes.  That way they can test the 0.6.8.x series (pre-merge) and
0.6.9.x series (post-merge).

I could always bring another 4 servers online (and use four for 0.6.8.x and
four for 0.6.9.x) if need be.

But at least this way we have a wide range of platforms for testing.  That
way the dev's can just roll stuff out, and have "sandboxes" for bug
testing/fixing things and development of the upcoming 0.7 RC.

If we can't get the merge's working smoothly before the 0.7 RC, then we can
always save the 0.6.9.x branch for a future 0.7.1 release (with updated
merges).

*> We can, by this order:
> 1) merge presence-refactor into master
> 2) create a sop-refactor branch from master immediately after
*

This way we're not "under the gun" to get the merge fixed prior to the 0.7
RC.

If too much is broken after the merge, then we can always just release the
0.6.8.x tag as the 0.7 RC

Then just release the 0.6.9.x tag (after fixes) as a 0.7.1 release (an
update to the 0.7 RC).

If the fixes after the merge are easy, then we can always release the
0.6.9.x tag as the 0.7 RC.  If the fixes after the merge are ugly (and too
time consuming) then we can just revert back to the 0.6.8.x tag and release
that as 0.7 RC, and then save the 0.6.9.x for the 0.7.1 RC update.

This way we can have a 0.7 RC stable released fairly soon, and also have a
0.7.1 RC that follows shortly (with the merge).

This would at least give the documenters and bug testers time to "beat up"
the servers, and do bug testing, and also work on updating documentation
(for the new upcoming releases) and get tutorial/manuals/documents written
prior to the 0.7 RC getting released.

With 4 servers dedicated to the 0.7 RC (two for 0.6.8.x and two for
0.6.9.x), that will at least give developers a nice "sandbox" platform for
developing/working, and also give the bug testers the ability to move
between boxes for documenting/mantis bug reporting/bug testing, and test
everything thoroughly prior to the formal 0.7 RC release.

                  Mark

On Mon, Feb 22, 2010 at 5:09 PM, Mark Malewski <mark.malewski at gmail.com>wrote:

> Mic,
>
> It seems like a good request.  I like the idea of a tag, but maybe we
> should create two tags?  Use a 0.6.8.x tag prior to the merge, and a 0.6.9.x
> tag after the merge?  Then save the 0.7 tag for the stable RC?
>
> *> Can I make one request... Can we tag the current master as *
> *> 0.6.9 (or something) prior to the merge?
> *
> Maybe just tag the current master as a 0.6.8.x prior to the merge, then
> just create a 0.6.9.x tag after the merge?
>
> That way we have two tags (a 0.6.8.x tag prior to merge and a 0.6.9.x tag
> after merge).
>
> Then we can work on bug testing, and bug fixing and then decide which of
> the two tags we'll use for the 0.7 RC.  If the merge breaks too many things,
> or is too unstable we can just revert to the 0.6.8.x tag series.
>
> If the merge doesn't hurt/damage things too badly, and the fixes can all be
> done fairly easily, then we can use the 0.6.9.x tag to use for a 0.7 stable
> RC for the final release candidate (after it goes through the whole formal
> RC bug-testing/bug-fixing release candidate process).
>
> This way at least we have two separate tags (0.6.8.x and 0.6.9.x) that we
> can use as tagged reference points for testing, prior to the 0.7 RC?
>
> This way the current state could be tagged as a 0.6.8.x tag, then we can
> use 0.6.9.x for:
>
> 1) merge presence-refactor into master
> 2) create a sop-refactor branch from master immediately after
>
> Then depending on how much work needs to be done after the merge of
> "presence-refactor" into master, and the "sop-refactor" branch work that
> needs to be done.  This way we can have two separate tagged releases that we
> can use for bug testing and bug reporting.  Then depending on how much is
> broken (and what the timeline is to fix the bugs) then we'll either just use
> either the 0.6.8.x tag (pre-merge) or the 0.6.9.x  tag (post merge) for the
> stable 0.7 RC.
>
>                 Mark
>
>
> On Mon, Feb 22, 2010 at 10:20 AM, Mic Bowman <cmickeyb at gmail.com> wrote:
>
>> Can I make one request... Can we tag the current master as 0.6.9 (or
>> something) prior to the merge?
>> --mic
>>
>>
>>
>> On Mon, Feb 22, 2010 at 8:13 AM, <diva at metaverseink.com> wrote:
>>
>>> We can, by this order:
>>> 1) merge presence-refactor into master
>>> 2) create a sop-refactor branch from master immediately after
>>> 3) create a 0.7 branch some time later
>>>
>>> I would like to propose that the sop refactoring work be done in a
>>> branch rather than in the master branch, similar to what we did for the
>>> services refactoring. It works pretty well -- gives the refactoring devs
>>> peace of mind to leave things unstable and isolates the master branch
>>> from prolonged instability.
>>>
>>> Also, are there any suggestions for Adam before he starts doing this? He
>>> sent out a document some time ago, but there wasn't a lot of feedback or
>>> discussion. Are there any alternatives or wishes for his proposed work?
>>>
>>> Justin Clark-Casey wrote:
>>> > Frisby, Adam wrote:
>>> >> I would like to start the SOP refactor fairly soon - what if once 0.7
>>> is tagged for the RC process; I go and and make a new branch; we can sic
>>> testers on the presence-branch, while dev happens on the branch I tag?
>>> >
>>> > My concern with branching for 0.7 release candidates immediately after
>>> the presence-refactor merge is that we won't get everybody helping to iron
>>> out the inevitable hiccups since most people follow master.  Waiting a
>>> couple of weeks for at least some of this to happen is the minimum, I feel.
>>>  Ideally, I'd like that to be longer but I know that you and other folk want
>>> to press ahead.
>>> >
>>> > I guess some of this depends on how disruptive the refactor is.  What
>>> do you think?  I'm assuming there will be breakage but perhaps I'm wrong?
>>> >
>>> > Of course, I guess you could create a separate sop-refactor branch at
>>> any point and start work there, possibly merging back to master and
>>> continuing in master once 0.7 RC has been branched.
>>> >
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20100222/0a4abe5e/attachment-0001.html>