How To Submit A Viewer Change

Open Source Quick Links

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.

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.
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.
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.
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.
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,

Put a clear comment in the issue pointing to the repository and changeset to be pulled
Make sure that it is Unassigned
Put it into Approved state
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.

**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.