wiki:LsstDCTicketWorkflow
Last modified 5 years ago Last modified on 01/31/2014 08:36:17 AM

LSST Data Challenge Workflow

from: LSST Trac Environment.

The DC Ticket Workflow incorporates ticket resolution and the standards compliance review of the implementation. The workflow provides traceability of code implementation and modifications facilitating end-to-end tracking of Requirements through Software Releases.

This workflow has proved rather cumbersome in practice, especially with short-lived tickets that still deserve a code review. A proposed simplification is described here.

Ticket Workflow Overview

The generic workflow process is:

  • Step 1: a new ticket is created;
  • Step 2: the ticket is assigned to a developer;
  • Step 3: the developer accepts the ticket and completes the task;
  • Step 4: if the ticket didn't cause source files to be modified, the ticket is closed; otherwise
  • Step 5: the ticket is assigned to a reviewer;
  • Step 6: if the review found no issues, the ticket is closed; otherwise back to Step 3.

Ticket Workflow

% Completion Reporting

When reporting in DM status reports the %Completion for a Ticket, use the general rules, below, for assigning the value:

  • use 0% if the solution is still being designed;
  • use 25% if the solution's design is completed;
  • use 50% if the solution is implemented and tested within the Ticket branch;
  • use 75% if the implementation review is complete, the Ticket branch has been merged onto the Trunk branch, and the Ticket is closed.
  • use 100% if the affected Trunk packages are tagged and released.

The above boundaries work well for implementation and bug fixing Tickets. However, for Tickets such as design-only and distribution requests, the above boundaries aren't suitable. Refer to the Ticket Workflow Scenarios to model appropriate %Completion boundaries for non-implementation Tickets.

Ticket Workflow

The descriptive text accompanying the Workflow transition selections is targetted for Tickets created for new development or modifications to existing implementations. The scenario for Tickets created specifically to create a new Distribution Package is demonstrated in New Distribution Releases.

The How-To on using svn and its repository to manage a Ticket's source modifications is available in the DM Subversion FAQ. Pay particular note to the information on svn merge.

new

Probably you selected 'New Ticket' from the Trac banner line and created a new Ticket by describing the issue and, if it was a programming problem, providing a script or scenario to duplicate the error. If the New Ticket needed to be resolved before another Ticket could be processed, the Ticket number of the Ticket being blocked was entered into the Blocking field. The Ticket type and the Ticket priority could also be set. After submitting the new Ticket, you were finally given Ticket transition options.

Ticket Types

The various types are defined:

  • defect: relates to some defect in product, code, procedure, etc
  • documentation: request for some or more or better documentation on specified item
  • enhancement: requests improvement to existing product
  • task: catch-all ticket type. This is the default.
  • design issue: relates to research, conceptual design or technical design issues
  • new functionality: requests creation of new product or addition of functionality to existing product
  • distribution request: request for product distribution, generally to LSST software stack
  • benchmark: relates to any aspect of benchmarking: performance, resource utilization, reliability, etc

Select the one which most closely matches the Ticket being created.

Ticket Priorities

The various Priorities are defined:

  • "Blocker" should be used for: 'I can't make any progress on critical-path delivery due to this'.
  • "Critical": 'I really need this soon to make progress on a critical-path delivery'.
  • "Normal": 'This is required for current DC completion'. This is the default.
  • "Minor": 'I need this sometime but not necessarily for current DC completion'.
  • "Trivial": 'This would make my life easier but is not required'.

Select the one which most closely matches the Ticket being created.

Options

[] leave as new.
[] assign to <user>. The owner will change. Next status will be 'assigned'
[] close ticket as <filled-in>. The resolution will be set. Next status will be 'closed'
[] postpone ticket's processing indefinitely. The owner will change to <user>. Next status will be 'deferred'

assigned

Someone assigned the Ticket to you. Either agree to work on it; hand it to another; or let it remain in 'assigned'.

Options

[] leave as assigned.
[] accept ticket. The owner will change to <filled-in>. Next status will be 'inTicketWork'
[] reassign open ticket to <user>. The owner will change. Next status will be 'assigned'
[] close ticket as <filled-in>. The resolution will be set. Next status will be 'closed'
[] postpone ticket's processing indefinitely. The owner will change to <filled-in>. Next status will be 'deferred'



inTicketWork

You accepted the Ticket which makes you responsible for

  • implementing the code according to Standards, compatible with the LSST Project Requirements, and to satisfy the Ticket's issue;
  • documenting the solution's progress in the Ticket log;
  • implementing a unittest for new features and/or implementing a regression test for repaired code;
  • including the ticket's number within all svn commit messages;
  • merging the ticket branch into the trunk; refer to the DM Subversion FAQ;
  • entering the trunk validation tests' output log as an attachment to the Ticket, thus demonstrating the modification's successful use;
  • and finally, reassigning the Ticket to the Standards Reviewer (or the Ticket Manager for reassignment) to review the code for standards compliance.

If successful implementation stalls, you may either reassign the ticket or ask for additional information.

Options

[] leave as in TicketWork?.
[] code tested & merged: send review request to <user>. The owner will change. Next status will be 'inStandardsReview'
[] work done, no new code to review: close. The owner will change to <user>. Next status will be 'closed'.
[] send request for info to <user>. The owner will change. Next status will be 'needInfo'
[] reassign open ticket to <user>. The owner will change. Next status will be 'assigned'



% Completion Reporting

When reporting %Completion for this issue:

  • enter 0% if the solution is still being designed;
  • enter 25% if the solution's design is completed;
  • enter 50% if the solution is implemented and tested within the Ticket branch;
  • enter 75% if the implementation review is complete, the Ticket branch has been merged onto the Trunk branch, and the Ticket is closed.
  • enter 100% if the affected Trunk packages are tagged and released.

needinfo

Someone requested info from you about this Ticket. Either provide the info or lack thereof and return Ticket to requestor; or let it remain in 'needInfo' until you can provide the info requested.

Options

[] leave as needinfo.
[] return requested info to <user>. The owner will change. Next status will be 'inTicketWork.'



inStandardsReview

Someone assigned you to review the modified source for standards compliance. Either review and select appropriate Ticket disposition; don't review and return to requester, or let it remain in 'inStandardsReview'.

If you agree to review, you are responsible for

  • checking that the modifications conform to LSST Coding Standards; and
  • ensuring that the validation tests successfully ran by checking the attached unittest log.

If either of the above is unsatisfactory, enter your concerns in the Ticket log and reassign to the developer for changes. Otherwise, note the review's satisfactory completion in the Ticket log and close the Ticket;

Options

[] leave as inStandardsReview.
[] close ticket as <fill-in>. The resolution will be 'closed'.
[] send outstanding issues back to <user>. The owner will change. Next status will 'inTicketWork'.



% Completion Reporting

When reporting %Completion for this issue:

  • enter 50% until the implementation review is complete, the Ticket branch has been merged onto the Trunk branch, and the Ticket is closed
  • enter 75% once the above conditions are met.
  • enter 100% if the affected Trunk packages are tagged and released.

deferred

This Ticket is postponed indefinitely. Either reassign to new owner; or close the ticket.

Options

[] leave as deferred.
[] assign to <user>. The owner will change. Next status will be 'assigned'.
[] close ticket as <filled-in>. The resolution will be set. Next status will be 'closed'.



% Completion Reporting

When reporting %Completion for this issue:

  • enter 0% if the solution is still being designed;
  • enter 25% if the solution's design is completed;
  • enter 50% if the solution is implemented and tested within the Ticket branch;

A deferred Ticket should never be merged onto the Trunk so %Completion can't increase to 75% unless the Ticket is reactivated.

close

This Ticket is closed. Either reopen and reassign owner; or reassign owner but remain 'closed'.

Options

[] leave as closed
[] reopen Next status will be 'new'
[] reassign to <user> The owner will change. Next status will be 'closed'



% Completion Reporting

When reporting %Completion for this issue:

  • enter 100% if no code modification was required or if the affected Trunk packages have been tagged and released;
  • enter 75% if the implementation review is complete, the Ticket branch has been merged onto the Trunk branch, and the Ticket is closed.

Sample Workflows according to Ticket Type

Role Description
Build Manager responsible for installing packages into Build Distribution system
Developer individual assigned to handle (design/implement/install/etc) a Ticket request
Package Owner responsible for overall design and release management of a package
Release Guru responsible for orchestrating a DM subsystem release according to the LSST Software Development Guidelines
Requester individual initiating a Ticket
Reviewer responsible for reviewing some aspect of a Ticket
SQA Team responsible for ensuring released products conform to LSST Software Development Guidelines

Code Defect, Code Enhancement, New Code, Embedded Documentation

This scenario outlines the workflow required for code development and its later maintenance.

  • 1. Developer creates a new Ticket for development.
    • Status -> new
    • %Completion = 0%
  • 2. Developer assigns Ticket to self.
    • Status -> assigned
    • %Completion = 0%
  • 3. Developer is ready to work on Ticket and accepts Ticket.
    • Status -> inTicketWork
    • %Completion = 0%
  • 4. Developer
    • completes design;
    • %Completion = 25%
  • 5. Developer
    • completes implementation and test;
    • %Completion = 50%;
  • 6. Developer
    • merges the Ticket into appropriate SVN trunk directory;
    • runs the Package unit test on the trunk version and
    • saves unit test result to Ticket, and then
    • assigns Ticket to Reviewer to check standards compliance.
    • Status -> inStandardsReview
    • %Completion = 50%
  • 7. Reviewer
    • checks standards compliance of code,
    • checks trunk Package validation has been done and finally
    • declares Ticket closed.
    • Status -> closed
    • %Completion = 75%

Note: %Completion for the Ticket won't become 100% until the affected packages are tagged and released.

Distribution: New Package Release to Developers

This scenario outlines the workflow required to tag a new version of a DM component and make it available for automated installation with lsstpkg.

  • 1. Package Owner creates a new Ticket for Distribution Release Generation.
    • Status -> new
    • %Completion = 0%
  • 2. Package Owner assigns Ticket to self.
    • Status -> assigned
    • %Completion = 0%
  • 3. Package Owner is ready to work on Ticket and accepts Ticket.
    • Status -> inTicketWork
      • %Completion = 0%
  • 4. Package Owner (see also Issuing Releases)
    • validates Package readiness by running unit tests and attaching results to Ticket,
    • reviews contents of package table file to ensure that (a) all required packages have a minimum version specification, and (b) all minimum versions are themselves currently released (not svn revisions),
    • copies trunk to tags directory using appropriate new tag,
    • records that tag within the Ticket comments, and finally
    • assigns Ticket to Reviewer.
    • Status -> inStandardsReview
    • %Completion = 50%
  • 5. Reviewer
    • checks unit test results and standards compliance,
    • checks that new tag is entered into the Ticket comments, and finally
    • assigns Ticket to Build Manager.
    • Status -> inTicketWork
    • %Completion = 75%
  • 6. Build Manager
    • installs new package so that it can be distributed via lsstpkg
    • checks the installation on supported platforms (see IssuingReleases)
    • reassigns Ticket to Package Owner or SQA team
    • Status -> inTicketWork
    • %Completion = 75%
  • 7. Package Owner or SQA team
    • reverse engineers software into EA model,
    • declares Ticket closed.
    • Status -> closed
    • %Completion = 100%

Distribution: DC Product Release

This scenario outlines the workflow required to baseline and release a DM subsystem product. For DC3, that involves the release of the Data Release Pipeline. The Release Guru is the individual responsible for marshalling the new Baseline through all the validation tests; the Release Guru works closely with the SQA team in certifying the product conforms to the Baseline's Software Development Plan.

  • 1. Release Guru creates a new Ticket for DC Product Release Generation.
    • Status -> new
    • %Completion = 0%
  • 2. Release Guru assigns Ticket to self.
    • Status -> assigned
    • %Completion = 0%
  • 3. Release Guru is ready to work on Ticket and accepts Ticket.
    • Status -> inTicketWork
    • %Completion = 0%
  • 4. Release Guru (see also Issuing Releases)
    • validates Release readiness by running integration tests and attaching results to Ticket,
    • archives the provenance of the Release, and finally
    • assigns Ticket to Reviewer.
    • Status -> inStandardsReview
    • %Completion = 50%
  • 5. Reviewer
    • checks integration test results,
    • Signs-off on Release readiness in Ticket comments, and
    • returns Ticket to Release Guru or SQA Team.
    • Status -> inTicketWork
    • %Completion = 75%
  • 6. Release Guru or SQA Team
    • if not done for each tagged package, reverse engineers software into EA model,
    • declares Ticket closed.
    • Status -> closed
    • %Completion = 100%

Distribution: 3rd Party Software

This scenario outlines the workflow required to install TCT-authorized 3rd party software into the DM software stack.

  • 1. Developer
    • creates a new Ticket for 3rd Party Software inclusion in DM software stack,
    • tests install of software noting the general build procedure and any customizations required,
    • when creating the ticket, includes a summary of the build procedure and special requirements in the ticket.
    • Status -> new
    • %Completion = 0%
  • 2. Developer assigns Ticket to Build Manager.
    • Status -> assigned
    • %Completion = 0%
  • 3. Build Manager is ready to work on Ticket and accepts Ticket.
    • Status -> inTicketWork
    • %Completion = 0%
  • 4. Build Manager
    • validates 3rd Party software is approved for DM inclusion,
    • installs software into LSST software stack, and finally
    • requests that Developer test inclusion using 'needinfo'.
    • Status -> needinfo
    • %Completion = 50%
  • 5. Developer tests 3rd party software is available and usable
    • enters comment into Ticket log, and
    • returns Ticket to Build Manager
    • Status -> infoprovided
    • %Completion = 75%
  • 6. Build Manager closes ticket
    • Status -> closed
    • %Completion = 100%

Design, Benchmark, Task, General Documentation

This scenario outlines the workflow for Tickets which are not developing or installing code.

  • 1. Requester creates a new Ticket for a non-programming task.
    • Status -> new
    • %Completion = 0%
  • 2. Requester assigns Ticket to Developer.
    • Status -> assigned
    • %Completion = 0%
  • 3. Developer is ready to work on Ticket and accepts Ticket.
    • Status -> inTicketWork
    • %Completion = 0%
  • 4. Developer
    • does the task requested,
    • enters appropriate comment into Ticket log, and
    • send the Ticket to Requester for review.
    • Status -> inStandardsReview
    • %Completion = 50%
  • 5. Requester reviews task completion
    • enters completion comment into Ticket log, and
    • 'closes' the ticket
    • Status -> closed
    • %Completion = 100%

Attachments