Bug systems - was Re: [os-infrastructure] Commit Messages

[Alex Hanshaw]

Hi Chris

 I would certainly prefer to see a tightly integrated issue tracking
system so that they can be tied to bugs and
see issue fields updated accordingly when a bug is fixed in the release
the issue was raised against. Just because
SD is not integrated doesn't mean we should select another option where
we have to manually plug in the relevant
fields from the bug system.
 Grant, does Jira have a patch system? This is a vital component of BUGs
and so far I've not heard any mention
of a patch system in any of these discussions.

 Alex

On Wed, 2008-04-30 at 16:25 -0700, Chris Clark wrote:

> On 4/30/2008 2:36 PM, Grant Croker wrote:
> > 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.
> 
> I was trying to avoid the gory detail. Yes the service/application was 
> called Advisor, I believe it used the Bugs database and the application 
> enforced the "limited" access to bugs data (maybe some roles/grants 
> too). The idea was that Ingres support and (some lucky) customers had 
> access to the same bugs data, support had a superset of it.
> 
> The important take away is that public Bugs fields are supposed to be 
> customer clean (and were at one point) - some bugs may not be customer 
> clean today but they are supposed to be. We could make (some) of this 
> data public again, this would get us into the business of maintaining a 
> bug tracking system which is unattractive but has some compelling 
> advantages over a replacement system.
> 
> > Beyond that we need to consider the issue tracker, the 3rd member of 
> > the trinity. 
> 
> Pull pin, throw a grenade, run.......
> 
> This is a question for Pam/Michael Lochead :-) If end users want issue 
> support, our party line is, "get a support contract". So it need-not be 
> part of the opensource infrastructure. I've not heard much recently on 
> what the next step for ISN is, originally it was supposed to have 
> support for both paying customers and community members. And I get the 
> impression that this has already been decided. As engineers (only 
> engineers are subscribed to this list so far) I suspect we will have 
> little sway on selection of an issue tracker (or what ever we call the 
> support experience).
> 
> > How well integrated is servicedesk with bugs?
> 
> "Not at all", is my experience. I'm sure someone from Pam's team can 
> comment on this better than I can. There are a few custom fields added 
> to SD (under the Bugs tab; Bug Number(s), Resolving Patch Number, Patch 
> Request Number (BUGS), Customer Reference Number) that are manually 
> updated by technicians -- at least I'm manually maintaining them, if 
> there is a better way I'd like to know about it! There is no link from 
> SD to Bugs and vice-versa. A bug fix in bugs (status SUBM) does not get 
> updated in SD, etc.
> 
> I think we (on this mailing list) only have to worry about a bug system 
> and a source code control system. It would be nice to talk about issue 
> tracking but I fear it will be a waste of (our) time.
> 
> Chris
> 
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure

Alex Hanshaw
Manager, Sustaining Engineering
Ingres Europe Limited
alex.hanshaw at ingres.com

PHONE +44 01753 559515
MOBILE+44 07793 757929

www.ingres.com

This transmission is confidential and intended solely for the use of the
recipient named above. It may contain confidential, proprietary, or
legally privileged information. If you are not the intended recipient,
you are hereby notified that any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you have received this
transmission in error, please contact the sender by reply e-mail and
delete the original transmission and all copies from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ingres.com/pipermail/opensource-infrastructure/attachments/20080501/cf1eb385/attachment.html