LL announce revamp to the viewer release process

secondlifeLinden Lab have announced a revamp to the way in which they will be releasing viewer updates in future.

Currently, the process for the majority of viewer changes is that they go through a progression – generally being seen first in the development channel (or sometimes prior to that in a project viewer), before moving through to the beat viewer (where updates go through what is effectively a final validation  / user test) prior to being adopted into the SL release viewer.

This system has generally worked, but can cause problems, particularly when there is a lot going on in terms of projects and updates, and things end up being “queued up” for the release (as is currently the case, where CHUI, Server-side Baking / Appearance, and a host of other updates / fixes are concerned all being “queued” awaiting their turn in the beta viewer release channel.

Another problem – as seen at the end of last year – can be that should a significant issue occur within the beta viewer code, it can completely block further viewer releases until such time as the problem can be tracked down and effectively fixed. Last year this meant that viewer updates were effectively stalled for around a two month period while LL sought to isolate and fix the problem.

To try to overcome any bottlenecks which might occur with viewer releases, the Lab is adopting a similar process to that used by the server-side code release mechanism, as the blog post explains:

We’ll release more than one new version at the same time in parallel to subsets of users for final validation, and then promote the most important of the best of those to the default Release Viewer when that testing shows it to be ready.

If a development project wants to put out an early version for testing prior to it being ready for the Release channel, a channel specific to that project (either ‘Project <project>’ for very early versions, or ‘Beta <project>’ for more mature ones) will be created, just like we do today. These will be shut down when the project is ready to move to final testing in the Release channel, and users in the early project test channels will automatically be upgraded to the corresponding Release candidate version.

This means that in the coming weeks, we’ll start to see different versions of the viewer start to appear in parallel in their own “release candidate” channels, and people will be able to choose which versions they want to download and try-out. Once it is deemed the code from a specific “release candidate” viewer is ready for release, it will be integrated into the SL viewer and made available to the community through the established mechanism. As such, the beta viewer channel will be vanishing in the near future.

Quite how well different flavours of the viewer will run together on a single computer for those who want to try-out more than one upcoming release remains to be seen. Generally, different versions of the SL viewer tend to play nicely together. However, as was seen with the 3.4 and 3.5 code base changes problems can occur. In that particularly instance, running a development or beta viewer using the 3.5 code and then swapping back to the SL release viewer on the 3.4 code resulted in all the toolbar buttons vanishing from the latter.

The overall hope is that this change will mean that specific features and updates will reach the release version of the viewer at a greater pace than can be achieved with the current process, which in turn should not only smooth the path for new capabilities and features to reach users quicker (allowing for the inevitable bugs and hiccups such projects tend to encounter anyway), but perhaps also help in get fixes for significant issues and problems out to the mainstream viewer.

SL projects update week 18 (2): server releases

Deployments for Week 18

The week 18 deployments make for interesting reading.

SLS Main Channel

On Tuesday April 30th, the Main channel was rolled back to release, as a result of a widespread performance issue.

Release Candidate Channels

  • BlueSteel and LeTigre: both of these channels should remain on the Experience Keys project, but will also be reverting some changes, due to the same performance issue which is affecting the Main channel – release notes
  • Magnum: should remain on the same server maintenance project as week 17.  This project brings some new minor features to LSL, and fixes some crash modes.  This update fixes the grid performance issue, and fixes an issue in which llDialog() messages sent to the object owner could be incorrectly throttled – release notes.

The performance issue which caused the Main channel to see the re-deployment of an older release was described by Simon Linden as being related to problems with regions locating their neighbours. “The performance problem was really showing up between any one region trying to locate another on the grid … the system was actually working, but too close to the cliff for comfort.” The re-deployment means that the new LSL AO capabilities can no longer be compiled / run on any Main, BlueSteel or LeTigre regions, until the supporting code is rolled-out once more.

There is still no further detail on the Experience Keys project and whether this may / may not be more than a deployment of the Advanced Creation Tools permission system.

Interest List Update

Andrew Linden has been working on fixing a bug related to Meeroos (but which I’ve seen affecting other animals as well), which he describes as, “If you turn your camera away from a crowd of Meeroos, wait several seconds, then turn back around… the Meeroos will be updated, but not quite in the right order. So sometimes you’ll see a head move to the new position, then a fraction of a second later the rest of the body.  So I have a theoretical fix that doesn’t crash the simulator (anymore).” The fix in question has yet to be tested and QA’d, so there is no time frame for any release.

“Missing” Prims

While talking about the interest list work, Andrew answered a question on missing prims / linksets, again acknowledging it to be a viewer-side issue, before going on to say:

We think maybe it is fixed in a new viewer. But this new viewer I mention happens to be very crashy, so we haven’t opened up the source code for it yet nor have we submitted it to our QA team since they’ll just crash …  This is the viewer that goes with our new interest list changes which I mentioned a few weeks ago and people were wondering when the code would be put up on a public repo.

"Missing" prims - viewer-side fix possibly on the way?
“Missing” prims – viewer-side fix possibly on the way?

So a viewer-side fix, along with viewer-side interest list updates, looks to be somewhere on the horizon.

Region Crossings

There have been a number of reports of region crossings worsening again after seeing a significant improvement with the release of the fix for BUG-1814. A common issue has been avatars becoming “snagged” at a region boundary while the vehicle they were travelling in continuing on its way, sometimes being returned to their Lost and Found folder from a location two or three regions beyond where the avatar became stuck. Both prim/sculpt and mesh vehicles are affected when the problem occurs, and it is an issue which had been encountered prior to the widespread deployment of the BUG-1814 fix.

Getting "snagged" at a region crossing while my aircraft flew on was a problem I encountered several times over Blake Sea early in April. The problem has again manifested itself to many, and I've again encountered it while flying my mesh Spitfire Mark IX
Getting “snagged” at a region crossing while my aircraft flew on was a problem I encountered several times over Blake Sea early in April. The problem has again manifested itself to many, and I’ve again encountered it while flying my mesh Spitfire Mark IX

I’d actually encountered the problem on April 4th during a series of region crossing tests, but the problem no longer appeared to be occurring by the middle of the month.

The issue of region crossings was raised at the Simulator Meeting on Tuesday May 30th, but the discussion was dominated by the problems being encountered by one particular type of train. In commenting more generally on region crossings, Andrew Linden said, “I agree that region crossing on vehicles needs more work. I can’t promise that I’ll be working on that as soon as I’m done with this interest list project, but I’ll try to bring it up in the next ‘what do we work on next’ brainstorm that we have.”