Since we can se the web2py tickets as bugs (of our apps), its be nice to incorporate a management of this tickets, not only registering them.
2010/8/25 mart <msenecal...@gmail.com> > 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)... > -- Atenciosamente -- ========================= Alexandre Andrade Hipercenter.com
