I was thinking why not Mart?! ;-) There is no need to rush. I would wait for more feedback and Massimo ideas on this, in the midtime we can use googlecode better, while *eventually* starting a web2py centric bugtracker...
2010/8/25 mart <msenecal...@gmail.com>: > What a great thing! Now we just need to define requirements... Someone > should lead this to avoid problems... (N cooks in one kitchen where N > should = 1) Michele is it? :) > > Mart :) > > On Aug 25, 1:52 pm, Michele Comitini <michele.comit...@gmail.com> > wrote: >> *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
