Difference between revisions of "Tickets"
| Line 3: | Line 3: | ||
The Einstein Toolkit uses the TRAC issue tracker to keep track of current problems and new features. This page describes how this system is used. | The Einstein Toolkit uses the TRAC issue tracker to keep track of current problems and new features. This page describes how this system is used. | ||
| − | =Processes= | + | ==Processes== |
| − | == Triage == | + | === Triage === |
When tickets are created, they are automatically placed into a "NEW" state. Such tickets should be triaged by a maintainer. Once triaged, their state will be changed to "triaged" or "lookedat". <span style="background:yellow">Maybe we want a better name for this.</span> The process of triage includes: | When tickets are created, they are automatically placed into a "NEW" state. Such tickets should be triaged by a maintainer. Once triaged, their state will be changed to "triaged" or "lookedat". <span style="background:yellow">Maybe we want a better name for this.</span> The process of triage includes: | ||
| Line 15: | Line 15: | ||
<span style="background:yellow">How do we avoid multiple maintainers triaging tickets at the same time? Each maintainer theoretically has an area of expertise (https://docs.einsteintoolkit.org/et-docs/Organization_and_Responsibilities), but these are not uniquely assigned.</span> | <span style="background:yellow">How do we avoid multiple maintainers triaging tickets at the same time? Each maintainer theoretically has an area of expertise (https://docs.einsteintoolkit.org/et-docs/Organization_and_Responsibilities), but these are not uniquely assigned.</span> | ||
| − | ==Review== | + | ===Review=== |
When a patch or branch is available for review, the ticket state should be set to "review", and assigned to a reviewer (the reviewer can unaccept the assignment, or reassign it). If the review is passed, the state should be set to "reviewed_ok". This indicates that it is ready to commit or merge. Once this has happened, the ticket can be closed as "fixed". | When a patch or branch is available for review, the ticket state should be set to "review", and assigned to a reviewer (the reviewer can unaccept the assignment, or reassign it). If the review is passed, the state should be set to "reviewed_ok". This indicates that it is ready to commit or merge. Once this has happened, the ticket can be closed as "fixed". | ||
| − | =Ticket metadata= | + | ==Ticket metadata== |
The following sections describe how the TRAC ticket metadata is used in the Einstein Toolkit. | The following sections describe how the TRAC ticket metadata is used in the Einstein Toolkit. | ||
| − | + | ===Priority=== | |
{| border="1" | {| border="1" | ||
| Line 40: | Line 40: | ||
|} | |} | ||
| − | + | ===Type=== | |
{| border="1" | {| border="1" | ||
| Line 52: | Line 52: | ||
|} | |} | ||
| − | + | ===Owner=== | |
This is the TRAC user who is expected to perform the next work on the ticket, and who will do so soon (on a timescale of a week). Feel free to assign ownership to other people. This should be interpreted as a polite request to do something if possible. If you are assigned a ticket, feel free to reject the assignment if you don't have time or inclination to work on it. Ticket can be "Reassigned to" an empty field, which removes ownership. | This is the TRAC user who is expected to perform the next work on the ticket, and who will do so soon (on a timescale of a week). Feel free to assign ownership to other people. This should be interpreted as a polite request to do something if possible. If you are assigned a ticket, feel free to reject the assignment if you don't have time or inclination to work on it. Ticket can be "Reassigned to" an empty field, which removes ownership. | ||
| − | + | ===Milestone=== | |
Tickets can be assigned a release milestone. This means that we want to have these tickets looked at for the upcoming release. It is normal that not all of these will be addressed in time. Note that it doesn't make sense to add a milestone to a ticket unless someone is likely to work on it, and ideally that should be the person who assigned the milestone. | Tickets can be assigned a release milestone. This means that we want to have these tickets looked at for the upcoming release. It is normal that not all of these will be addressed in time. Note that it doesn't make sense to add a milestone to a ticket unless someone is likely to work on it, and ideally that should be the person who assigned the milestone. | ||
<span style="background:yellow">We should make a clear distinction between tickets which are "major", i.e. imporant enough to be considered for the release, and those which have the milestone. What is the difference?</span> | <span style="background:yellow">We should make a clear distinction between tickets which are "major", i.e. imporant enough to be considered for the release, and those which have the milestone. What is the difference?</span> | ||
| − | + | ===Version=== | |
The version of the code that the problem is reported against. This will either be the development version or a particular release. | The version of the code that the problem is reported against. This will either be the development version or a particular release. | ||
| − | + | ===Component=== | |
Which area of the code (or infrastructure) is affected. This is useful for people who are experts in a particular area to see all the problems in that component. | Which area of the code (or infrastructure) is affected. This is useful for people who are experts in a particular area to see all the problems in that component. | ||
| − | + | ===Keywords=== | |
We have a set of keywords and meanings which allow certain things to be searched for easily. You can enter multiple keywords separated by spaces. The following are currently defined | We have a set of keywords and meanings which allow certain things to be searched for easily. You can enter multiple keywords separated by spaces. The following are currently defined | ||
| Line 85: | Line 85: | ||
| − | + | ===State=== | |
{| border="1" | {| border="1" | ||
Revision as of 12:24, 8 December 2014
This draft document is a work-in-progress.
The Einstein Toolkit uses the TRAC issue tracker to keep track of current problems and new features. This page describes how this system is used.
Contents
Processes
Triage
When tickets are created, they are automatically placed into a "NEW" state. Such tickets should be triaged by a maintainer. Once triaged, their state will be changed to "triaged" or "lookedat". Maybe we want a better name for this. The process of triage includes:
- setting the priority (see below);
- checking that the title and description make sense;
- possibly assigning the ticket to a person (see below).
How do we avoid multiple maintainers triaging tickets at the same time? Each maintainer theoretically has an area of expertise (https://docs.einsteintoolkit.org/et-docs/Organization_and_Responsibilities), but these are not uniquely assigned.
Review
When a patch or branch is available for review, the ticket state should be set to "review", and assigned to a reviewer (the reviewer can unaccept the assignment, or reassign it). If the review is passed, the state should be set to "reviewed_ok". This indicates that it is ready to commit or merge. Once this has happened, the ticket can be closed as "fixed".
Ticket metadata
The following sections describe how the TRAC ticket metadata is used in the Einstein Toolkit.
Priority
| Value | Meaning |
|---|---|
| Optional | Very low priority |
| Minor | Not important enough to look at before a release |
| Major | Needs to be fixed before release or documented in release notes |
| Critical | At least one thorn always fails to run |
| Blocker | The ET does not build, or another problem which means development cannot continue. |
Type
| Value | Meaning |
|---|---|
| Defect | Something does not do what it is supposed to do |
| Enhancement | A new feature proposal |
| Task | Something that needs to be done that does not make any change to the code |
Owner
This is the TRAC user who is expected to perform the next work on the ticket, and who will do so soon (on a timescale of a week). Feel free to assign ownership to other people. This should be interpreted as a polite request to do something if possible. If you are assigned a ticket, feel free to reject the assignment if you don't have time or inclination to work on it. Ticket can be "Reassigned to" an empty field, which removes ownership.
Milestone
Tickets can be assigned a release milestone. This means that we want to have these tickets looked at for the upcoming release. It is normal that not all of these will be addressed in time. Note that it doesn't make sense to add a milestone to a ticket unless someone is likely to work on it, and ideally that should be the person who assigned the milestone. We should make a clear distinction between tickets which are "major", i.e. imporant enough to be considered for the release, and those which have the milestone. What is the difference?
Version
The version of the code that the problem is reported against. This will either be the development version or a particular release.
Component
Which area of the code (or infrastructure) is affected. This is useful for people who are experts in a particular area to see all the problems in that component.
Keywords
We have a set of keywords and meanings which allow certain things to be searched for easily. You can enter multiple keywords separated by spaces. The following are currently defined
| Keyword | Meaning |
|---|---|
| regression | The code or feature was previously working, and now is not. We should not release with regressions. |
| backport | The fix needs to be applied to the latest release, as well as the current trunk |
| (thorn name) | Since we don't have components for every thorn, it can be useful to put the thorn name as a keyword, so it becomes possible to search for tickets affecting specific thorns |
State
| Value | Meaning |
|---|---|
| New | The ticket has been newly-created, and no decision has been made on what to do about it or who will do it |
| Accepted/Assigned | The user will oversee the ticket, usually doing the work themselves |
| Reopened | The ticket was closed before, but the problem came back, or was not fully fixed |
| Closed | (fixed, invalid, duplicate, wontfix, worksforme) |
| Review | A patch has been created which is ready to apply, and approval and/or comments are needed because that is the ET process |
| reviewed_ok | The patch has been approved and can be committed |
