[1852] in Kerberos_V5_Development
Re: use of gnats "release" field
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Oct 15 16:24:51 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 15 Oct 1996 16:24:33 -0400
In-Reply-To: "Barry Jaspan"'s message of Wed, 2 Oct 1996 15:32:37 -0400
>>>>> "Barry" == "Barry Jaspan" <bjaspan@MIT.EDU> writes:
Barry> That is generally not the case with MIT krb5. We do not
Barry> generally issue patches to previous releases.
Uh, you may not do this, but at least epeisach and I try to do so when it isn't too difficult.
In terms of patches already issues to Beta 7:
* kadmin/configure patch
* appl/bsd/login.c patch
* I think a few kadmin patches were posted but may be wrong
Barry> When a bug
Barry> report comes in, we will either decide it applies to the
Barry> current code base and needs to be fixed, or that it used to
Barry> apply to a previous release and has already been fixed. In
Barry> the latter case, (I suspect) we will just send mail to the
Barry> originator suggesting they get the newest version, and
Barry> close the bug.
Barry> Therefore, I propose that the Release field of a krb5 PR
Barry> should contain the release for which the development team
Barry> has scheduled the bug to be fixed. That way, when a
Barry> release is coming up, we can simply run a query-pr to
Barry> determine if all the bugs we decided to fix by that release
Barry> are fixed; when query-pr prints nothing, we know our
Barry> bug-fixing job for that release is done.
I think it would be more useful for the user community for the
release to be the release for which the bug was reported or first
applies. This way, a user can search for beta-7 bugs and know if they
need to report the problem or if a fix has been suggested.
I tend to use the priority field to suggest how important it
is to fix a bug, and try to make sure that all high priority bugs are
fixed before a release. This is not as flexible but allows users to
know what doesn't work in a particular release, which is fairly
important.
Barry> Comments?
Barry> Barry
