I'll take a patch to improve admin with the suggested changes. Massimo
p.s. Call me Massimo. My students usually do so too. On Aug 29, 12:48 am, mart <msenecal...@gmail.com> wrote: > 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?
