Viewer Release Pipeline Update

Summary

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.

8 thoughts on “Viewer Release Pipeline Update

  1. Couple of points.

    The “beta viewers” you refer to aren’t beta viewers. They are release candidate viewers which are currently sitting in the viewer release channel as cohorts.

    Also, while release candidate viewers will, by default, install into the viewer release folder (or the last folder pointed to during the Windows install process), project viewers do actually install into their own folders under windows, which are quite separate to the viewer release folder.

    • You are right about beta and release naming. Oz is clear on that. But, the rest of the Lab isn’t. They do call them Beta Viewers on the main download page, which links to the ‘Alternate Viewers‘ page. You might notice the word ‘candidate‘ is not used on the linked to as Beta Viewer page, which is titled Alternate Viewers… So, I’m not overly concerned about being that precise about the names. And people are still going to think of them as Beta Viewers no matter what we or the Lab call them.

      Thanks for the tip on Project viewers I was thinking of testing their install process later today. That will save me some time. I am curious if the Project Viewers will keep the stand alone process or get pulled into the Candidate style process. I hope they remain separate.

      • The teminology has been pretty well set. “Beta viewers” are a separate entity to release candidates. In that an emerging viewer can go from project to beta to RC, for example, or it can go directly to beta and then to RC.

        That the download page hasn’t had the terminology updated is really neither here nor there – given that the Alternate Viewers page clearly distinguishes between Project viewers and Release viewers – and up until the move of the Maintenance Viewer from Beta to RC, also differentiated between Beta and Release.

        As to Project / Beta viewer installs – Oz has also been explicit. The intention is for viewers to only get pulled into what you call the “Candidate style process” when they are merged-up to the current viewer release code and become a release candidate. Up until that point, they do not necessarily have to be built using the current viewer release code, but can be built using any previous code base – such as the Cocoa Project viewer being built on 3.5.1. Ergo, it is more than likely they will retain separate install folders.

        • If you were talking to techies you would be making your point…

          For the majority of the SL crowd it makes absolutely no difference.

  2. According to Oz in the new process Beta viewers are supposed to be optional steps between project and release candidate viewers. The fact that the lab is now referencing release candidates as Beta viewers may indicate that the lab is having a welcome rethink on these release candidates that are marked as release viewers but are not. I have complained at the confusion that this causes – so hopefully they are revising the process again.

    • Your point is well made. I too hope the Lab cleans up its use of beta and release to be more consistent with how technical jargon is used in professional circles. Until then it is going to be confusing.

  3. Snowstorm is basically fixes contributed by third parties. One of the examples is the count of groups you have joined and that you can still join (you have joined 2 groups, you can join 40 more).

    It basically is how third party features and fixes get into the main viewer, like spellcheck, for example

Leave a Reply

Your email address will not be published. Required fields are marked *