[Opensim-dev] Status of presence refactor?

[Mark Malewski]

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/11d0bc57/attachment-0001.html>