Mark, Your offer is quite generous, however most of us already have test regions set up to facilitate development. On the subject of mercurial, we spent several developer-months switching over to git and several more months after that getting used to it and becoming productive again. I doubt you'll mind many of us willing to switch again to yet another revision control system and spending the time to familiarize ourselves with it.
What may be more useful is coordinated independent testing *specifically for the purpose of testing* with properly designed and documented plans, goals, methods, and well documented results. If good quality tests can be run independently of development and these tests produce valid, repeatable results with little overhead required from the developers, and the results can be provided to developers in a timely manner, then I suspect it could significantly improve development efforts. If developers need to spend time setting up new test regions in addition to those they already have, then it's likely it will slow overall development down. -dahlia On Mon, Feb 22, 2010 at 3:27 PM, Mark Malewski <mark.malew...@gmail.com>wrote: > 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.malew...@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 <cmick...@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, <d...@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@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > >
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
