[1840] in Kerberos_V5_Development
use of gnats "release" field
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Wed Oct 2 15:32:53 1996
Date: Wed, 2 Oct 1996 15:32:37 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
Cygnus, I imagine, often has several releases of a product installed
and operational at a site, and it is probably not unusual for them to
have to fix bugs in previous versions of software because their
customers do not always want to upgrade right away. Thus, in their
case it makes sense for the "Release" field of a PR to refer to the
release in which a bug was found.
That is generally not the case with MIT krb5. We do not generally
issue patches to previous releases. When a bug report comes in, we
will either decide it applies to the current code base and needs to be
fixed, or that it used to apply to a previous release and has already
been fixed. In the latter case, (I suspect) we will just send mail to
the originator suggesting they get the newest version, and close the
bug.
Therefore, I propose that the Release field of a krb5 PR should
contain the release for which the development team has scheduled the
bug to be fixed. That way, when a release is coming up, we can simply
run a query-pr to determine if all the bugs we decided to fix by that
release are fixed; when query-pr prints nothing, we know our
bug-fixing job for that release is done.
This, of course, requires an organized process of assigning PRs to
releases. At OV, we handled that via a periodic meeting (say, every
two weeks) to categorize, assign, prioritize, and schedule all new
bugs; the meeting tended to be pretty short. I suggest the same thing
here, where the "bug tracking team" is anyone that happens to be in
E40 the day of the meeting, or who cares enough to show up (ie: open
to anyone on krbdev).
Comments?
Barry
