On Fri, Oct 16, 2009 at 12:25 PM, Pete Morgan <ac...@daffodil.uk.com> wrote: > Right, I'm a web developer and been thinking a lot about the bug > tracking (in my case across projects/ventures/etc), and applying that to > FG. Thats my frustration ladies and gentlemen, and I apologize for my > harshness sometimes; this comes from frustration ;-) > > Indeed as a day job, its working sometimes with users who think they > made a mistake, and indeed a bug.. ie proven twice, so ball back in my > court - we'll trained users. oops...ish and fixed, with svn up + python > onto a wind. > > So I checked out a few bug tracking systems for curiosity for the > purposes of FG,. I can report with confidence that none of them would > meet the criteria that would be useful within the scope of FlightGear, > as its bigger. Unless be break down the bugs into seperate components. > But then that is not the whole.. >
Hi Pete, I have used several incident and bug tracking systems professionally in the last few years. Started with an over version of the Perl RT system that you mention below. We ended up settling on Mavell Open Pursuit (which is derived from ITIL principles) for 12 months before management realised that it doesn't deliver what was promised and very limited searching for previous instances. Open pursuit is commerical (around $5000 per seat!!) and depends on Terminal Server. Bleerk! We settled on Atlassian Jira (their ticketing system, not the wiki) which is great. While Atlassian has in the past offered free instances to Open Source projects, I'm not sure if I'd be willing to spend at least 6 hours a day keeping incident tickets in line. While I'm not suggesting that we use a big end product, I did come to appreciate a few functions that should be a requirement for any issue/bug tracking system. - Searching. If I can't search for a error code or a Airport then I am wasting time. - Speed. When someone is investigating an issue, you should not be impeded by the interface. For remote connections Web based is good, Ajax/DHTML or some other XML-RPC method is better still. - Be able to track who is submitting what. A opened ticket stating "This aircraft is broken" is not helpful. Even worse is when several tickets have been opened, one for each aircraft. - Which brings us to the next point which is being able to split a ticket into sub tickets as similar issues may not have common cause. - At the same time, if several people have submitted the same issue, it's nice to create a master ticket to centralise efforts. - End users shall not submit bugs, instead they submit a isssue (incident ticket in ITIL). What the user calls a bug could turn out to be a configuration issue or a MP server being down. This issue ticket is investigated with sufficent information obtained to get an idea of what's going on. At this point a bug ticket is created against the version that the user(s) have installed. End users will be able to browse the bug tickets, though Yes, this is starting to sound like ITIL whose principles are reasonably sane but also annoyingly structured for open source projects. I think it's still valid to peck the eyes from around the world to suit. I'd be happy to step into the breech to help drive the system but (like everyone) I am constrained timewise. Regards George ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
