Difference between revisions of "How To Submit A Viewer Change"

From Second Life Wiki
Jump to: navigation, search
(Snowstorm Workflow Detail)
(fixing permission column in table)
Line 70: Line 70:
 
| '''Start Progress'''
 
| '''Start Progress'''
 
| ''In Progress''
 
| ''In Progress''
|
+
| Assignee only
 
| When a developer picks a task to work on from the Sprint List, they Assign the task to themselves and execute the '''Start Progress''' transition, moving the issue to ''In Progress'' state.
 
| When a developer picks a task to work on from the Sprint List, they Assign the task to themselves and execute the '''Start Progress''' transition, moving the issue to ''In Progress'' state.
 
|
 
|
Line 88: Line 88:
 
| '''Approve'''
 
| '''Approve'''
 
| ''Approved''
 
| ''Approved''
| Assignee only
+
|  
 
|
 
|
 
* When the last reviewer has signed off, they should execute the '''Approve''' transition (which records an Approved By name).
 
* When the last reviewer has signed off, they should execute the '''Approve''' transition (which records an Approved By name).
Line 108: Line 108:
 
| '''Pass QA'''
 
| '''Pass QA'''
 
| ''Passed QA''
 
| ''Passed QA''
| ''Assignee only?''
+
|  
 
| When a QA tester has confirmed that the issue is fixed in a Development (or later stage - Beta or other release candidate) build, they execute the Pass QA transition.
 
| When a QA tester has confirmed that the issue is fixed in a Development (or later stage - Beta or other release candidate) build, they execute the Pass QA transition.
 
''Should this set a "QAed By" field to the current user?''
 
''Should this set a "QAed By" field to the current user?''

Revision as of 13:57, 27 September 2010


This is not the place to start if you want to change the Viewer; this is one part of the Viewer Integration and Release Processes, and before you belong here, you must have gotten your proposed change accepted (strictly speaking, if you want to do the work of implementing the change first, that's up to you, but you still have to go back and get the idea accepted before you submit the code). See How To Propose A Viewer Feature.

For general advice on how to prepare changes so that they can get through the review and submission process easily, see Submitting code.


Submitting an Integration Request

When you have a change that is ready for integration into the Viewer Development repository, it must be submitted to the Snowstorm Project Team .

Only the Snowstorm Project Team has commit access to the integration repository.

A full description of the Snowstorm workflow is below. The checks that must be done before submitting to the integration repository and the mechanics of creating that integration request follow:

Readiness Criteria

Changes must meet all of the Development Integration Criteria before it can be pulled to the Development repository.

  1. Functionality must have been reviewed and accepted by the Product Owner:
    Normally, this means that the item must be on the current Sprint Backlog for the Snowstorm Project Team or some other Linden viewer development team, and has been reviewed by the Product Manager for that team. See How To Propose A Viewer Feature.
  2. Design and code must have been reviewed by competent reviewers.
    Reviewer(s) must be identified in the Jira item(s) used to track the change.
  3. There must be a test plan
    The test plan must describe in detail how Integration QA can validate the modified behavior.
    • For bug fixes, putting the test plan into a Jira comment is acceptable (since the issue should already contain a documented way to reproduce the problem, this should not be much new work).
    • For features, links to wiki pages are preferred.
    • For features especially, building and distributing a viewer from the Project repository for live testing is strongly encouraged.
  4. The Project repository must have merged in the latest changes from Development.
    The results must be validated by building viewers for all platforms and doing at least minimal viewer testing.
  5. There must be a Contribution Agreement on file from each contributor to the change that is not a Linden employee or contractor.
    • External contributions must include the appropriate updates to doc/contributions.txt

Linden Submissions

Requests coming from Linden Lab developers not on the Snowstorm team will typically be working on issues in Jira projects other than Snowstorm. When the code is ready to be integrated,

  1. Put a clear comment in the issue pointing to the repository and changeset to be pulled
  2. Make sure that it is Unassigned
  3. Put it into Approved state
  4. Use the Move action (under More Actions) to transfer the issue from your project to the Snowstorm project.

The combination of Unassigned and Approved defines the Snowstorm integration queue, and one of the Snowstorm team members will pick up the issue and do the pull.

Note that by default all issues in Snowstorm are publicly visible.

Open Source Submissions

Open source contributors should be working on issues that are already in the Snowstorm project and on the Sprint Backlog, so the issues involved should already be in the Snowstorm project. For these issues, execute the Ready For Review transition (you must be in the In Progress state for this transition to be available).

Snowstorm Workflow Detail

The diagram and table below describe the workflow for issues in the Snowstorm Jira project.

JIRA-STORM-workflow.jpg

Workflow Transitions
From Transition To State Permissions Usage JIRA Fields on Transition Screen
Open Start Progress In Progress Assignee only When a developer picks a task to work on from the Sprint List, they Assign the task to themselves and execute the Start Progress transition, moving the issue to In Progress state.
In Progress Ready For Review Reviewing Assignee only When a developer has finished the work, they put a pointer to the hg repo and changeset into the issue, execute the Ready For Review transition, and Assign to the first reviewer (or leave it unassigned)
  • The combination of Unassigned and the Reviewing state is the queue for Snowstorm review requests. Anyone can take the issue from this queue.
  • The issue may then be assigned between multiple reviewers in this state, including at least code reviews and Product Owner reviews.
  • Hg Repo and Changeset
  • Assignee
Reviewing Approve Approved
  • When the last reviewer has signed off, they should execute the Approve transition (which records an Approved By name).
  • The combination of Unassigned and the Approved state is the queue for Snowstorm pull requests, and will normally be ordered by the time in state.

This transition should not be done until all of the Readiness Criteria have been satisfied.

  • Approved By (default to Current User)
  • Sets Assignee to Unassigned
Approved Integrated Integrated When a Snowstorm Team member takes responsibility for pulling the request, they Assign it to themselves (thus removing it from the queue), and execute the hg steps to pull the change to viewer-development. When that is complete, they execute the Integrated transition to move it to Integrated state (which again automatically sets the issue to Unassigned).
  • Set Assignee to Unassigned
Integrated Pass QA Passed QA When a QA tester has confirmed that the issue is fixed in a Development (or later stage - Beta or other release candidate) build, they execute the Pass QA transition.

Should this set a "QAed By" field to the current user?

Integrated Fail QA Open Used by QA to indicate that when tested in a Development (or later stage) build, the test failed
  • Set Assignee to Unassigned
Passed QA Close Closed When Release posts the final stable release that includes the change for the issue, this transition is executed.

Should there be a state to show when the build is available in a Beta between Passed QA and Closed?

Workflow Statuses
Status Description
Approved The project/code has been approved for merge to viewer-development
Rejected/Closed-Won't Finish? The project/code has not met the required integration criteria
Needs More Info Required integration criteria has been omitted from the request issue

Tracking

You can see the current state of the Snowstorm queues:

Reviewing
Development is believed to be complete, and issue is awaiting review and approval.
Integration
Change has been approved for integration into viewer-development
Testing
Change has been integrated and is awaiting QA

These and other Project Snowstorm tracking information are available on the shared "Snowstorm" dashboard in Jira.