Deploys for the week of 2012-01-30

[Jack Abraham]

Ayesha, if I'm reading Oskar's update right, the code with the ghosting problem will be pulled back and a different one, "maint-server", will be deployed to all the RC channels.

[Oskar Linden]

---

Ayesha Askham wrote:

Oskar

Forgive my obtuseness.  This issue with a new bug...does it mean that the ghosting issue will not now be fixed this week or did I mis-read?

Also, thankyou once again for your painstaking explanation of this process such that numbskulls like me can understand what has to be done each week.

I do hope this ghosting issue can be got rid of because it is not simply affecting region-crossers.  If an av that has previously been ghosted on a sim TPs back into that sim, apparently it can never get out again, even if it cleaned up its doppelganger!:smileysurprised:

---

The ghosting issue was created by the code on BlueSteel and LeTigre. That code will not be on any region after tomorrow morning. As for the claim that some avatars are permanently stuck I am unaware of that situation. If you find anyone who for certain cannot log in after tomorrow and support cannot help them let me know.

__Oskar

[WolfBaginski Bearsfoot]

Might it not be that the weekly release of new code is too frequent? If there is such a tight schedule, there seems to be no margin for error. Is that wise?

[WolfBaginski Bearsfoot]

I think that here we have to accept that we have different viewpoints. I'm not in the same timezone, and for much of my day support is of greatly reduced availability. The hours of full support over the weekend seem to be even shorter.

With my experience of the last weekend, I have to say that Support, when it was working, was good. But Second Life is a 24/7 service, and Support is not.

From my viewpoint, your relying on Support over a weekend was clearly not a sensible choice. 

 

[Ansariel Hiller]

Okay, I have to hook into this thread again, after I had to update the already perfectly working height indicator fix for the minimap in Firestorm:

"Fixed data in CoarseLocationUpdate messages for avatars above 1020m. These are now sent with a value of 255, which was previously sent as 0 in error. This fixes numerous mini-map issues with avatar relative altitude indicators."

I don't consider that as a fix. Instead returning 255 now makes everything even worse! With 255 returned as indicator, now a glorious gutshot is produced, where you can't determine if an avatar is at 1020m or not. To be more precise:

When the viewer determines the avatars and their positions, it first checks if there is a visible instance of a particular avatar available. If yes, it uses that position data, because it is not affected by the too small datatype chosen in the CoarseLocationUpdate message. If there is no object instance available, it uses the data from the CoarseLocationUpdate. Let's define 3 situations:

a) Avatar at 1020m, object instance available: Reports as 1020m

b) Avatar at 1020m, NO object instance available: Reports as 1020m

c) Avatar at 2000m, NO object instance available: Reports as 1020m

Question: How can you decide what case is applicable?

Answer: You cannot! You will have to treat 1020m as undefined. Before that questionable "fix", you could treat 0m as undefined. With the "fix" you produced a gutshot where right in the middle of the range is an undefined value.

Example of what will be returned inside the viewer by LLWorld::getAvatars():

• Return value 1000: okay, we can use this value
• Return value 1010: okay, we can use this value
• Return value 1020: UNKNOWN! Might be an avatar at exactly 1020m or at higher altitude but we don't have an object representation -> don't use for anything except displaying we don't know nothing
• Return value 1030: okay, we can use this value
• Return value 1040: okay, we can use this value

This has already been filed as SVC-7645

[Nalates Urriah]

WolfBaginski, the ones in the best place to decide the schedule are the ones planning and doing the work.

It seems to me you have an idea that by some change you will not have to experience problems. No matter what you, the Lindens, or anyone else does this is the process by which software advances and you will be inconvinenced from time to time. Expect it. Deal with it. 

"Anything that is successful is a series of mistakes." -- Billie Armstrong

I would also like to point out this is not the Lindens first week running SL.

 

[WolfBaginski Bearsfoot]

Nalates, I shall try to keep this simple.

Last weekend was a mess.

Oskar has said that a support fix was in place.

My experience, weekend and weekdays, suggests that the support system is inadequate for a service running 24/7, with customers throughout the world. The nine hour response time I experienced, on a weekday, suggests they couldn't cope with the problem. That hypothesis is strengthened by the fact that I had a prompt response early in the weekend. I infer that the support fix worked, but the system became overloaded.

These guys can program computers, but I wouldn't want them to be managing something important, such as the computer systems at my local hospital.

[Ayesha Askham]

Nalates

There is a problem here.  Wolf actually makes a very valid point.  Support (Live chat) services need to be available at times that are more useable to Non-US customers of Linden Lab.

24/7 phone support is not an exception in the commercial world it is a reality and a necessity.  It is long beyond high time that both Linden Lab itself and US based users of Secondlife started to realise that Secondlife is a global system, not a parochial thing.

That failure to provide adequate support was laid bare last weekend and compounded by support's inability to realise that the choice of ticket available to basic accounts did NOT include that suggested on the Grid Status page.

The lack of worldwide support and its very obvious lack of adequate training let Linden Lab down badly and made the company look foolish and amateurish.  That it is not should be plain to all, but the image that was given last weekend was  that of a company quite unable to deal adequately with its customers worldwide at a time that competent support was keenly needed.

The fact is that Resident help was mobilised far sooner and far more effectively than proprietory systems and that is NOT satisfactory at all.