Develop Viewer Code

From Second Life Wiki

Get Into The Backlogs

You should be familiar with the Snowstorm Project Processes; in particular:

• Changes that introduce new viewer features may not be submitted for integration without having been reviewed and accepted into the Product Backlog, and the relevant tasks included in the current Sprint Backlog.
• Changes to fix a bug that the triage process has Accepted must be included in the current Sprint Backlog in order to be submitted.
• There are some good ideas for things to work on in the Open Source Development Ideas filter

Everything that gets done should fit into the overall vision for the project, and the way to do that is to express proposals as stories in the Product Backlog. You can advance a proposal for new entries in the backlog by:

• Send a problem description to the opensource-dev mailing list (preferred)
• Send email directly to the leaders of the Snowstorm Project
• Propose a discussion topic for office hours of one of the leaders of the Snowstorm Project

  This last is ok if you need help formulating a good way to present your idea, but is not a substitute for ultimately writing it down.

In order to be ensured an opportunity to integrate changes during a given sprint, tasks that advance the change must be in the Sprint Backlog for that two week sprint. The tasks for the sprint are generally chosen at the Sprint Planning Meeting at the start of each sprint. Tasks may completely satisfy a story on the Product Backlog, or may be steps on the way. Tasks are chosen by estimating the amount of developer time available and choosing the highest priority items from the Product Backlog. You can strongly influence a given task getting into a Sprint by committing to complete it.

Developing A Change

See Viewer Integration and Release Processes for an overview of the code flow from developer to release.

The main Viewer source code repository is hosted at

http://hg.secondlife.com/viewer-release

which is another name for

 https://bitbucket.org/lindenlab/viewer-release

In order to implement and submit changes, you must obtain the latest code from there and make it available in a public mercurial repository (see below for how to do this free at bitbucket). See Creating a version control repository for advice on how to make effective use of Mercurial.

Steps To Submit a Change

One Time Setup Steps

• Sign and send in a Contribution Agreement
• Create an account at bitbucket.org - please use something that is recognizably the same name that you use as a contributor on the opensource-dev mailing list, the jira, and in world, just to avoid confusion. You may use any other public mercurial hosting, but this one is easy and free, and it's what we use, so we can probably help with it if you have problems.
• Make a local clone of the viewer-release repository

hg clone http://hg.secondlife.com/viewer-release

This is your local clean copy - you should not make any local changes to it (this will speed up and simplify other steps)

Per Task Steps

For each issue you work on:

• Make sure your local copy of viewer-release is up to date

cd viewer-release && hg pull -u

or, if you have enabled the 'fetch' extension you can do that in one step:

cd viewer-release && hg fetch

if you have not made any local changes to your copy of viewer-release, these commands will never require any merge.

• Make a clone of your the local viewer-release repo to a new local working repo named for the task (a convenient way to track this is to use the jira issue id as the repository name):

hg clone viewer-release storm-issuenumber

On file systems that support hard links, this takes very little additional disk space

• Make your changes in the local working repository, build and test the viewer
  • At appropriate times, but always before synchronizing as in the next step, check in your changes locally

cd storm-issuenumber; hg commit

• Before your final test build, you must synchronize with the main viewer-release tree:
  • Update your local clean copy as in the first step
  • Merge those changes into your local working repository:

cd storm-issuenumber; hg pull && hg update

this may require that you merge files to resolve overlapping changes from other developers

• When you are ready to share your code publicly
  • Check in any changes to your local repository as above
  • Using the bitbucket web interface, 'fork' http://hg.secondlife.com/viewer-release to create a new repo; name it the same as the local working repo: storm-issuenumber
• From your local working repository, push your changes to bitbucket:

cd storm-issuenumber; hg push https://bitbucket.org/your-account/storm-issuenumber

if you local repository is up to date, this will not cause a merge and will succeed (if not, return to step 4)

• Create a request for review using the Code Review Tool; you may be asked to update your change based on the review feedback.
• When your review has been approved, the jira issue will move to the Approved state, and in due course the change will be pulled from your repository to http://hg.secondlife.com/viewer-release.
• After the change has been pulled to http://hg.secondlife.com/viewer-release, both the local and bitbucket storm-issuenumber repositories can be deleted.