Difference between revisions of "SLDev Open Source Viewer"

From Second Life Wiki
Jump to navigation Jump to search
(New page: =What is the SLDev Open Source Viewer?= See [https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts Philip's blog post] for the initial announc...)
 
(SLDev Viewer Development Process has been moved, it is now a redirect to Snowglobe Development Process)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=What is the SLDev Open Source Viewer?=
#REDIRECT [[Snowglobe Development Process]]
 
See [https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts 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.

Latest revision as of 15:09, 18 May 2009