wiki:TicketLifecycle
Last modified 10 years ago Last modified on 10/22/2008 08:19:13 AM

OBSOLETE DC2: Revisiting Workflow from Ticket Creation to Ticket Completion

Currently we've built up a backlog of Tickets already integrated into the trunk but which have not completed all the QA steps required by LSST software policies.

Current Ticket hand-off is generally

Reporter creates new Ticket
Developer implements
Developer installs on trunk
Module Guru makes Distribution branch
Reviewer checks compliance
Developer closes Ticket

The QA, if it occurs, happens after the implementation has been put on the trunk. We need to streamline the process so reviews can be done in a timely manner.

KTL comments:

I thought that the Module Guru step is actually at the end of this process, not the middle. It seems to me that it is much more useful in terms of tracking the status of changes and progress towards a given milestone to have tickets closed when resolved, not when distributed. The same goes for the proposal below.

Robyn replies:

I'm saying this is the de facto process, although it's not supposed to happen this way. In the proposal following, closing the ticket after it's become part of a distribution branch ensures that the UML update has been done. But I'm fine having the Ticket closed when the change is merged onto the trunk. Module guru would still need to ensure UML is up-to-date with all tickets and should update their status for the 'paper trail'.

ajc comments:

My concern is that having a dual review (coding practice and algorithm) is going to add to the overhead to the review process. Reviews are always going to be the rate limiting step (more the actual review than assigning it) and I dont really see how splitting into two components (both of which must be completed before check in) will make this more efficient. My view is that the review process is not to test the algorithm of the checked in code or to evaluate it in a detailed manner but to instead to ensure standards, check there arent obvious errors, check someone iterates through the data correctly, and generally to get another set of eyes on the problem. Showing the algorithm is appropriate or improves the results is something that the developer or group of developers (or testers) should be doing. If we stick with that the reviewer doesnt have to be a domain expert just familiar with the data structures. We originally planned small tickets (i.e check in 200 lines of code per ticket) but we arent really doing that. Hopefully this stops after DC2 and we can get to a more 'formalized" process.

Robyn replies:

OK, point taken. The second review for algorithm is not the purpose of the code review. In reviewing the outstanding tickets, I need to know which reviews that have been completed and how far the code has been integrated. A checklist for both categories would suffice:

reviewed: Standards, UML, Requirements; integration: inTicket, inTrunk, inTag.

Using this, there is some guarantee of end-to-end QA having been done. Some of this will be incorporated in the new Trac Workflow - but the that release hasn't even made it to beta.

Robyn comments:

I'll be testing soon the procedure where the Module Guru is required to synchronize the source with EA for a number of tickets. If the process is too tedious, this step will devolve back to the Developer.

Proposal

One issue which causes delays is the assignment of a reviewer by the developer. If the current Ticket holder doesn't know who to draft for the next step, reassign the Ticket to the Ticket Manager. The Ticket Manager will ensure someone is quickly assigned the task.

In order to start clearing the backlog, I suggest a further workflow change: move the UML reengineering step to the point where the trunk is tagged as a distribution release.

Moving the reverse engineering step to the point where code is tagged as a Distribution branch corresponds with when the UML needs to match the code. This also reduces the burden on the individual Developers since multiple Tickets will be reengineered at the same time. Individual Developers are, of course, encouraged to update the UML earlier if a Ticket covers a major redesign.

Optimal Ticket progression

Reporter creates new Ticket
Developer implements
Standards Reviewer ensures compliance
Developer installs on trunk
Module Guru makes Distribution branch
Module Guru closes Ticket

Reponsibilities at each Ticket transition

Upgrade, Bug Fix, and New Implementation Tickets

Reporter

  • enters new ticket describing issue and providing duplication scenario;
  • provisionally assigns Ticket to a Developer or to Ticket Manager for further reassignment.

Ticket

    Status:  new          Review: notReady    Resolution:
                          checkStandards ___ onTrunk ___ checkUML ___

Developer

  • accepts ticket.

Ticket

    Status:  assigned     Review: notReady    Resolution:
                          checkStandards ___  onTrunk ___  checkUML ___

OR

Developer

  • rejects ticket and provisionally reassigns it to someone else.

Ticket

    Status:  reassigned   Review: notReady    Resolution: 
                          checkStandards ___  onTrunk ___  checkUML ___

Developer

  • implements the code according to Standards, with compatability to LSST Project Requirements, and to satisfy the Ticket's issue;
  • documents the solution in Ticket log
  • implements a unittest module to exercise the new code;
  • enters the unittest's output log as attachment to the Ticket thus demonstrating its successful use;
  • on completion of above list,
    • reassigns Ticket to Standards Reviewer or to Ticket Manager for reassignment.

Ticket

    Status:  reassigned   Review: needsReview    Resolution:
                          checkStandards ___  onTrunk ___checkUML ___

Standards Reviewer

  • checks code for conformance to Standards;
  • ensures unittest successfully run by checking unittest log in the Ticket;
  • if either step above indicate non-compliance to Standards,
    • enters concerns into Ticket log;
    • enters 'notReady' in Review field;
    • reassigns Ticket to Developer;
  • on satisfactory completion of above,
    • enters comment on satisfactory check into Ticket log;
    • enters 'reviewed' in Review field;
    • reassigns Ticket to Developer.

Ticket

    Status:  reassigned   Review: reviewed    Resolution:
                          checkStandards _x_  onTrunk ___ checkUML ___

Developer

  • merges Ticket branch into trunk
    • enters ticket number into 'svn merge' comment;
  • enters 'needsTag' into Review field
  • possibly notifies [LSST-data][DataChallenge?] if trunk change will require complementary changes in other modules;
  • on completion of the above, reassigns Ticket to Module Guru.

Ticket

    Status:  reassigned    Review: needsTag    Resolution:
                           checkStandards _x_  onTrunk _x_ checkUML ___

Module Guru

After the trunk has been moved into a Production branch

  • verifies that UML was reverse engineered (for batch of Tickets)
  • closes the Ticket

Ticket

   Status:  closed     Review: reviewed    Resolution: fixed
                       checkStandards _x_  onTrunk _x_ checkUML _x_

Reponsibilities for New Distribution Release

Module Guru

  • opens a new ticket for creation of production branch
  • ensures Lsst Project Requirements remain accurate wrt new implementation.
    • requires Guru to know all Tickets comprising the upgrade; if necessary, a new Report will be generated.
  • ensures module's overall testing framework is exercised successfully;
    • possibly includes integrated testing with other modules;
  • reverse engineers the trunk into the UML model;
    • calls upon Ticket Developers to assist in reconciliation if necessary.
  • updates the Ticket body with
    • attachment of the log from the module's testing framework,
    • the UML Change #(s) of the reverse engineering of the trunk into the UML,
    • the SVN changeset(s) for the production branch creation (not the individual Tickets comprising all the changes),
    • the LSST Version number defining the production branch.
  • closes EACH Ticket involved in the upgrade.

Since the creation of a production release is done in a short timeframe, the ticket status transitions may be compressed :

Ticket

      Status:  new  Review: needsReview    Resolution:
                    checkStandards ___  onTrunk ___ checkUML ___

Ticket

      Status:  assigned  Review: needsReview    Resolution:
                         checkStandards ___  onTrunk ___ checkUML ___

Ticket

      Status:  closed  Review: reviewed    Resolution: fixed
                       checkStandards _x_  onTrunk _x_ checkUML _x_

For this type of Ticket,

  • LSST Requirements check relates to 'checkStandards';
  • Tagged branch creation relates to 'onTrunk'.