<div>Devs,</div><div><br></div><div>I can setup 4 "sandbox" servers for tagged release bug testing:</div><div><br></div><div>Server 1: Ubuntu Linux w/ SQ Lite </div><div>Server 2: Ubuntu Linux w/ MySQL</div><div>
Server 3: Windows 2008 R2 w/ SQ Lite</div><div><div>Server 4: Windows 2008 R2 w/ MySQL</div><div><br></div></div><div>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).</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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).</div><div><br></div><div><b><i>> We can, by this order:<br>
> 1) merge presence-refactor into master<br>> 2) create a sop-refactor branch from master immediately after<br></i></b></div><br>This way we're not "under the gun" to get the merge fixed prior to the 0.7 RC.<div>
<br></div><div>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<br><div><br></div><div>Then just release the 0.6.9.x tag (after fixes) as a 0.7.1 release (an update to the 0.7 RC).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> Mark</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Mon, Feb 22, 2010 at 5:09 PM, Mark Malewski <span dir="ltr"><<a href="mailto:mark.malewski@gmail.com">mark.malewski@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>Mic,</div><div><br></div><div>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?</div>
<div class="im">
<div><br></div><b><i>> Can I make one request... Can we tag the current master as </i></b></div><div><div class="im"><b><i>> 0.6.9 (or something) prior to the merge? <br></i></b><br></div><div>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?</div>
<div><br></div><div>That way we have two tags (a 0.6.8.x tag prior to merge and a 0.6.9.x tag after merge).</div><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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?</div><div><br></div><div>This way the current state could be tagged as a 0.6.8.x tag, then we can use 0.6.9.x for: </div>
<div class="im">
<div><br></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">1) merge presence-refactor into master<br>2) create a sop-refactor branch from master immediately after</span></div>
<div><br></div></div><div>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.</div>
<div><br></div><font color="#888888"><div> Mark</div></font><div><div></div><div class="h5"><div><br></div><div><br><div class="gmail_quote">On Mon, Feb 22, 2010 at 10:20 AM, Mic Bowman <span dir="ltr"><<a href="mailto:cmickeyb@gmail.com" target="_blank">cmickeyb@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Can I make one request... Can we tag the current master as 0.6.9 (or something) prior to the merge? <br><font color="#888888">--mic</font><div>
<div></div><div><br><br><br><div class="gmail_quote">On Mon, Feb 22, 2010 at 8:13 AM, <span dir="ltr"><<a href="mailto:diva@metaverseink.com" target="_blank">diva@metaverseink.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">We can, by this order:<br>
1) merge presence-refactor into master<br>
2) create a sop-refactor branch from master immediately after<br>
3) create a 0.7 branch some time later<br>
<br>
I would like to propose that the sop refactoring work be done in a<br>
branch rather than in the master branch, similar to what we did for the<br>
services refactoring. It works pretty well -- gives the refactoring devs<br>
peace of mind to leave things unstable and isolates the master branch<br>
from prolonged instability.<br>
<br>
Also, are there any suggestions for Adam before he starts doing this? He<br>
sent out a document some time ago, but there wasn't a lot of feedback or<br>
discussion. Are there any alternatives or wishes for his proposed work?<br>
<br>
Justin Clark-Casey wrote:<br>
> Frisby, Adam wrote:<br>
>> 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?<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> 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.<br>
><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>