[1972] in Release_7.7_team
Re: Status report on Athena bug tracking efforts.
daemon@ATHENA.MIT.EDU (Roger A. Roach)
Thu Oct 28 17:00:49 1999
Message-Id: <199910282100.RAA10959@rar.mit.edu>
To: Bill Cattey <wdc@MIT.EDU>
cc: rar@MIT.EDU, rferrara@MIT.EDU, vkumar@MIT.EDU, release-team@MIT.EDU,
tbelton@MIT.EDU
In-Reply-To: Your message of "Thu, 21 Oct 1999 18:41:58 EDT."
<ss3tOqsGgE6e1QkUk0@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 28 Oct 1999 17:00:29 -0400
From: "Roger A. Roach" <rar@MIT.EDU>
Bill,
Thanks for sending me this note. As you know, better bug tracking is one of
the issues I am trying to address in each of the areas of Service. This
effort should be a big help and I appreciate it.
A good tracking system is fundamental to addressing this problem and I
applaud your efforts to get this resolved. A common system, such as
Casetracker, would have some advantages, but I don't consider that a
requirement. It has been a long time since I read the scarab requirements
and I could not lay my hands on it quickly, but at the time it seemed
document the right issues. I am now concerned with such issues as to be able
to easily see outstanding problems and to allow end users to see the status
of their reports. Do you kow if Debian does that or is it just an internal
tracking system?
Once we have a system, I would like to step back a bit and look at process.
That is how should users/consultants enter problems. Should OLC or the
helpdesk act as a filter so that questions and non-bugs do not get put into
the bugs list as frequently? How do we get the results back to the user?
What about problems that we can't fix? Do we forward problems to the vendor?
If so, how do we track the results? etc. etc.
Anyway, good work. I'd be glad to meet with the team if you feel it would
help.
Roger
> This note is primarily directed at Roger, to provide a slightly formal
> status report on some stuff we had discussed informally.
>
> Objective: To improve tracking of Athena bugs.
>
> The Athena Release Team has devoted some effort to reviewing the present
> situation with bug tracking and the past work done by the scarab team.
> Currently available bug tracking systems, Debian, GNATS, Bugzilla, and
> Casetracker were discussed. The following observations were made:
>
> 1. The primary support contact for end users is the help desk and olc,
> not the mailing list bugs@mit.edu. The bugs list is for bonafide bugs.
> There is an existing procedure where Greg Hudson and others read the
> bugs messages, and forward end-user issues that are not bugs back to the
> consultants and the help desk.
>
> 2. From #1 above, this means that the primary value of bug tracking
> would be information management for developers not end users:
>
> - help us not "lose" bug reports (in the sense of people forgetting
> that the bug exists after too long goes by without anyone dealing)
> - be able to access history of individual bugs.
>
> 3. Reviewing the abstract requirements put forth in the past by the
> Scarab team, we see that they can be met by a combination of people
> continuing to do what they are doing, but using the ability to flag
> transactions in the archive.
>
> 4. When Bill asked, "What about Case Tracker?" Oliver Thomas (who should
> know) said, "It's not really a bug-tracking system. We don't like
> its interfaces. It doesn't meet many of the scarab requirements."
>
> 5. There was discussion about the possible value of interfacing with
> other data management systems, but consensus was that the most important
> requirement to meet was making it easy for developers to see bugs that
> needed fixing, and to correctly and easily record that they have been
> dealt with.
>
> Actions Taken:
>
> Greg Hudson took the action item to do the leg work to make the existing
> archives amenable to tracking by flaging transactions in the archive.
>
> Greg Hudson did further study of the Debian bug tracking system, and
> confirmed that if we wanted to switch over to using it that all the
> Scarab requirements would be met.
>
> Current consensus is that we will try and avoid the additional work of
> installing a whole bug tracking system. So we'll see if flagging
> transactions in the discuss meeting and a writing few perl scripts to do
> reports turn out to be sufficient.
>
> Todd Belton, reviewing the Athena Release Team minutes asked whether
> infoagents bugs should go through bugs@mit.edu even though they're not
> really Athena bugs. Greg Hudson and Todd agreed that a new process
> would be followed which mimics how we deal with third party software
> bugs:
>
> infoagents bugs appearing in bugs@mit.edu would be:
> forwarded to bug-infoagents
> marked in the bugs archive as "not our problem".
>
> In the future if the relationship of infoagents changes to be more
> closely integrated with the Athena Release Team, this procedure might
> change.
>
> -wdc
