At my company we started to use this http://www.reviewboard.org/
Integrated with hg I suggest to start using this integrated with the main web2py repository. Enviado via iPhone Em 30/10/2010, às 21:33, mart <[email protected]> escreveu: > BTW - have you seen Mondrian? - is built on Perforce. > > http://video.google.com/videoplay?docid=-8502904076440714866# > > Mart > > > On Oct 30, 7:24 pm, mart <[email protected]> wrote: >> Hey, >> >> Would it make sense not to pull the apps that get built against #head >> revision (unless the goal is to test the apps themselves) and >> preferably just pull the code line it self @ #head revision? (follow >> up on this in next paragraph) And also, I don't know where things >> stand wrt bug tracking, but an important consideration are the bug >> fixes ("does this build contain the fix for Bug X?"). Typically when >> bugs get resolved/closed, they get verified on a clean slate, then >> once validated & blessed (or rejected), the fix can be made public. >> >> I think the process is pretty close to what Thadeus mentioned, but >> would add the integration to bug tracking (this data is usually made >> part of the release notes specifically instead of a description typed >> in @ commit time). if the desire is automation (smoke tests) that I >> would store the raw data of the "generic app" in some dedicated >> tables, then re-populate the all-encompassing app with current data. >> By always grabbing latest_row, you keep the previous data for the >> previous build/release intact and in the correct place (so you don't >> need to change the test process from release to release, and you have >> the the build process insert a new set of records @ build time >> referencing the current build. With this, you also have >> reproducibility if needed. >> >> Last point, and I know I am persistently annoying with this, but >> mercurial, IMHO, sucks, sucks a lot. Personally I would use nothing >> less then the best out there, Perforce, specially if considering >> automated testing (again IMHO, but at least a fairly well supported >> statement :)). web2py is Open source, Perforce does give additional >> user licenses to open source projects (I'm sure Massimo would only >> need to make the request (which is online @ perforce .com btw). I >> mention that here because, good testing processes should be well >> integrated to source control. and for the web2py user, offering time >> for testing, a local instance of the perforce server can be installed, >> absolutely free of charge (with a max of 2 user licenses per server - >> more than enough for "remote workers" who can very easily keep in sync >> with the "main web2py" server (I work from home (Quebec, Canada), work >> for an American based company (HQ in Sunnyvale) - and that is how I do >> my work, with my local p4D. works like a charm). Anyways, enough of >> that, just thought I'd find another reason to slide that in ;) >> >> regards, >> Mart :) >> >> On Oct 30, 2:58 pm, Luther Goh Lu Feng <[email protected]> wrote: >> >>> It is reasonable to suggest a universal test app that will assist in >>> the quality assurance of web2py. But I wonder if this will always have >>> 100% test coverage, given that bugs may appear even when writing test >>> cases. This is still a good idea compared to not having a test suite. >> >>> However, I think I would have a greater sense of security if I am able >>> to test the apps I have written against the nightly/trunk build. >> >>> On Oct 31, 1:46 am, Thadeus Burgess <[email protected]> wrote: >> >>>> Where should the list of apps come from? I think this is the biggest >>>> question. >> >>>> -- >>>> Thadeus >> >>>> On Sat, Oct 30, 2010 at 12:46 PM, Thadeus Burgess >>>> <[email protected]>wrote: >> >>>>> Someone writes a script to automate the process. Have a list of apps that >>>>> we want to be sure are tested and working. The script will download web2py >>>>> testing, copy the apps to the downloaded version, fire a process fork to >>>>> start that web2py, use urllib or httplib to navigate to each of the apps >>>>> pages to verify that things are working. If a response code of 500 is ever >>>>> received then go get the error ticket and store it somewhere central >>>>> including which app it came from. >> >>>>> -- >>>>> Thadeus >> >>>>> On Sat, Oct 30, 2010 at 9:25 AM, Luther Goh Lu Feng >>>>> <[email protected]>wrote: >> >>>>>> On Oct 30, 7:05 am, mdipierro <[email protected]> wrote: >>>>>>> Normally it goes to the nightly build, perhaps not exactly the latest >>>>>>> but something very close. The bug in question has been there for about >>>>>>> one week. The problem is that nobody tests the nightly build. >> >>>>>>> Massimo >> >>>>>> I would love to have a way to test non stable builds easily with my >>>>>> existing apps. How does one do so besides downloading the trunk/ >>>>>> nightly build, and then exporting the apps from stable web2py and then >>>>>> import to the trunk/nightly web2py? >> >>
