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
