Dear Mart, Your help is very much appreciated. In particular because I am not very knowledgeable about this aspect. I am old fashion and for me the less I use mercurial the better. For example I keep one single branch of web2py. I simply apply patches, test them, and either revert or commit. This model has worked well for me and I would not like to change it.
I too am uneasy with the idea of freezing but not with the idea of a testing period. How do you suggest we proceed? Massimo On Aug 22, 4:30 am, mart <[email protected]> wrote: > Good evening all, > > I hope no one takes offense by me jumping in, but I couldn't help > myself as the thread's subject got my attention (release management is > what I do). If you'll allow me, I'm just curious as to the narure of > your current branching strategy wrt the subject of the thread? In my > experience, freezing a code line is rarely beneficial, least of all to > the release going forward. So, was wondering if finding the correct > branching strategy (as well as defining an appropriately well matching > high level root folder structure in your source CSM) would help in > sorting out such things as separating out and accommodating the need > for stability, moving forward and any iterative requirements in your > release cycles? (I heard someone last year year - obviously someone of > the newer generation - call this "the need for speed" ;) ) But > regardless, if at all interested I'd be happy to do my part and help > out in any way I can if such plans are being considered. BTW - I was > hired to revamp and restructure release management processes last > spring for US based company, and web2py (with some Flex pieces in it > for demo purposes) was what I used to to showcase and spread the word > about the proposed changes :) > > On another note: > I saw that some PDF libs were on there way for web2py???? Awesome! I > am looking forward to that! :) I made a web2py app a few weeks ago > (mixing the ReportLab's tool kit and Flex/iFrames) so that the kids in > my daughter's violin class (yeah ok, this may be a little weird, > but...) could generate fingerboard position markers (which are then > convert to printable PDF templates) so that the kids could create the > exact position markers for their instrument (I think she hates things > that are pitchy). Anyways, did not want to use LiveCycle data services > (with flex) for this (although it does do some good things), and even > though the results I got with what I used were a little ok (or most > probably, the problematic parts had something to do with the guy > writing the code :) ), generating PDF with good tooling will be great! > I'm already a fan! :) > > Thanks, > Mart :) > > On Aug 22, 1:02 am, Jason Brower <[email protected]> wrote: > > > Again I think we have more pressure for testing tools. Which I agree > > on. > > BR, > > Jason > > > On Sun, 2010-08-22 at 00:32 -0400, Andrew Thompson wrote: > > > On 8/20/2010 4:54 PM, Phyo Arkar wrote: > > > > -bug-squishing-contest , > > > > -Stress test, Test everything , try to crash web2py etc. > > > > Could we build an app to act as a test harness? > > > > Or a script to build an app per a test case, evaluate it, then destroy > > > that app, loop etc. > > > > Turning bug reports into test cases causes regressions to be noticed > > > quicker I would think.
