Meaning of RT tags and versions

[Sam Hartman]

We're in the middle of migrating away from Gnats for bug tracking and
to RT.  I sent out some mail describing the bug tracking process we
were going to use at the beginning of the summer and wanted to follow
up on that with definitions of fields in the  tickets.

Tickets have three version numbers associated with them:
version_reported, version_fixed, and target_version.  The
version_reported should be filled in by the submitter if they are
using the web interface or by the first person  to edit the bug with
the web interface; it is the version of Kerberos the bug first
appeared in.

The version_fixed field is set during the release process; you should
never change this field  unless you are a release engineer and even
then you'll probably be using automated scripts.

The target_version field is the version of the software we plan to fix
a bug in.  It is generally updated after release planning meetings,
although it is reasonable for people with commit access to update this
if they believe a particular issues should be considered for the
specified target version.  If we notice a lot of issues we don't have
time to deal with, we will drop the target versions as the release
approaches.

Therer are several tags that can be set on a ticket as well.

The first tag is the enhancement tag; this roughly corresponds to the
Gnats classification as change-request, distinguished from sw-bug.


The next tag is the nochange tag.  This indicates that the ticket has
been (or will be) closed bwith no code change and thus should not be
processed by the next round of release scripts.  This is appropriate
for tickets where the requestor is mistaken or where no bug/change
exists.

The final tag is the noresource tag; this indicates that MIT does not
have resources to dedicate to the problem/feature.  We'll set this tag
on tickets when we evaluate them in release planning discussions so
that we do not have to continue thinking about then at each
consecutive release.  In general, if we feel an issue is not a
problem, we'll just close the ticket.  However if we agree that in an
ideal world the issue would be fixed but don't ever expect to be able
to fix it ourselves, we'll set the noresource tag and forget the issue
unless someone replies to it with a patch or proposed solution.

--Sam