Page History
A ticket is an object describing and tracking a bug, new feature, project, incident, or action item related to the software development of HTCondor.
Ticket life cycle and status attribute
A newly created ticket has a status attribute of New. Once a developer is actively working on this ticket, it should be marked as Active. For anything but the most trivial of enhancements or bug fixes, the first step is to write a design document. Once a design document has been attached to this ticket, the ticket should go to ReviewDesign state until approved - often times this results in a new/edited version of the design document. After design approval, the ticket will go back to Active while being implemented. If the developer has permission to push directly to the HTCondor git repository, this implementation may happen on a topic branch; if not, the implementation may be attached to the ticket as a patch file or a github fork URL can be placed in the remarks. Once the implementation is complete, the ticket should go to ReviewCode and be re-assigned to another developer for a code review. The result of this code review will appear in the ticket Remarks and be clearly labeled in bold-face with CODE REVIEW. After review, this ticket is assigned back to the original developer to address any issues identified in the review. After implementation is complete, the ticket should go into DocPending state until the HTCondor Manual has been updated appropriately, after which the ticket may go to Resolved. Other less common ticket status values include stalled for a ticket that was active in the past, but is no longer being worked on), pending for a ticket that is awaiting additional input from a third-party (typically more information related to reproducing a bug), and abandoned for a ticket that we will never work on or for a ticket that is a duplicate of a previously existing ticket.
Creating a new ticket
Click on the [Ticket] link at the top of the page. It is very important the the fields of the ticket are assigned proper values, and that the formatting for the fields is strictly followed. When creating a new ticket, most of the fields should be obvious from the desciptions, just be careful about following the formatting conventions as described. A couple comments on a few fields:
- Title / One-line summary should be as descriptive as possible since it appears in various cross-references, reports, ticket link titles, etc.
- Type should be set to
Code Defectfor a software bug,Code Enhacementfor adding new capabilities or enhancing existing capabilities,Action Itemfor activities not related to the code (e.g. updating the web site), and finallySupport Incidentfor describing suspicious observed behavior when you are not (yet) sure if the problem is due to a bug. Do not use typeDocumentationfor new tickets. - Priority describes how quickly the ticket should be resolved, and have special meaning to the HTCondor developers. Priority 1 is do ahead of everything / fire priority. Priority 2 means very important, must get done within the next couple releases. Priority 3 means we should make every effort to get it done in the current development series. Priority 4 means nobody has thought yet about the priority of this ticket (essentially, this ticket has not yet been triaged). Priority 5 means "idea network" - it is a worthy idea but unknown when (or ever) anything will happen.
- Assigned To identifies the developer responsible for this ticket. This person will automatically get an email whenever this ticket changes. If you do not know who should get the ticket, assign to
tannenbaand he will re-assign and/or re-prioritize. - Notify should be a comma separated list of email addresses. Every time the ticket is updated, the list of addresses in this field will be sent an email summarizing what changed. Note that the person to who the ticket is Assigned To automatically gets email notifications.
- Ticket Number is unique to each ticket and can be referenced in wiki markup using the #n syntax.
Changing ticket status and other updates
Ticket properties including status can be edited by following the Edit link in the ticket view. Remarks can be added by following the Add remarks link in the Remarks area of a ticket view.
Other properties and functionality
Related fields
Any check-ins and milestones related to the ticket are listed in their own sections.
Tickets may also have children which reference them in their Derived From properties. These child tickets will be listed in a separate section, allowing a certain amount of hierarchical project task management.
History
A separate page containing a full ticket history provides a chronologically ordered list of all events associated with a ticket. Property changes, remarks, check-ins, attachments, inspections, etc, are all listed here.
Changes to certain fields, such as Description and Remarks are shown in diff style.
Attachments
Arbitrary files may be attached to tickets. This could include things like screenshots, design documents, etc. Attachments are of limited size.
Undoing Changes
When in the history view, it's possible to undo changes. A user with delete permissions or the user responsible for the change can do this within 24 hours while a user with admin permissions can do so at any time. An undo link is included at the last item of the history page in this case.
Deleting Tickets
Users with setup permissions can always delete tickets. Tickets should only be deleted as a last resort. If a ticket contains valuable project history, it should instead be closed.
Users (except anonymous) with delete permissions can delete tickets created by anonymous within 24 hours of ticket creation.