The viewer release pipeline is coming along. I still have not seen an official announcement or detailed explanation of how it works. I’m getting most of my information from the Lindens in UG meetings and by testing different install methods.
This pipeline is obviously for the Lindens and designed to allow novice users to help with viewer development. The idea is the Lindens will handle the installs and updates for the users once they make the first install and opt into the viewer testing plan. From that point on the Lindens push updates and catch the viewer’s crash reports. The user has little to do.
For now it is something for the general user. It has made testing by advanced users that run multiple versions of the SL Viewer much more difficult. I’ve uninstalled all but one version of the viewer.
Whether this will provide the Lab better information or not is debatable. They will get more stats and data from the areas where they need it. They control which beta the user gets once they opt into testing. So, they can direct more testers to the beta versions they need tested. I think that is an improvement.
But, more advanced usrs with more computer and programming knowledge will have to put more effort into running multiple versions. Will they do that? Some will and some won’t. So, I see it as a loss in the size of this group.
In the case of the textures that fail to download I can’t file a JIRA yet because I can’t reliably reproduce the problem. But, now I cannot try other versions of the viewer to see if they too have the problem. It is too hard to change from version to version. Th8is problem is not a crash. So, the Lab is getting very little if any information about it. Only three or four people are mentioning it at the UG meetings.
So, I may put up with a specific problem that bites me until it pushes me past some tolerance point. By then I’m frustrated and everything is going to be an annoyance. I’ll either file a lame JIRA, try another version, or go play Hawken. I’ll have to see how it goes. But I expect to be filing fewer bug reports simply because it is more difficult to do.
I think the pipeline as it is now will push some number of advanced users out of the testing program and slow down those that remain. Time will tell.
Will the additional data from novice testers the Lab can assign to their projects make up for the difference? Only the Lab is ever going to know.
Will we see faster viewer releases? Probably. Is the quality going to go up or down? I am not sure anyone will ever know. On the Lab side fewer JIRA and crash reports would indicate better quality. But… if fewer people report problems, get frustrated and leave SL that trend would be hidden in among all the other reasons people leave SL. The problem would be effectively hidden in the stats. Yep, they look good.
Like the USA’s unemployment current rate of 7.4% looks better than 8.2% from earlier this year and suggests things are going the right direction. Until one understands what the Labor Participation Rate is an looks at it. Having that participation stat reveals how some numbers can lie. Understanding how the official Participation Rate fails to denote the difference between full and part time jobs is also misleading. My point being the numbers are complex and require though to understand.
One has to consider the number of bug reports and the SL participation numbers together. Unfortunately the Lab like the government has no good way to analyze the causes of changes in or make up of the participation numbers. So, this could be another hidden problem.
OR… I could be wrong and the advanced users that are core testers will continue on in spite of the changes in the pipeline. There is also the possibility that the Lab will continue to change the pipeline so it works for novice and advanced testers. Time will tell.