Difference between revisions of "SLDev Open Source Viewer"

From Second Life Wiki
Redirect page
Jump to: navigation, 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