[os-infrastructure] Bug/issue tracking (was commit messages)

[Andrew Ross]

To share our thoughts regarding bug/issue tracking.

Trac is a stop gap in our minds. It is simple, easy to use, and runs on Ingres. Unfortunately it cannot handle private/security issues nor does it handle issue tracking.

We've really liked what we've seen from Jira. There are others in the ecosystems we're part of and they use it with pleasure for both issue and bug tracking. As Grant mentioned, Luminary has also had a positive experience.

The only issue I see is that Jira does not run on Ingres currently. I personally feel this is important. I don't think they would do a port just because. If we engage and show value/share some of the work, they may be interested in talking.

Even though Service desk is a mine field (as Chris aptly pointed out), I would like to choose a bug/issue tracker that is capable of unifying our current systems while still hooking into our CM system.

Andrew

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of Grant Croker
Sent: April 30, 2008 11:36 PM
To: opensource-infrastructure at lists.ingres.com
Subject: Re: Bug systems - was Re: [os-infrastructure] Commit Messages

On 30/04/08 19:59, Chris Clark wrote:
> On 4/30/2008 9:59 AM, Alex Hanshaw wrote:
>> The public fields in a bugs system should not have client 
>> information. (I know ours does, horse and stable door . . .. ).
>
> For those new to Ingres, "Bugs" was and is the bug tracking system 
> from the olden days. Customers had limited access to this over a 
> modem, i.e. they saw the public fields NOT the internal ones. Bugs is 
> forms based but there is a prototype GUI (Windows/Web) read interface 
> floating around if you ask the right people......
>
Wasn't this advisor and not bugs? IIRC advisor gave you access to bugs and the public KB docs from calltrack.
> For those new to Ingres, "Problems" was the sub-system in Startrack 
> for bug tracking when we were at CA.
>> Whatever we do we should have 1 bug tracking system. bugs and 
>> Problems was a nightmare in CA and that was without external people 
>> logging bugs on the single system available to them.
>
> Agreed, this was a VERY painful period at CA. I don't think SE can 
> stress this enough, we need a SINGLE solid bug tracking system that 
> ties into SCM. If this means we move away from Bugs we should move 
> away from bugs. If this means we extend bugs, we should extend bugs.
Beyond that we need to consider the issue tracker, the 3rd member of the trinity. How well integrated is servicedesk with bugs?
>
> As a side comment (warning personal opinions abound); I see a distinct 
> difference between bug tracking and issue tracking. Confusing Service 
> Desk (issue tracker with very little bug tracking) with a bug tracking 
> system (like Trac, Bugzilla, etc.) is easy to do but they service 
> different needs. SD is NOT a bug tracker. Conversely Trac is not an 
> issue tracker.
Agreed - Jira (http://www.atlassian.com/software/jira/) looks like it does what we need. I know rPath use it and have it set-up to distinguish between customer issues/bugs and community issues/bugs. I believe we have some in house experience at Luminary as they use it for their services engagements. I have no experience of using other than as a user as the IM server we use has its project managed via JIRA.

my 0.02€ cents...

g

--
Grant Croker - Ingres PHP, Ruby and Python maintainer The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.
    -- Terry Pratchett

_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure