[1959] in Release_7.7_team
Status report on Athena bug tracking efforts.
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Oct 21 18:42:10 1999
Message-ID: <ss3tOqsGgE6e1QkUk0@mit.edu>
Date: Thu, 21 Oct 1999 18:41:58 -0400 (EDT)
From: Bill Cattey <wdc@MIT.EDU>
To: rar@MIT.EDU, rferrara@MIT.EDU, vkumar@MIT.EDU
CC: release-team@MIT.EDU, tbelton@MIT.EDU
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
