Sounds good, then Massimo it is :) I can setup a proposed branching structure with a clone of the latest code line (where hopefully folks will jump in and throw rocks at it so it modified if needed to better resolve initial issue). I can also look into into the Google-2- mercurial API and see where we can wrap it up and make less of a pain to use (i did this recently with Perforce where users' habits needed to be directed a little). Or maybe you think of something more pressing from comments in the thread?
Mart :) On Aug 29, 1:53 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > 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. > > ... > > read more »
