SLDev Open Source Viewer

What is the SLDev Open Source Viewer?

See Philip's blog post for the initial announcement.

Merov posted on SLDev:

We do hope that most of the innovations battle-tested here will eventually make it to the official viewer codebase but things that are clearly not mainstream enough or not very popular with this community simply won't make it there and that's ok. People will still be able to get those features in the "Second Life OSS" download though.

This document is an edited version of some of Merov's other comments on the SLDev list combined with an edited outline originally by Mike Monkowski.

How do I contribute to it?

Talk to the mailing list

First, you might want to have a discussion about your idea. Chat on the SLDev mailing list. Create a JIRA and see if others agree with you. Refine the JIRA to get the idea clearly defined.

Write your code

Writing code isn't just writing the lines of C++. It's also documenting the code, designing a test plan, doing the actual testing, and making sure it works in a variety of situations.

When you think it's solid, you should create a patch file (using a diff tool like svn diff) and attach the patch to the JIRA. You should attach the test plan in the JIRA, either directly in a comment, an attached document, or a nonvolatile link to it on the web.

Get your code reviewed

You should then ask in the JIRA, and possibly on SLDev, for comments on the code and for people to help by trying out the test plan. Give people time (at least a day, maybe quite a bit more depending on the complexity of your submission and the timing) to evaluate it and comment.

Keep in mind that a positive, engaged attitude on SLDev and in JIRA is likely to garner more support than a more negative approach.

Get it committed to the repository

It's like almost any other FLOSS project: there is a group of committers that do have commit privileges to the svn tree. The big difference with the "old LL way of doing things" is that this group of committers has Lindens *and* non-Lindens. Engage folks on SLDev to get support: are people interested by the feature, is this a worthy issue to fix?

If there is community support and a good review of the code from committers, the patch will be taken in and committed by one of the committers. Eventually, if your contributions are significant and in line with the project, other committers might propose that you to become a committer himself. The committers group grows by internal recommendations only.

If someone objects (and if our community is alive, there *will* be someone to object...), we debate and try to reach a consensus on this list. If there's a really contentious decision to be made (split debate), Philip, our BDFL (Benevolent Dictator For Life), will weight in and make the decision.

Track it through the merge process

Some contributions may merge back to the official viewer someday. That will be up to the LL viewer team to cherry pick and merge patches/commits separately.

This is not easy to do. Making this more manageable is one of the big reason for the push to hg (mercurial) which does make merges from various sources much more easier than svn.