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 Defect for a software bug, Code Enhacement for adding new capabilities or enhancing existing capabilities, Action Item for activities not related to the code (e.g. updating the web site), and finally Support Incident for describing suspicious observed behavior when you are not (yet) sure if the problem is due to a bug. Do not use type Documentation for 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 tannenba and 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

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.

This work supported in part by NSF grants MCS-8105904, OCI-0437810, OCI-0850745, and/or ACI-1321762. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. Site built using CVSTrac.