Jump to content

Deploy Plans for the week of 2019-10-14


Caleb Linden
 Share

You are about to reply to a thread that has been inactive for 730 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

13 hours ago, Nalates Urriah said:

Figuring what is where isn't that hard. TP to the Blue Steel, Le Tigre, or Magnum sandboxes and check the version numbers. Tedious, but doable.

You're presuming that all those RC sandboxes will be running the correct server version. This has not always been the case in the past.
 

Edited by Whirly Fizzle
  • Like 1
Link to comment
Share on other sites

The dating on the Release Pages now is different but STILL WRONG!  The Release to Main Server of ..528 MUST have been 15th Oct not 14th!  Yes the week began with Monday the 14th but for God's Sake,. LL  Main Server restart day is  the 15th, RC channel day is 16th.  Now I may be hard of thinking but the notes state the release date not the date of the "week commencing...", don't they?  The previous dates given for the Main Server Releases are both Tuesdays, so why now a Monday?  It makes no sense!

It's not complicated, it is easy to get this right, assuming any thought is given to what you're typing.  How is this sort of stupidity supposed to give us ANY confidence in LL?

Edited by Aishagain
additional info
Link to comment
Share on other sites

8 hours ago, Whirly Fizzle said:

You're presuming that all those RC sandboxes will be running the correct server version. This has not always been the case in the past.
 

Fair point... I haven't seen that happen, but I don't follow them close enough to know.

2 hours ago, Aishagain said:

The dating on the Release Pages now is different but STILL WRONG!  The Release to Main Server of ..528 MUST have been 15th Oct not 14th!  Yes the week began with Monday the 14th but for God's Sake,. LL  Main Server restart day is  the 15th, RC channel day is 16th.  Now I may be hard of thinking but the notes state the release date not the date of the "week commencing...", don't they?  The previous dates given for the Main Server Releases are both Tuesdays, so why now a Monday?  It makes no sense!

It's not complicated, it is easy to get this right, assuming any thought is given to what you're typing.  How is this sort of stupidity supposed to give us ANY confidence in LL?

You seem to think they are posting roll out or release dates. As best I can tell these dates in the release notes are typically the compile date.

Edited by Nalates Urriah
Added comment
  • Thanks 1
Link to comment
Share on other sites

@Nalates Urriah: Well, I'd sort of assumed that since the Notes are "Release" notes and the previous weeks' dates on Main Server "releases" were Tuesdays, that it should be a Tuesday this week as well.  If the previous note were not compiled until Tuesday, than gives them very little time for testing, does it not?

If they were called Compilation Notes, I'd agree with you, but they aren't. But hang on...the actual software identifier gives the compile/creation date surely?

No, I am sure they are "supposed" to be release or roll dates, so my comment stands.

Link to comment
Share on other sites

@Aishagain no no... Release Notes are not "compiled" in the way I meant it. Compiled in this context is when all the human readable coding is processed into executable code the computers can use. For programmers that date is important and that is the compilation date and time used in the version number. It is the version numbering & date code used to refer to which specific assembly of code was used for the executable. With 50 or more programmers working in a team and operations support people all focused on getting the right binary code loaded to the right places this is the key piece of information needed.

Compiles take hours. I would guess most release notes are put together during this time. But, the date and time of the release notes is not important, just the specific  version the notes are for.

The roll date is not important to the coders. That date is important to us so we know when to duck.

  • Thanks 1
Link to comment
Share on other sites

11 hours ago, Aishagain said:

he dating on the Release Pages now is different but STILL WRONG!  The Release to Main Server of ..528 MUST have been 15th Oct not 14th!  Yes the week began with Monday the 14th but for God's Sake,. LL  Main Server restart day is  the 15th, RC channel day is 16th.  Now I may be hard of thinking but the notes state the release date not the date of the "week commencing...", don't they?  The previous dates given for the Main Server Releases are both Tuesdays, so why now a Monday?  It makes no sense!

It's not complicated, it is easy to get this right, assuming any thought is given to what you're typing.  How is this sort of stupidity supposed to give us ANY confidence in LL?

It MUST not!!

2019-10-03T01:12:11.531528 is the long and wide declared version number with the time stamp of the compilation and the date below is a date automatically generated by the system that shows the date of the posting and can not be changed. Everyone knows when the respective rolling restarts will take place and, in addition, it will be announced again in the grid status. In this post here the start date of the respective week is assumed to be relevant and not the date of the respective rollout.

Edited by Miller Thor
  • Thanks 1
Link to comment
Share on other sites

@Nalates Urriah:Those comments are to varying degree correct but in one context irrelevant.

The point is that whatever date the Release Notes are referring to, they are inconsistent.  In previous weeks they refer to Tuesday's,whereas this week's appears to reference a Monday.

@Miller Thor: Roll dates are by no means "known by everyone" they can vary even from the schedule posted on  the Grid Status Page. Even then, the notes need to be consistent. 

The posted date of promotion of code to Main Server indeed must be correct.  If it is not, it is quite simply wrong.

This paragraph was deleted.  It was irrelevant and inappropriate.  I should not post before I am fully awake!

It seems to me then, that this new system of nomenclature has been developed purely to assist the developers and we the users must muddle along as best we can with whatever information we can glean.  We can no longer assume, it would seem, that the issue we are observing is software-related or a server or client glitch.

It still needs to be consistent. 

Edited by Aishagain
Link to comment
Share on other sites

@Aishagain Every week the same spectacle with you. The only troll is yourself. You've now been told by several people what it's all about. Obviously, this doesn't go into your skull as the situation is. In the future, please let your frustration sit down, that not everything is as you imagine in your seemingly sick brain, go somewhere else and get on your nerves from me with your neighbors or anyone else. Get away with the existing facts or let it stay at all, but don't get on our nerves all the time. It's not your head, it's about logical and systemic facts. 

Edited by Miller Thor
  • Haha 1
Link to comment
Share on other sites

Without some legwork I'm not sure exactly how to do it (although those sandboxes give hints), but I'm pretty sure we could post to these threads the magic key to decrypting which release numbers correspond to which RC channel so we'd all know WTF we're trying to talk about.

Of course this would utterly defeat the much-lauded goal of obfuscating that information and hence preventing residents from slipping into such slang terms for the releases. Even though Lab folks use only that slang, except when they're en-/decrypting the obfuscated nomenclature for residents.

Besides being fantastically aggravating to deal with, this new make-believe release naming convention must rank near the top of the Stupid Linden Tricks list.

  • Like 6
Link to comment
Share on other sites

@Aishagain at this point Miller just might be right or you are trapped in trying to be right or satisfying an OCD condition. Or maybe you just can't understand why correlation is not proof of causation.

When rollouts happen is a scheduled event for everyone's benefit. But, practicality and happenstance define when the rollouts actually happen. THe Lindens move things as quickly as they can. There is no cushion for when things go wrong. So, some rollouts are delayed. We've seen Tuesday & Wednesday rolls drop back to Wed & Thurs.  We have seen Wed's roll unwind later the same week on varying days. The same for the RC rolls. And we have seen RCs roll out on odd days.

The point is it is not the schedule that controls WHEN. The schedule is the goal and things usually go as planned. But, actual RL events and problems control the WHEN. The date stamp is not a goal to be met.

Also, the purpose of the rollout affects the WHEN. If a problem causes the login servers to fail, the fix will rollout as soon as it is found. They won't wait for Tuesday if the fix is for something more disruptive than the disruption of restart. It doesn't matter if the date stamp version number or release notes posting date says today as long as the fix rolls out and a disruption goes away.

So, this is my last try to get you aware of what is going on. You are now free to show your nature and have us classify it.

  • Thanks 1
Link to comment
Share on other sites

3 hours ago, Qie Niangao said:

Without some legwork I'm not sure exactly how to do it (although those sandboxes give hints), but I'm pretty sure we could post to these threads the magic key to decrypting which release numbers correspond to which RC channel so we'd all know WTF we're trying to talk about.

Of course this would utterly defeat the much-lauded goal of obfuscating that information and hence preventing residents from slipping into such slang terms for the releases. Even though Lab folks use only that slang, except when they're en-/decrypting the obfuscated nomenclature for residents.

Besides being fantastically aggravating to deal with, this new make-believe release naming convention must rank near the top of the Stupid Linden Tricks list.

I preferred the named channel references. But, I do see the problem for the Lindens. I disagree that the change is stupid. I see the change as a response to the stupid way people tend to report problems to the Lindens or talk about them in the forum. The Lindens needed a better way to get precise information or denote when complaints had no clue when a problem started.

Think about people talking about a problem with the Blue Steel release of 3 or four weeks ago... aaaah.... which version do you look at? Do the Lindens need to spend time sorting that out? I don't think so. I would rather they spend time on something more productive. Apparently they think so too.

  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

35 minutes ago, Nalates Urriah said:

Think about people talking about a problem with the Blue Steel release of 3 or four weeks ago... aaaah.... which version do you look at? Do the Lindens need to spend time sorting that out? I don't think so. I would rather they spend time on something more productive. Apparently they think so too.

Taking this same example, there is zero chance I'll remember the release number that was running on my region a month ago, but if I know it's on the Blue Steel channel at least I can go back and figure it out (as an individual or a Linden), assuming accurate deployment reporting. But now we're not supposed to know a region's channel, so to figure out what release it was running a month ago I first must solve the channel cohort problem and then do all the same work sleuthing through old deployment reports.

Or if we're talking about looking at old trouble reports filed a month ago, the full release number was always included in the About Second Life window and was as likely to be included in the report before as it is after the change; the reports that only said "Blue Steel" before will now say nothing at all to identify the release -- and we're back to the same two-stage detective work to ferret out the information.

At first I was giving the Lab the benefit of the doubt on this, but after a couple of weeks of this, I don't buy it at all anymore. At best it was stupid; it feels more like an attempt to deter resident discourse about reliability and performance problems. It's like preventing lost keys by turning off streetlights.

  • Like 5
Link to comment
Share on other sites

As I noted earlier, I wear a hair shirt briefly for allowing my irritation to show.  However I repeat:

"The point is that whatever date the Release Notes are referring to, they are inconsistent.  In previous weeks they refer to Tuesdays, whereas this week's appears to reference a Monday."

If someone can show me that my interpretation of that is wrong, all well and good.

Qie's suspicion that LL's intent was twofold, that is to make particular server versions easier for the devs to track, AND to obfuscate the actual channel to prevent user bias is entirely credible, indeed I believe that was LL's stated purpose.  The resultant confusion amongst many was probably NOT LL's intent, it is just the result of their action.

As I've said before though, it's often not merely what LL do but the WAY they do it..

Link to comment
Share on other sites

In theory, the servers would not have to have any names at all. Even knowing the version number is n.e. not really important.
It is sufficient to have the region name, or for advanced users, the estate ID and the date and time of the incident, in order to be able to access all relevant data in the database. 
Since not all problems are due to the region software, but often only affect one region, it is better to continue after this new procedure. Thus, it can first be checked whether it is a "local" error and this can be fixed immediately from the 1st level, or whether this is a bigger problem that must be assigned to the 2nd level. 
In this case, the opening of a ticket is necessary anyway. 
The main problem, however, is the user himself who either does not, very late or only gives very vague information about the region. 
It is important to sensitize the user so that, if he notices a problem, he immediately reports the problem, either in the form of a ticket, a jira or in live chat, notes down the name of the region and makes the time and a concise indication of the problem. Information like "in a sandbox where I was 3 weeks ago goes nothing" is absolutely incomprehensible and in reality unusable for support. 

That would be the same as saying, "In China, a bag of rice has fallen over."

From adults one should actually be able to assume that they are able to describe a problem at least in such a way that it is also understandable for the other person, in the case of 1st Level Support. Well, you can't expect every user to be an IT professional, but most of them are in SL long enough to at least provide more precise information than "there's nothing" or "there's a problem you're to blame".  When I look at some regions and then look at the statistics bar to see, for example, why there are such massive delays there, I usually realize why it is. However, the problem is not always with the region itself, but with the user who is located in the region. Scriptlag is not only generated by objects, but is also primarily burdened by the visitor of the region with 6 , 7 , 8 or even 20MB script load per person. Therefore, it is necessary to act as I described it above.

Edited by Miller Thor
  • Haha 1
  • Confused 1
Link to comment
Share on other sites

3 hours ago, Qie Niangao said:

At first I was giving the Lab the benefit of the doubt on this, but after a couple of weeks of this, I don't buy it at all anymore. At best it was stupid; it feels more like an attempt to deter resident discourse about reliability and performance problems. It's like preventing lost keys by turning off streetlights.

There are advantages to removing noise from the signal...

  • Sad 2
Link to comment
Share on other sites

10 hours ago, Nalates Urriah said:

I disagree that the change is stupid. I see the change as a response to the stupid way people tend to report problems to the Lindens or talk about them in the forum

If people can harm others with a usual kitchen knife it's not a reason to ban knives sales in the entire country to prevent it. Because then you'll have to ban forks, spoons and all the rest. Stupid people will still report "problems" to LL and they'll still complain about them on the forums without even bothering to check if it might be something on their end first, so nothing will change, just reasons will be different.

Before it was convenient to just open stats tab and check if regions runs on main channel or RC without having to go and check those messed up release notes with obscure numbers. Reasons? To help self-diagnosis in case of a problem, to know where to go during tuesday rolls and then wednesday rolls, instead of jumping between regions comparing those numbers (not all regions stay on one channel forever).

At the end of the day everything is still the same as before (until someone in LL decides to hide all information entirely), except LL made the change that wasn't needed. If it ain't broke, don't fix it. Old saying, but still true.

Edited by steeljane42
typos and corrections
  • Like 4
Link to comment
Share on other sites

6 hours ago, Miller Thor said:

From adults one should actually be able to assume that they are able to describe a problem at least in such a way that it is also understandable for the other person, in the case of 1st Level Support. Well, you can't expect every user to be an IT professional, but most of them are in SL long enough to at least provide more precise information than "there's nothing" or "there's a problem you're to blame". 

Of course there are reports that simply need more information to be of any value. The release channel nomenclature for versions really doesn't affect those reports anyway, one way or another.

The folks most inconvenienced by the change are, I think, those folks most eager to provide all information they can when reporting a problem.

Many SL folks really try to help investigate what seems to be happening when things go wrong. It's just not as simple as reporting everything immediately and letting Support filter it out: we all encounter way more WEiRDNeSS in SL than deserves reporting as bugs. Much of it will turn out to be PEBCAK (and we know that going-in) but much is also observing patterns that surpass some subjective threshold for writing up a defect report.

It's really not in Support's long-term interest to discourage such user engagement exploring problems in the platform.

  • Like 5
Link to comment
Share on other sites

On 10/17/2019 at 8:35 PM, Qie Niangao said:

The folks most inconvenienced by the change are, I think, those folks most eager to provide all information they can when reporting a problem.

This. 

There are two "script improvement" related issues I could be spending more time looking into, but I'm feeling rather disinclined. I don't want half or more of that time spent looking for regions where I want to test those issues. 

  • Like 2
  • Thanks 2
Link to comment
Share on other sites

1 hour ago, Willow Wilder said:

This. 

There are two "script improvement" related issues I could be spending more time looking into, but I'm feeling rather disinclined. I don't want half or more of that time spent looking for regions where I want to test those issues. 

I will, if the Lindens pay me to do it. 😋

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 730 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...