SLDev-Traffic 25
sldev-traffic no 25
sldev discussions through August 31, 2007
Hippo Awards!
The Hippos were announced on the main blog. Read about the winners. Read about the prizes. Read!
Release Candidate Viewers
Bridie Linden announced the Release Candidate Viewer program. The goal is to provide release candidate viewers accompanied by early source drops, which will only receive bug fixes between the initial and final release.
Nicholaz Beresford said, "Can someone please pinch me, I think I'm dreaming?," and Blakar Ogre replied, "This is exactly what I asked for yesterday! :)" The timing of the announcement was amusing or frustrating, depending on who offered their view. Open source developers had been asking for exactly this, only days prior to the announcement. But with the program release imminent and a lot of hard work put into the planning and development, none wanted to steal Bridie's thunder. Sometimes surprises are still fun. :)
Hippotropolis Hangout
With the Hippos also came the new open source island, Hippotropolis, where most Linden-sponsored open source activities are now being located. The space is also usable for other open source events and meetings. Feel free to make use of the region!
Eventlet and Mulib
Ryan Williams (Linden) announced the open sourcing of Eventlet and Mulib. The list announcement is here, and there was a blog posting as well. These two libraries constitute the heart of the new backbone for back-end services, which are replacing most of the existing hard-wired database routines in the simulators. These represent the first of projects to follow, which will be developed primarily on the public svn and wiki.
Internally and on the list, there was discussion about how to best handle these projects, as they are usable well outside of the scope of Second Life. For now, it's been decided to discuss them on the existing viewer-centric SLDev mailing list and to use the SL JIRA and wiki. These may change in the future.
Grokking the Vivox Voice Daemon
John Hurliman expressed frustration at not receiving answers to questions about the closed-source Vivox voice daemon, rightly surmising that the line is drawn at the XML-formatted commands issued from the viewer to the daemon. Dana Fagerstrom and others echoed, and John created VWR-2029 to request documentation, which is now being developed internally. In the interim, most of the XML procedure calls are easily parsed, and developers are encouraged to add details or questions to the Voice page. Changes to how the daemon is used should not happen without first appearing in a release candidate, if not an earlier source drop still.
Voice CODECs
In discussing Vivox, Matthew Dowd shared his impression that most of the components making up the Vivox client are free software, with the exception of the CODEC. Chance Unknown named a few other CODECs in use in open source VOIP products, including GSM729, adding "a reasonable codec needs to have adequate noise suppression and suitable bandwidth for its intended use." To date, there hasn't been a firm recommendation of a comparable free CODEC that LL could pitch to Vivox, nor have criteria been established for what constitutes a good replacement.
User Interface Improvement Discussions
Benjamin Linden posted User Interface Improvements to SLDev, a page with a proposal for a newer, simpler approach to the UI. This spawned an extensive, broad-ranging discussion about custom UIs, OS-native UIs, and what constitutes good usability. The discussion is beyond summary, but is available in the archives -- simply search for topics with "shell" in the subject line. Remember too, that Benjamin holds regular Office Hours for discussing these ideas in real-time.
UTF-8 Open Source Fonts
Lawson English points out that many non-Latin-1 characters don't appear the same way (or don't appear) on various residents' machines. Alissa Sabre notes that OS-provided fonts are used for these characters, and behavior will be dependent on what fonts are available to the OS. There was a brief discussion about including a comprehensive font with the viewer, but the likely candidate turned out to be nearly as large as the viewer itself, as found by Farallon Greyskin, and the Linden i18n team previously as well. There wasn't any resolution as to how to best handle varying or broken appearances in international use.
Translating the Wiki
Alissa Sabre noted that she often receives questions about compiling the viewer from Japanese residents, and inquired as to whether she could translate the build instructions. Rob Linden strongly encouraged the effort, pointing to Project talk:I18n for translation guidelines.
Mike Monkowski notes that it's not possible to search for Japanese text at present, a shortcoming that's still standing.
Dale Glass' Viewer
Nicholaz Beresford has been very successful in drawing users to his own distribution of the Second Life viewer. Dale Glass has an offering with some features he eventually hopes to see added to the main viewer as well. Dale's avatar scanner and annoyance-fighting tools are already known and loved by some stores and clubs, but Dale now adds the ability to track the owner and the location of objects sending IMs from other regions. This has already proven useful in identifying a spammer. See more information in the release announcement!
Splitting up SLDev
There has been extensive discussion about splitting up SLDev, managing traffic, or creating expected tags to go into subject lines. Some of the proposals for subject tags are mentioned on MISC-642.
JIRA Emails
The topic comes up a lot. To date, there still isn't a way to subscribe to bugs in JIRA in order to receive notifications about status changes or additional comments. We're still bugging our vendor about WEB-58. This hasn't been forgotten.
Traffic is Back
Soft here! I usually stick to the third person for everything in SLDev-Traffic, but I'll break form for a quickie note, gambling that in creating -traffic, I've earned a little editorial leeway. I took a couple weeks off from writing while we tried to better focus and boost our open source strategy. We're still learning a few things, and making lots of incremental improvements in how we work, but we're far from perfect. I really want to thank so many of you for your frank criticism and feedback in the last few weeks on what we can do better, especially in the hectic "Upcoming viewer releases" thread, and during last week's open source office hours.
Some of the things that shook out of discussions were a commitment to more frequent source releases, doing a better job of roping Lindens who aren't SLDev regulars in on relevant discussions, the announcement of the release candidate program, and the collection of a number of loose-end items we still need to follow up on. I'm also hoping we can make the pipeline more transparent between patch import, through final release.
In keeping expectations realistic: Don't expect bigger changes overnight. There's big work yet to be done as we advocate open source internally. Nobody is having it thrust upon them, and we've deliberately not created an open source "department," in favor of trying to make this many Lindens' part-time work. The ideal is that eventually most Lindens are involved in open source, and the idea of an "open source department" is as silly as a "using email department," which is to say open source should be a ubiquitous tool, and a part of the Linden culture.
In order to spread involvement, we need to find ways in which Lindens' work is provably helped by community involvement, that is to say - a commitment to 10% time on open source activities yields more productivity from that 10% time than coding alone would yield. For some, this is as simple as waiting for developers to begin a new project that can be developed publicly, as with some of the newer server components. For others, we need to find the right tools and strategies for open source to prove itself to developers; the release candidate program has been a good example of this, with developers pleasantly surprised by the attention and feedback this unreleased code has received. They already see that the next release will be far better for it.
Other Lindens are eager to proceed, but don't yet know the best first steps to take. We're trying to encourage more use of the public JIRA and wiki for features in development for these Lindens, and we're trying to push more sldev mail threads toward developers working on related code in the hope that these will prove helpful enough to make more Lindens eager to develop publicly. The changes won't be radical, but I think if you look at how many Lindens appear in the public JIRA and in sldev discussions from one quarter to the next, you'll be pleased.
The thing you can do is to speak up when you're not getting something you need in order to do something you believe is important. I don't think there's a one of us who stays upset if you convince us we've fallen down on a specific promise, or that there's something more we need to do to make open source yield better fruit. Just remember to propose specific solutions if you're ever frustrated or at a loss for how to proceed. That's proven helpful to us time and again.
(hippos)
If you have to ask, you're not ready to know. If you're ready, it's just a fun little secret and a tiny bit of Linden culture. Nik Radford, Nicholaz Beresford, Able Whitman, Strife Onizuka and Dale Glass all said a few things about it. If you download the source, you might know what this is all about. :)
Thanks for readin'!