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

From Second Life Wiki
Jump to navigation Jump to search
m (add link to readiness criteria in Approval step)
Line 122: Line 122:
# '''There must be a [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Contribution Agreement] on file from each contributor to the change that is not a Linden employee or contractor.'''
# '''There must be a [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf 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
#* External contributions '''must''' include the appropriate updates to doc/contributions.txt
==Submission==
{{Todo|This is a temporary procedure - when the Jira upgrade is completed in early September, this will become Jira workflow in the VWR project}}
When the above criteria have been met and documented in the Jira issue or issues that track the change:
# If the issue is not already there, move the issue to the VWR project or create a VWR issue linked to yours.
# Execute the "''Change QA Status''" transition (on the left under "''Available Workflow Actions''")
#:[[Image:Change_QA_Status.png]]
# Set the status to "''Ready To Integrate''".
#:[[Image:Ready_To_Integrate.png]]
# Assign the issue to "Snowstorm Team"
#* If your account does not have the access required to Assign the issue, send an email to [mailto:oz@lindenlab.com Oz Linden] requesting that the issue be assigned.
If there are conflicts between your submission and another ahead of yours in the queue, then you may be asked to pull from Development after the other has been integrated and resolve any conflicts before resubmitting your request.  If this happens, your resubmitted request will get a higher priority to try to avoid the same thing happening again.

Revision as of 13:13, 9 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.


Snowstorm Workflow Overview

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.

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

JIRA-STORM-workflow.jpg

From Transition To State Permissions Usage JIRA Fields on Transition Screen
Open Start Progress In Progress 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 Assignee only
  • 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 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.

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?

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

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
Retrieved from "https://wiki.secondlife.com/w/index.php?title=How_To_Submit_A_Viewer_Change&oldid=1031333"