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)...
