bug tracking app is available on web2py.com? I think opening a bug should be the first that happens.... possible to add validation code within the bug tracking as a first layer filter (is this /or hast this ever been a bug ?) or... perhaps an easy way for users for query the db.bug_history (perhaps optimal in this case?)
Mart :) On Aug 25, 1:10 pm, Michele Comitini <michele.comit...@gmail.com> wrote: > 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)...
