Snowglobe Development Process
From Second Life Wiki
Contents |
What is the Snowglobe?
See Philip's blog post "Intensifying Open Source Efforts" on March 30, 2009 for the initial announcement and explanation." The "Snowglobe" name wasn't revealed until a few weeks after that post, so you may see that viewer referred to as the "SLDev Viewer" or the "http-texture viewer".
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.
What should we expect for the next release?
For the latest status, see Snowglobe Current Cycle for the latest news on what's happening this release cycle.
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 entry and see if others agree with you. Refine the JIRA entry to get the idea clearly defined. You should set "Affects Version" to the current Snowglobe version, but leave the "Fix Version" unset (none).
If you're attaching your patch to an existing VWR issue, you should create a SNOW issue to link to it with the versions set as above.
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
This is the hard part. In the past, contributors would get other residents to vote for their contributions and Linden developers would choose from among the highest vote getters. It usually took quite a while to get through the process.
Now it's first-come first-served. The Snowglobe developers will look for Unscheduled issues using the "SNOW" project dashboard on jira.secondlife.com Send a note to the SLDev mailing list with the PJIRA issue title, issue number, and a link to the issue on PJIRA to get their attention, asking for comments on the PJIRA.
Try to keep discussions about the issue on the PJIRA, not on the mailing list. It keeps all of the comments together. Mailing list posts are very transient. Anything said there is quickly lost among newer posts. Anyone with a serious concern will take the time to read the issue before offering comments.
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. The developers will then calssify the Fix Version to the current version, the next version, or the mysterious future. If it is decided to be included in the current version, try to get one of the people who are authorized to commit code to the repository to look at the patch file.
It is quite difficult to evaluate a code contribution just looking at a patch file and reviewers will want to be sure there are no bugs before agreeing to commit the code.
Ironically, the review of code intended for an immersive collaborative virtual world uses primarily a text-based issue tracker for discussion. It is still very difficult to make visual presentations in-world and voice chat is usually considered exclusionary. So let your fingers do the talking.
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 weigh 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.
Release cycle
Here's the rough contour of what the release cycle will look like:
- Phase I : Merge window - we'll provide the general guidelines for the release (e.g. stating what improvements we'd like to focus on). More on the merge window in a bit.
- Phase II: Stabilization phase - bugfix phase. No new features, no big disruptive changes. Only fixes necessary to get the already completed features into shipable shape.
- Phase III: RC cycle - very short cycle at the end of the stabilization phase. Only fixes for showstoppers, and only shallow bugfixes (no gutting/replacing subsystems...just the least disruptive change that fixes the problem, saving the "real" fix for the next cycle)
Committing during the merge window
For the merge window: Specific feature/patch proposals should be discussed on sldev@ (let at least one full business day pass without comment before considering silence assent). All checkins should have a corresponding JIRA task with the proposed patch, either attached in JIRA, or a pointer to a specific patchset in a public source repository somewhere (e.g. Bitbucket). The comments on the JIRA task should have a comment from another committer (not necessarily a Linden) who has thoroughly reviewed the patch, and is willing to stake their credibility as a committer that the patch should be safe for checkin.
You'll need to take responsibility for the code you commit, especially if you commit a build breaker. Failure to do so may lead to you losing commit access, depending on the degree of carelessness exhibited. Reviewers will also be subject to scrutiny.
Quality Assurance
This process is designed to maintain high-quality releases while hoping to avoid the high-overhead associated with doing that. The Snowglobe QA page describes in more detail the process we'll use to maintain high quality releases.
Committers list
Other documents
See HTTP Texture for more technical details about the work in this branch, and Snowglobe for more general information about participating in this effort.
