[1856] in Kerberos_V5_Development
Re: use of gnats "release" field
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Wed Oct 16 18:12:29 1996
Date: Wed, 16 Oct 1996 18:12:19 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: Sam Hartman <hartmans@MIT.EDU>
Cc: "Barry Jaspan" <bjaspan@MIT.EDU>, Sam Hartman <hartmans@MIT.EDU>,
krbdev@MIT.EDU
In-Reply-To: [1855]
The other problem associated with doing this is that the
submitter often doesn't know when the bug will be fixed.
Obviously. The submitter often doesn't what the bug's priority is,
either; most people's idea of "high priority" is anything that annoys
them. That's what bug review meetings are for---the development team
gets together to discuss and schedule when bugs will be fixed.
Finally, I
don't see us getting organized enough to decide more than one release
ahead of time to decide when things would be fixed, so I think the
priority field is sufficient.
It is pretty difficult to argue against "we're too lame," so I won't
try. :-)
Very well. If we are going to use the priority field to determine
which bugs will be fixed by the upcoming release, then we need (a) to
decide how priorities will be assigned to reflect that and (b) either
assign someone the job of assigning priorities, or have meetings when
necessary to do it as a group.
I propose the following interpretations of priorities:
high: must be fixed before next release; the release will be
delayed until it is fixed
medium: important to fix, but won't hold up the release;
perhaps for each release we should designate a "medium
priority bug fix" time period during which no other source
code changes (ie: new development) are allowed, and however
many we can fix during that period, so be it.
low: yeah, right. When we get around to it.
I don't think there is a single person that should assign all the bug
priorities, so I suggest many every month or so we schedule a meeting
to discuss and prioritize new bugs.
Barry
