The following notes are taken from the TPV Developer meeting held on Friday November 22nd. A video, courtesy of Northspring, can be found at the end of this report. The numbers in braces after each heading (where given) denote the time stamp at which the topic can be listened-to in the video.
No Change Windows
As has been previously noted in this blog, week 48 (commencing Monday November 25th) is code freeze / no change window due to it being Thanksgiving in the United States. This means there was be not server deployments during the week and there will be no viewer release channel updates for the week.
The Christmas code freeze / no change window is scheduled to run from Monday December 16th through until Wednesday January 1st. This most likely means that once the code freeze comes into effect, there will be no major server updates until the 2nd week of 2014 (commencing Monday January 6th, 2014), and viewer updates may be likewise.
Both the Thanksgiving and Christmas no change windows effectively mean there are only two full weeks left in 2013 in which server deployments and major viewer updates are liable to be made. However, it is possible both periods could see project viewer updates appearing. This is because any project viewer which may be available will have limited use (only those particularly interested in using / testing it are liable to run it), and so minor updates, etc., to such viewers are not seen as being potentially problematic in terms of support issues.
As note in part 2 of this week’s report, the release viewer was updated using the GPU table updates release candidate, leaving just the Project Interesting RC in that channel.
There are upcoming RCs in the pipe awaiting release, including an updated version of the Google Breakpad viewer and another maintenance viewer RC, while the Project Interesting viewer is to update an update as well. However, as week 48 (commencing Monday 25th November) is a code freeze week for Thanksgiving, it is unlikely there will be any releases in the viewer release channel during the week.
Fitted Mesh Viewer
A number of JIRA have been filed in relation to the Fitted Mesh project viewer, and are receiving attention within Linden Lab. “We’re getting the repairs together,” Oz Linden reported to those attending the TPV Developer meeting, “And when we’ve got enough of them together to do a release with, that have been tested, then we’ll do an update to that one.”
Avatar Skeleton Files
The Fitted Mesh viewer actually contains a small number of actual code changes; the majority of the changes lay within the avatar skeleton and its associated filed (e.g. Avatar_skeleton.XML / avatar_lad.XML). This has led to speculation that other viewers can update relatively simply by using the revised avatar skeleton files. Responding to this, Oz said:
Ideally that’s true, but it turns out not to be quite completely true. It turned out that there were some code bugs that the new skeleton and weighting exposed. So there are actually some changes that will be beyond that. That is some code [to be changed].
“Adding bones exposed some limitations,” Nyx added.
One of the code fixes which is in progress appears to deal with the issue of how garments weighted to use the new skeleton appear in viewers which do not have the updates, as demonstrated in my preview article on the Fitted Mesh viewer, and shown below.
Time Frame for Formal Release
While the Fitted Mesh project viewer may well see one or more updates before the end of the year, there are no plans to progress it to a release candidate status before the start of the New Year (again, the no change windows would preclude that, at least in part).
Even with the changes now being made, the number of code changes within the viewer is “very, very small”, so when the code is in a position where the Lab is comfortable with TPVs taking it and merging it into their repositories, it should not create major issues. One thing that is not clear at this time is whether merging and incorporating the Fitted Mesh changes will be dependent upon merging other code releases coming out of the Lab, such as the Sunshine / AIS v3 code and the Project Interesting code.
Project Sunshine / AIS v23 Updates
Nyx Linden reports that the Sunshine / AIS v3 updates are going “really well”, and the Lab is focused on cleaning up the last few bugs of which they are aware, and it is hoped that the code will be ready for QA and then a project viewer soon, possibly prior to the December no change window coming into force. If the viewer does make it to a project release prior to that happening, Nyx will likely hold it over until early January.
In the meantime, the Lab is still keen to get started on more extensive load testing for the new inventory service, AIS v3, using the Sunshinetest regions (1-4) on Aditi. They’d preferably like the assistance of TPVs with this, the latter having been given access to the code a couple of weeks ago so that they could start work merging it into test versions of their viewers for this purpose.
Firestorm released a version of their viewer with the new Sunshine / AIS v3 code updates to their Beta testers in week 47, although this has yet to have the legacy baking code added back into it for the OpenSim version of Firestorm. The team is approaching this cautiously, as there is a need to try to isolate the code used in the legacy avatar baking process (which is still used on OpenSim) so that it does not interfere with / get altered by future merges with code from Linden Lab. Once this has been done, Firestorm plan to make the code available to other TPVs so that they do not have the same headache when faced with trying to reintegrate the legacy baking code into their viewers.
Both Firestorm and Kokua (the latter having integrated the Sunshine / AIS v3 changes into a test viewer at the start of November) have indicated they are now in a position to assist with any load tests. The hope is that this will take place during December.
One of the reasons the Lab is keen to get the load testing underway is so that any remaining issues with the server-side code can be identified, investigated and fixed prior to the code being deployed on any RCs on the main grid. Any initial deployment of the server code on the main grid would likely be handled “pretty quietly”, simply because it wouldn’t be exposed to any viewers that did not have the necessary updates.
“It is currently still in QA,” Monty Linden reported in reference to his current work with HTTP 1.1 changes within the viewer. while no bugs have so far been found with the new code itself, he did reveal that the work has uncovered “quite a few bugs in mesh in general”, which are being filed internally. Currently, it is predicated that the QA round is unlikely to finish before Tuesday December 3rd, so and project viewer will not be appearing until after that date.
In addition to QA testing not finding any bugs within Monty’s code, all the numbers coming out of the performance aspects of the testing are described as “equal or better than past history”.
In the interim, Monty is continuing to lay the foundations for HTTP pipelining. As indicated in my last update on his work, he’s been going through the third-party libraries and their repositories which are used in the viewer builds and updating them. This has led him into a number of “interesting” discoveries as a result of tracking through all of the repository dependencies, etc., and identifying the various package mismatches and unnecessary libraries which are being packaged with the viewer (noticeably in the Linux version of the viewer), as well as one or two libraries which are not being packaged when they should be, as well as the use of multiple versions of the same library (e.g. 3 different version of Boost, 3 or 4 different versions of zlib, etc.).