Re: [Flightgear-devel] FG Bug tracking

[George P. <geo...@gm...>]

On Fri, Oct 16, 2009 at 12:25 PM, Pete Morgan <AC...@da...> 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