Difference between revisions of "RT keywords"
(snapshot Sam's old text) |
(Note multivalued nature of "tags") |
||
| Line 1: | Line 1: | ||
| − | 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. |
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. |
||
| Line 7: | Line 5: | ||
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. |
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. |
||
| − | There are several tags that can be set on a ticket as well. |
+ | There are several tags that can be set on a ticket as well. ("Tags" is a multivalued keyword select, so there can be more than one on a ticket.) |
The first tag is the enhancement tag; this roughly corresponds to the Gnats classification as change-request, distinguished from sw-bug. |
The first tag is the enhancement tag; this roughly corresponds to the Gnats classification as change-request, distinguished from sw-bug. |
||
| Line 14: | Line 12: | ||
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. |
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 |
||
Latest revision as of 18:19, 2 November 2011
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.
There are several tags that can be set on a ticket as well. ("Tags" is a multivalued keyword select, so there can be more than one on a ticket.)
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 with no code change and thus should not be processed by the next round of release scripts. This is appropriate for tickets where the requester 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.
