Point 2) is nice for all of us because you (Massimo) are very quick, but how much does take off of your web2py time? Would not be better to open the ticket before testing and eventually close it as "works for me"? This way someone among the developers could take care of the ticket and test it, if he is able to fix it good, he makes a patch and he closes it when the patch is put in the trunk (by you). In case the patch cannot be applied either you have time to fix it or inform the submitter to fix it.
A slight modified version of the process (very imperfect): 1) people post a question about a possible bug 2) if it looks (without test) like it, you (or a developer) ask them to open a ticket 3) you or a developer take care of the ticket (becoming the ticket holder) locking others out 4) the holder tests: if it is not a bug then 6) 5) you fix it in trunk or a developer sends you a patch 5.1) if you cannot apply the patch in trunk then 5) again 6) the ticket holder closes the ticket making a reference to the revision in trunk. Point 1) and 2) can be optional? could a user open the ticket right away? For me a plus of a ticket system would be the automatic assignement of tickets to developers based on the area of the problem or some other criteria. Of course there is some work for Massimo... for instance finding stalled tickets and bashing lazy developers ;) One advantage would be that users can search for similar bugs in googlecode and see that they are already fixed at some revision and would check that they have updated their copy of web2py before asking. Also the changelog of a stable release could include a list of closed tickets (do not know how on googlecode, but *there must be some way*!!). BTW: patch generation should be something with a procedure by itself, using plain files or others means such as mercurial mic 2010/8/25 mdipierro <mdipie...@cs.depaul.edu>: > we do use googlecode for not. Here is the current (imperfect) process: > > 1) people post a question about a possible bug > 2) somebody checks that it is a bug, usually me > 3) if the bug does not get fixed in 24h, the original poster opens a > googlecode ticket > 4) when the bug is fixed the ticket is closed > > because many bugs are dealt with in <24hrs there is no record. Because > bugs are fixed in trunk and trunk takes a couple of weeks to become > steable and because most users never upgrade to the latest stable, > occasionally there are multiple questions related to the same fixed > bug. I am not sure better workflow management fixes this latter > problem. > > I have not read all messages on this thread carefully yet. Eventually > I will but I am happy to hear more of your ideas. > > > On Aug 24, 5:52 pm, Michele Comitini <michele.comit...@gmail.com> > wrote: >> Actually I would like to ask if bug tracking is used on web2py? >> >> Code is available from either (btw Massimo how do you keep those 2 in >> sync? just too curious :-) ): >> a) googlecode (with hg) >> b) launchpad (with bzr) >> >> both have some sort of bugtracking ticket system I do not know which >> one is best (or worst), we could start with one those, but >> the choice must taken with care and other systems must be evaluated >> (on: usability, independece, web2py phylosophy ...), and first >> they must meet Massimo needs. >> >> BTW: I would like to see a web2py application for doing serious >> bugtracking in the future... so that submitting >> a bug would be just one click on the ticket reported by any web2py >> installation! mmm too easy... that would be dangerous! ;-) >> >> ciao, >> mic >> >> 2010/8/24 mart <msenecal...@gmail.com>: >> >> > I don't know if you are currently using a specific bug tracking >> > system, but they are typically easy to interface with and made part of >> > build/release & test processes/automation. I.e. As part of a release >> > process, I would set rules with the source control system where non- >> > bugTraking releated changes can either be automatically rejected, or >> > moved to another set of prioritiesArea, etc... the build (or packaged >> > fileset, or whatever the output is) contains a detailed inventory of >> > bug fixes/features/etc... as part of an automated delivery system >> > (these are part of the build notes)...
