Hi Again, So, spending the day with my 3 girls certainly does provide perspective on requirements and how well attached we can be to them sometimes ;). That in mind, I certainly do understand your personal requirements on keeping what you know and what works for you (I respect old fashion ;) ). We can work with that, while hopefully bringing something efficient, scalable and most certainly flexible, while remaining respectful of what is important to Mr Di Pierro who brought us all here.
Although I haven't spent too much time with Mercurial, most concepts don't change, and implementation well... that's all it is really. I had look @ your src repository and I find it is very telling of how you do things and what is important. As I understand, the goal is to meet 2 separate requirements that inevitably impact one another with current structure. The desired outcome: no freeze of the code line while allowing for planned testing iterations to move forward (while enabling Mr Di Pierro to maintain those elements of the current model which are important to him). I think it's entirely doable and please don't hesitate to stop me if I get carried away... I would like to start, if there are no objections, by getting a high level understanding of current practices. So, I'll throw a few questions out there. (I will try t keep the number of questions short – although it may not appear that way). Perhaps, this could be taken to another area to minimize the ruckus? I like the idea of getting a group together and collaborate on developing a proposal. As the more input we have, the better we can serve this type of development model (the concept of contributors) in the web2py dev world in particular. I see that Mr Di Pierro commits all changes to the single branch (default). Here's are a few questions with that: Where do developers check-in or commit their changes while in development? Where does the src going to dev come from and at what frequency does it get synced with the reference code line (if at all) ? Is the reference code line stable (no changes) or is it in constant flux? Since Massimo, is doing the commits, I assume that everybody keeps a sandbox copy of the src? Is there a mechanism in place which makes sure that everyone is working off the same starting point? If not, how are merge conflicts handled presently? Does the code get reviewed before making its way to Massimo who will be committing the changes (or not committing)? As the “release guy”, my first and most important consumer of builds is QA - the testers usually get first dibs on my time ;) - as they are the ones blessing builds and enabling them to move to the next levels. I tend to want to have them in mind when writing automation and making sure they can interface as smoothly as possible to my automation with there own. When going to Test, what get's handed off (src or build)? Is there any regular automated/manual testing? Or is it the case where bigger testing efforts are done later in the release cycle? how are builds identified with those test results? Good release strategies do help, so here are just a few questions on that subject: Have you a defined plan for release strategies? (i.e. moving forward between releases from 1.83.x to1.84.x, .... to 1.90.x etc.) - or are releases treated as milestones? milestone strategies within those releases? how do you keep track of previous releases? So, depending on the extent of adherence to release practices we want to look at, there are many elements worthy of attention. I am ready and willing to spend time in helping web2py plan and implement release methodology (if that is desired) in line with your growth expectation (which I can only imagine it being very high). What I can do to start is setup a structure on Google (although i have noe clue yet what the procedures are yet to get that going... a simple sign up?) and play with a few ideas. So, where do we go from here, meaning how do we get a group of interested people to join in? I am open for discussion with anyone interested. Thanks, Mart :) On Aug 22, 1:11 pm, mart <msenecal...@gmail.com> wrote: > This is sounding like fun! My experience is mostly with Adobe (10 > years) working with cross-continent & distributed dev efforts. So, > getting the chance to work with the great folks from web2py on a > "contribution model" (for the lack of a better term) sounds real > exciting to me! :) > > thanks, > Mart :) > > On Aug 22, 12:12 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > I propose the people most competent and interested in this subject > > form a team to work on it. > > Call for help, setup a mailing list and an IRC channel. I will be > > happy to use/incorporate a testing suite. > > > Massimo > > > On Aug 22, 10:57 am, Paul Gerrard <p...@gerrardconsulting.com> wrote: > > > > Hi All, > > > > Like Mart - I'd better declare an interest and some knowledge in this > > > area. > > > > My company is Gerrard Consulting (www.gerrardconsulting.com) I'm very > > > active in the UK and European testing community and have written a > > > couple of books, done lots of conference work, host the UK Test > > > Management Forum (uktmf.com) etc. etc. I am using Web2py to create a > > > test management tool that we will use to support our testing services. > > > (It's mainly for test design and record keeping in large software > > > projects, rather than test execution). So I am very interested in a > > > rock-solid Web2py as my company will depend on it :O) > > > > Right now, I'm full-on writing code and testing as we launch in mid- > > > September. But I will be creating a performance/stress test for our > > > app as we'll be making a free subset of the functionality available on > > > our servers.Obviously scalability is a concenr for us. I'll probably > > > use The Grinder (http://grinder.sourceforge.net/) to stage these > > > tests, but that won't be for 5-7 weeks I think. > > > > I'd be very interested in collaborating to create some form of test > > > automation regime for the Web2py infrastructure and applications using > > > either available tools or maybe writing our own framework. (I'm > > > looking to build an interface from my tool to things like Fit/Fitnesse > > > (or replace them) and Selenium as I focus very much on acceptance > > > testing). This might be the subject of another thread, perhaps. > > > > Sorry for the length of this, but I thought I should declare my hand > > > and support for a 'stabilisation period'. > > > > Paul. > > > > On Aug 22, 2:25 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > 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 <msenecal...@gmail.com> 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 <encomp...@gmail.com> 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.- Hide quoted text - > > > > > - Show quoted text -
