*plugin_wiki* could be used as a basis for this eventual bugtraker?
2010/8/25 mart <msenecal...@gmail.com>: > yes, in any bug tracking system, "work on bug" data is provided by > assigned dev user (status/fix description/fix available in build X/ > etc.). > > Mart :) > > > On Aug 25, 1:23 pm, Alexandre Andrade <alexandrema...@gmail.com> > wrote: >> 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
