Good idea! Would be awsome! Probably a bug tracking system should be still need to be added though, for a few reasons (just my opinion though). If we go back to the root issue of the thread (or rather what turned out to be the defining issue to resolve), 2 separate things seem have been deemed as "in need of change" (well, 3 really).
1. Professor Di Pierro would like to retain control over adding patches, updates, features & bug fixes into the "main code line" while not having to enter/explain-how/modify(correct) bug information. He would like to spend the time fixing the issues a opposed to managing the ins and outs. By creating a bug/ticket system with web2py, a few very positive benefits are achieved: ease of integration to build system/release deliveries with solid build notes wrt bug included bug status (provided that too be done with a web2py flavor), tight control over the bug data itself (I.e. easy of bug history retrieval for bug validation, authentication which may prove useful if at some point it becomes necessary to implement bug/user filtering if Prf. Di Pierro decides to hand off some of this workload)). Oh and a great benefit (IMHO), showcasing an "in production system" built on the featured technology is always well viewed. Providing as many opportunities of web2py users to register (obviously without appearing overly eager can be a good thing, as you mention) 2. A change in structure may prove useful with the initial thread subject (move forward with testing iteration while continuing on with development efforts). Done correctly, by applying predictable patterns in the structure a "made to fit" bug/ticketing system could be made a little more intuitive and productive than the current Google-ish offering. If we can imagine all the desired functionality baked into exiting release & testing infrastructures, release cycles become much more efficient and consistent. As the guy managing releases where I work, I can say that consistency and repeatability of process goes a long way, and in this case Prf. Di Pierro is taking a lot on his shoulders which is a good thing for the web2py world, but understandably things could and should be easier for him given the current model. At This point, would be a good thing to take this to next level and begin planning and focused activity around this (with prf. Di Pierro's initial ask as the areas of focus). Any takers? @ Michele: still interested in heading the efforts ? ;) Mart :) On Aug 28, 5:34 am, Phyo Arkar <phyo.arkarl...@gmail.com> wrote: > That way > > 1) Encourage users more into web2py group > 2) Users can just jump into conversation and work onto bug fixes too. > 3) If thers google api which allows user to login and post directly to > google group , users can submit bug/questions directly there via > admin. > > On 8/28/10, Phyo Arkar <phyo.arkarl...@gmail.com> wrote: > > > sorry i mean > > > Put subject Tagged [web2py] [bug] at the top of the list? > > > On 8/28/10, Phyo Arkar <phyo.arkarl...@gmail.com> wrote: > >> regarding bug-tracking , i have a very simple idea. > > >> how about , before we develop the bug-tracking system , at app admin , > >> add a side box , just like > >> web2py Recent Tweets box , add > >> web2py Google Group box ? > > >> Is there Google Group api which can get all the list of subjects? and > >> put subject tagged [web2py] [bug] > > >> or how about iframe directly to Google Group? > > >> On 8/27/10, mart <msenecal...@gmail.com> wrote: > >>> I'm thinking a few possibilities... > > >>> we can, as a possible option, give folks the opportunity to either > >>> register there install of web2py with additional user registration > >>> option (depending of your philosophy wrt that) - which could also > >>> serve as tracking mechanism to encourage people to keep up with > >>> updates (i.e. Flash screen: "you are on version 1.62. Latest stable > >>> release is 1.84. Would you like to update now? y/n/"). Or maybe offer > >>> the option to register as a web2py user only (which may help augment > >>> numbers). Perhaps users can be motivated to register? For example > >>> "register and get access to the web2py community, ask questions, get > >>> real case answers, LOG bugs, etc. which would be a hard requirement > >>> for this type of activity) > > >>> registration: > >>> * install/user registration on install (I.e. .msi on windows) > >>> * on launch of app admin > >>> * on error? (I.e. Exception is thrown, user can be prompted to send > >>> error to web2py.com db.errors to 1) report the problem b) if issue can > >>> be figured out automatically like one I seem to be getting lately > >>> where AMF fails on import (missing class) when I could actually see > >>> it ;) - just as an example :)) then 2) the system can return > >>> resolution if available, or automatically log a ticket (oh, and while > >>> were there, why not offer the option of registration?) > >>> * obviously on launch of "web2py bug tracker" > >>> * on web2py software update > >>> * maybe a nice feature when installing one of those cool fee apps, > >>> user gets prompted with option to register > >>> * etc... > > >>> I think there are many ways to get user attention to register with > >>> valid Google account for reducing the risk of spam with bug logging > >>> (and can have a bit of value add as well - again if inline with your > >>> web2py philosophy). web2py already has great authentication > >>> capabilities with variety and ease, leveraging that should be do-able? > > >>> Also, i assume it should also be possible to query Google DB for user > >>> authentication, if not user validation is done through web2py.com? > > >>> Mart :) > > >>> On Aug 26, 7:23 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > >>>> This is reasonable but how to check? > > >>>> On Aug 26, 6:18 pm, mart <msenecal...@gmail.com> wrote: > > >>>> > Interesting point... How about bugs can only be "truly submitted" if > >>>> > user is registered in web2py user group? Can we up authentication > >>>> > detail for users (if required)... True that it could be scary that > >>>> > folks start logging bugs left and right... If part of user group, > >>>> > would this only generate same amount of traffic? > > >>>> > Mart :) > > >>>> > On Aug 26, 4:56 pm, Michele Comitini <michele.comit...@gmail.com> > >>>> > wrote: > > >>>> > > some thoughts... > > >>>> > > Firstly it is important that tickets reach their fate (closed, wont > >>>> > > fix, cant fix, not a bug, whatever ) soon, otherwise > >>>> > > it would be worst than people writing for bugs already fixed. You > >>>> > > can > >>>> > > see many projects that have 3 year old tickets... > >>>> > > This means that some individuals should handle the task of keeping > >>>> > > an > >>>> > > eye on tickets that stall and take actions. > >>>> > > Secondly I would suggest that we put down a little howto on > >>>> > > reporting > >>>> > > bugs. Short, no one reads it otherwise. ;-) > >>>> > > The answer to a user signalling something that sounds as a bug > >>>> > > could > >>>> > > be, "please read web2py.com/bugshowto and report the problem, > >>>> > > thanks!". > > >>>> > > I like the remote thing, but should it require a captha or similar, > >>>> > > to > >>>> > > avoid spammers and > >>>> > > to make clear to the sender that something is going out of its > >>>> > > machine? > >>>> > > Else it would look much like those desktop applications that ask > >>>> > > you > >>>> > > to send info to someone you > >>>> > > do not know, not only, you do not even know what data is going to > >>>> > > be > >>>> > > sent! Just "YES" or "NO"! Scaring stuff! ;-) > >>>> > > Those ticket could contain really sensitive data! > >>>> > > Has anyone already managed a similar situation? please speakup! > > >>>> > > mic > > >>>> > > 2010/8/26 mart <msenecal...@gmail.com>: > > >>>> > > > good plan! Do you have people dedicated to test purposes for the > >>>> > > > monitoring help? Were you thinking on a something like a 2 tier > >>>> > > > filtering system? first level bug validation (is this really a > >>>> > > > new > >>>> > > > bug?) as automated filtering & second: trusted testers/dev folks > >>>> > > > who > >>>> > > > can best help in filtering and pass best info to you? > > >>>> > > > open a web2py ticket from the admin! Very innovative! Lots of > >>>> > > > possibilities there! :). > > >>>> > > > Also, do let me know if you would like to look at (or have > >>>> > > > thoughts > >>>> > > > on) branching strategies as a means to allow testing phases while > >>>> > > > continuing with on going development. > > >>>> > > > Thanks, > >>>> > > > Mart :) > > >>>> > > > On Aug 26, 8:57 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > >>>> > > >> I am in favor of both proposals > > >>>> > > >> 1) user google code more > >>>> > > >> 2) having a bug tracking application > > >>>> > > >> but > >>>> > > >> - I would like some help in monitoring this list and opening > >>>> > > >> bugs > >>>> > > >> on > >>>> > > >> google code when a new bug is suggested on the list. This is > >>>> > > >> because I > >>>> > > >> do not want to have to explain to new users how to open google > >>>> > > >> code > >>>> > > >> tickets and I do not want to have to open them myself (i.e. > >>>> > > >> open,fix,close vs just fix it). > > >>>> > > >> - If we are doing this we should give it an edge: why not add to > >>>> > > >> the > >>>> > > >> web2py ticket system in admin to open a ticket remotely and > >>>> > > >> eventually > >>>> > > >> submit a local ticket? > >
