Hi all, Sounds like there's a little momentum in this :-)
Here's what I can contribute to the party: 1. Part of the test management tool I am writing is a 'case management' facility. It is basic, but it supports multiple case types. Cases can be issues/incidents/defects, to do/actions, and notifications to review changes to other entities in the system (in my case, requirements, stories, tests etc...). There is a messaging/ notifications module, uploads/attachments and a case notes history. This functionality is part of the system we will will make available as a free hosted option to Agile Development teams. I'd be delighted to offer this to "the team" to use. I benefit by getting feedback and ideas for improvement. I also get a little kudos with the testing market :O) 2. As a sideline we have (currently 4) servers colocated at a data centre that is a mile away from where I live (Maidenhead UK). Currently, all are using Windows 2008 and I have my dev web2py set up on one of them. I would like to deploy on Linux, I use Mysql at the moment - the only proprietary code I currently use is Windows and I want to be 100% open source. So I'd be happy to provide a Linux box for a Linux expert to set up apache/mail/web2py. I'm familiar with Ubuntu, but if there's a preferred distribution - please advise - I'll use that. I anticipate this would host the tools required of the team, plus my own development environment. I would deploy on another server. I guess there should be a mirror of the web2py team content somewhere else on the planet. (I could also use my Amazon web services account, but this is a tad more expensive for me). 3. I'm sure none of us want to be drawn into a bureacratic, committee based group- but a little organisation is required. I also host three community stes using Druapl CMS. One is public (www.uktmf.com) and I have two private ones that are probably a better model for a small group).I also use Drupal for my own company website.I'd be happy to host (initially on Windows, but I'd migrate to the Linux box later) a Drupal site for the group to use. The value of a CMS is we could define a brief terms of reference for the group, assign roles etc and make a start. Mailing lists are a bit cumbersome :O) 4. There's also a slight possibility I can corral some professional testers into helping us. There's an interesting group I know who do weekend testing for fun - mainly exploratory, but if we released apps that needed some testing, I can publicise this in my testing network we might get them on board. Just a thought. This is what I can contribute. Paul. On Aug 23, 10:47 am, Michele Comitini <michele.comit...@gmail.com> wrote: > Hi all, > > I do develomplent with many different things, different languages > architectures and looking for tools for managing software projects is > a must for me > > ;-) > > I think the "problem" here is that web2py has started to receive the > deserved attention by the user and developer community. > Prof. Massimo is doing his best to keep with the growing volume of > request. The question is: "design of new features is slowed by > bugfixing?" > > Well I red from Massimo 2 alerts similar to the following (Massimo > feel free to correct me if I am wrong!!): > 1. "Please remind me of patches to be applied" > 2. "I need to keep track of messages, so no IRC" > > Due to web2py success things will get worse, then I would suggest to > start focusing on 2 main points to see if we can find some > ideas/solutions. > > 1) version control > > I perfectly understand Massimo position: dealing with mercurial > (git,bzr) is a pain! Anyhow we must help Massimo > delegate some dirty work to others, since we need Massimo to do the > important stuff. > I think that somehow Massimo's web2py problems resemble those that > Linus' Linux faced at the end of '90s. I just > remind that Linus to end the thing had written the git system! > > Please take time to read this > chapter:http://hgbook.red-bean.com/read/collaborating-with-other-people.html > > and > this:http://hgbook.red-bean.com/read/collaborating-with-other-people.html#... > > The model for Linux development IMHO is too much at this time, but > some ideas should be taken into consideration. > > 2) issue tracking > > We *must* setup a ticket system. Discussion on groups,IRC will > eventually lead to a new ticket, but *only* tickets must be > taken into account for bugfixing. Code snippets, error log, must be > tracked there. > > ciao, > mic > > 2010/8/23 mart <msenecal...@gmail.com>: > > > > > 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 > > ... > > read more »- Hide quoted text - > > - Show quoted text -
