This aims to be the central source of information about Tickets in rasdaman and their management.

Tickets processing workflow

Along the lines of the built in trac workflow, with respect to ticket assignments we have in place:

1. If the ticket owner is not specified at the time of ticket creation, it gets assigned automatically to the component owner;
2. A ticket can then be assigned further to the person that would be the most appropriate for handling or solving it.
3. Once a person starts working on a ticket he has to accept the ticket (so we are all aware that it is being worked on actively)
4. If on an accepted ticket one expects to stop working for long (e.g. more than 2-3 weeks) the ticket should be re-assigned (eventually to oneself)
   • the ticket should be brought to a "stable" progress update point with an interim patch (to be confirmed)

From the above we have that:

• Any ticket that is in new or assigned status can be sent to other people or anyone can volunteer to work on it (contacting the current owner for guidance or discussing it on the dev list is a good option for that);
• Any ticket that is currently accepted is expected to be under work and get either regular status updates or patch submissions towards its resolution. The owner of such a ticket has to be contacted before changes highly relevant to it are made or before reassignment or acceptance by someone else.

Once a ticket is resolved and the tested patch submitted it can be closed. Whoever wants to test it or see if it has already been integrated into the dev/release lines or packaged for release can check via git log (ticket linking is enforced by naming conventions on patch manager):

git log | grep 'ticket:NUM' -B4

As good habit a reference to the related changeset might also be added to the ticket once the patch is applied for cross-reference.

• Every patch referring to a ticket shall (must!) have a reference to it in the title/description for back reference in the form ticket:<code>, see our [StandardsAndGuideLines guidelines].

Ticket pollution problem

If the solution of the tickets deserves a deeper discussion with the mailing lists (or with single devs), it is good to spawn it outside the ticket comments onto e-mail or whatever means, and to provide there only concise and useful conclusions.

See also

• How to file new tickets at ReportBug
• Overall standards and guidelines for development and process management at StandardsAndGuideLines