[1947] in Release_7.7_team
minutes, 10/6
daemon@ATHENA.MIT.EDU (Dan Winship)
Wed Oct 6 20:07:30 1999
Date: Wed, 6 Oct 1999 20:07:23 -0400 (EDT)
Message-Id: <199910070007.UAA302786@antharia.mit.edu>
From: Dan Winship <danw@MIT.EDU>
To: release-team@mit.edu
Attending: othomas, ajfox, miki, danw, rbasch, ghudson, tb | wdc,
jweiss
1) Bug tracking
Goals:
- only for Athena bugs, doesn't need to interface to support systems
- 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
- content-free "thank you for your bug" acknowledgement? We're not
sure.
What's available:
- Debian's bug-tracking system (also used by GNOME):
organizes bugs by packages, sends email acknowledgement, deals
with bug aging. Control interface is via email. Browsing interface
is via www
- GNATS (used by krb5, NetBSD among others)
Greg doesn't like it because it makes users fill out a fairly
arcane and non-obvious form. (A "sendbug"-level form is good, but
GNATS's has too many questions.)
- Bugzilla (used by Mozilla and RedHat)
Not really a full-fledged system, just an SQL backend. Would
require more work on our part. Also, it's SQL. Ew. However, it
does do bug merging (the others don't) and lets random people
add themselves to the "interested parties" list for a bug so they
get notifications when it changes state.
- Casetracker
Oliver says it's not really a bug-tracking system. We don't like
its interfaces. It doesn't meet many of the scarab requirements.
Of these, Debian's is the only one we wouldn't hate.
To submit a bug report, you send email to, eg, "bugs@bugs.debian.org".
It assigns a bug number, replies with bug number. Mail sent to
"###@bugs.debian.org" is appended to the bug log. Mail sent to
"###-done@bugs.debian.org" closes the bug report and notifies the
user. Other control messages exist, too.
No authentication, but responsible party and submitter get
notification when bug changes state, and we know how to break fingers
if people abuse it.
Web interface may be only interface to querying (although we could
have it store the bug data into AFS or NFS). No linking of
related/duplicate bug reports. Requires special mail setup and a web
server.
Oliver brings up the idea of just using flagging in the bugs discuss
meeting, like accounts does with accounts, and ops does with afsreq
and hesreq. This would require basically no additional development,
but wouldn't get us nearly as many features.
Interesting requirements from scarab vs. Debian's system and discuss
flagging:
- Bug submitters should receive an acknowledgement with an ID, and a
notification when the bug is fixed.
Not sure if we care, but yes for Debian. Discuss doesn't do this,
but it would be a SMOP.
- The system should be accessible from a variety of platforms.
Both take input via email.
Debian's system can be searched and viewed via categories on the
web.
The discuss meeting can be read via discuss, edsc, dsgrep, and
diswww, but diswww doesn't show flags, and searching options are
much more limited.
- The system should lose no information.
Yes to both.
- The system should support access by support groups.
See "accessible from a variety of platforms".
- The system should know the full history of the bug, the current status
of the bug, and when/if it is likely to be fixed.
Yes. (via chaining in discuss)
- The system should support linking related bug reports together.
No for both.
- The system should possibly distinguish between "bug reports"
(complaints) versus "error list entries" (confirmed bugs).
Not clear. Debian's system does have a concept of "severity", for
distinguishing really important bugs from wishlist items.
Discuss does nothing useful here.
- The system should support periodic reports for management.
Yes. (ops has a script to generate a list of unflagged
transactions in a meeting).
- The system should support time triggers to alert management of bugs
which aren't getting required action.
Yes for Debian's system, although we're not sure we'd really use
this.
Pro's of Debian's system:
- better queries on the db / friendlier to browse
- auto-ack (if we want that)
- not tied to discuss
- better reporting options
- deals better with aging (for bugs which are not likely to get
fixed for a long time)
Cons of Debian's system:
- would require more development work
- would require ops work
- would take more setup time vs flagging, which we could just start
People think the Debian system would be better if it doesn't take too
much work.
Greg proposes flagging for now, and will look at the Debian system and
will decide if it seems reasonable, and if so, will get buy-in from
ops.
See [17243] and [17244] in bugs for procedure.
3psw bug reports will be dealt with by f_ls/alexp
2) SGI hanging problem
It's getting pretty bad (a few machines a week). We should get out the
patch release soon. Greg will put it out this week, public on the
18th.
Next week we'll talk about private workstations.
