Jump to content

Deploys for the week of 2012-09-03

Oskar Linden

By Oskar Linden,
in Second Life Server

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

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

Recommended Posts

Oskar Linden

Oskar Linden

Posted
Posted

Today is a holiday at Linden Lab. I'm getting the release notes out early so I can go back outside and enjoy my day off. There was a blocking issue found in the RC's last week SVC-8208 "L$ received notification not appearing when on an RC region". We had intended to do a release in the AM tomorrow. Much thanks to the resident who got my attention on Saturday so I could escalate emergency investigation into the issue. This disrupts our plans for main channel and RC releases this week. We cannot promote the RC code that we had intended to or release new code to the RC channels. Until everyone gets back to work tomorrow I can't know whether we will be able to have a release candidate for Wednesday morning. Hopefully we can, or we may need to do a Thursday AM release.

The code that is on the channels now will stay on there unless I update this thread.

Update: We will update the Magnum RC channel Wednesday AM and we will then update the LeTigre and BlueSteel RC channels on Thursday AM.

Second Life Server (main channel)

There are no changes to main channel. These regions will not be restarted.

2012-09-04, 5:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/12

  

Second Life RC BlueSteel

 Showstopper bugs were discovered in QA on ADITI Wednesday night. The code from Magnum was deployed here instead.

2012-09-06, 7-11:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_BlueSteel/12

 

Second Life RC LeTigre

This channel has the same code as Magnum.

2012-09-06, 7-11:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_LeTigre/12

 

Second Life RC Magnum

This code is on all three RC channels.

  • Bug Fixes
    • VWR-5044: Attachments only change/inherit the active group when they're "rezzed
    • VWR-25762: group owned objects appear as owned by (nobody) in Top Scripts and Top Colliders
    • VWR-20320: Show in search and set for sale remain enabled after owner changed
    • SVC-7760: Large object instant messages can corrupt returned object location URL making it impossible to determine the object's location.
    • STORM-1840: Searching legacy names in the "Choose Resident" floater with a period returns no result
    • SVC-7525: Selected objects move when a new keyframe motion is started
    • SVC-7793: Scripted agents can't abandon land on private estates
    • SVC-7917: Please automatically unmute avatars who have muted themselves, and prevent this from occuring server-side.
    • SVC-7968: When TPing using a landmark the server sends two TeleportStart packets
    • SCR-247: Scripts created by Residents who are limited to only the General maturity rating do not function as expected when inside an object that the scripter created that is running in a Moderate or Adult region
    • SCR-318: llInsertString & llSubStringIndex support for 4 bytes characters broken since 12.02.06.248938
    • SCR-359: The http_request() event fails to trigger in child prims that do not use llHTTPResponse() after it has received 64 HTTP requests and will not trigger again even if the script is reset.
    • SVC-8124: Excessive "ParcelOverlay reliable" messages sent by regions since last rolling restart (2012-08-08)
    • SVC-8136: Attachment point pelvis not being released
    • SVC-8146: llRezAtRoot() does not set correct parameters (for sale) on rezzed object in Second Life RC BlueSteel 12.08.03.263047
    • SVC-7641: Add object location info to messages, was "Object on land sending excessive messages
    • SVC-8177: There is different behaivior between the RC channels and the main channel involving permissions, objects lose modify permissions
    • SVC-8208: L$ received notification not appearing when on an RC region

 

2012-09-05, 7-11:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Magnum/12

 

We will be monitoring this thread during the next week so please feel free to post issues that you feel have been introduced by the new code. Please file a JIRA for issues you find and post the JIRA link into this thread. It really helps us out. When determining if issues are relevant or not research is key. Tracking down exactly the right situation where an issue is occurring greatly speeds up the development process to get fixes in place.

I appreciate your help. Have a good week!

 

__Oskar

 

p.s. If you are interested in helping test SecondLife in beta please join the group "Second Life Beta" in-world. We also have an email list where we communicate upcoming projects and how you can help. (https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta ) Once a week we meet on ADITI to discuss new features, new bugs, new fixes, and other fun stuff. You are more than welcome. Information is here:https://wiki.secondlife.com/wiki/Server_Beta_User_Group

 

This is not a forum thread for off-topic and unproductive ranting. I will no longer tolerate it. This forum thread is to discuss newly found issues in the Release Candidate channels. If you feel the need to have your opinions heard on topics unrelated to new bugs then please start your own thread. If an individual continues to post unproductive and off-topic comments I will take measures to remedy that.

If you are unsure about your posting please read this : "Linden Lab Official:Community Participation Guidelines"

Link to comment
Share on other sites
Ayesha Askham

Ayesha Askham

Posted
Posted

Oskar

I am puzzled about this SVC-8208 bug...it certainly isn't affecting me or anyone else on our LeTigre sim 9123 Woods of Heaven.  Yet it is slated as being a bug on all RCs!:smileyfrustrated:

Also I do not think I was hard on you or your colleagues in last week's Server thread.  No one with half a brain would say you don't work hard.  Lindens work, Linden Lab seems not to.

I hope you did enjoy your holiday!:matte-motes-sunglasses-2:

Link to comment
Share on other sites
Hitomi Tiponi

Hitomi Tiponi

Posted
Posted

I did suggest last week that you should have one RC running just the SVC-8124 fix, unless other fixes have to be applied at the same time.  With the user attention this matter is getting it would seem the best approach to make sure there is no other Showstopper bug that gets in the way of it's promotion.  Would this be possible?

 

Link to comment
Share on other sites
Qie Niangao

Qie Niangao

Posted
Posted

Of the fixes listed for the current RCs, Magnum and Bluesteel share the SVC-8124 fix; LeTigre apparently not. At first I was thinking that the blocking SVC-8208 might have been introduced with the patch to SVC-8124 (a stretch, I know), but because 8208 affects LeTigre, too, then that's probably wrong... and if these are independent, I have to agree: it would seem prudent at this point to have one channel running a release with the maximum likelihood of fixing 8124 without breaking anything else, which may be a new branch from the current main server release, with only those code changes needed to fix 8124.

Of course, if those 8124 changes are entangled with others merged since the main server release, then the work of disentangling them might generate more risk.

Link to comment
Share on other sites
Oskar Linden

Oskar Linden

Posted
  • Author
Posted

Paratrex, this is a forum thread for the QA team at Linden Lab to talk with residents about current issues in the Release Candidate channels in the attempt to stop these issues from going live. This is not a forum for everyone to whine about how bad they think LL is this week. Please keep your thoughts on topic and productive. If you would like to voice your strong opinions on things unrelated to the server code please create your own forum thread.

__Oskar

 

Link to comment
Share on other sites
Oskar Linden

Oskar Linden

Posted
  • Author
Posted

Ok here's the update. Finding that issue on a weekend with a Monday holiday has been very tricky. It messed up our whole release process and schedule this week. All the code that was to go to RC had to be redone. We had to investigate the issue, narrow it down, find a fix for it, build it, deploy it, and test it all in the timeframe of a few hours. This will continue to be tested overnight and we will have one channel ready for deploy Wednesday AM. Magnum will be updated then. The other channels will continue to be QA'd Wednesday for a Thursday morning release.

The Magnum channel notes are updated now.

__Oskar

Link to comment
Share on other sites
Oskar Linden

Oskar Linden

Posted
  • Author
Posted

Hitomi Tiponi wrote:

I did suggest last week that you should have one RC running just the SVC-8124 fix, unless other fixes have to be applied at the same time.  With the user attention this matter is getting it would seem the best approach to make sure there is no other Showstopper bug that gets in the way of it's promotion.  Would this be possible?

 

It's a good idea Hitomi and one that we have done before depending on the circumstance. It does however take pre-planning and is harder to do mid-release. The fix would be live right now if it weren't for the blocking issue discovered this weekend and everyone would be happy. To do it now would require us to go back in time. The problem is that the fix needs to be pulled and a special branch made for it which will then go through the entire build/deploy/qa process which takes time. Given that this week had no Monday we lost a lot of the time to set up a special situation like this. We would have had to have started the process last week to get it lined up for a Wednesday release. It's a very complicated set of procedures that each take time.

__Oskar

Link to comment
Share on other sites
Echo Hermit

Echo Hermit

Posted
Posted

Oskar Linden wrote:

Hitomi Tiponi wrote:

I did suggest last week that you should have one RC running just the SVC-8124 fix, unless other fixes have to be applied at the same time.  With the user attention this matter is getting it would seem the best approach to make sure there is no other Showstopper bug that gets in the way of it's promotion.  Would this be possible?

 

It's a good idea Hitomi and one that we have done before depending on the circumstance. It does however take pre-planning and is harder to do mid-release. The fix would be live right now if it weren't for the blocking issue discovered this weekend and everyone would be happy.
To do it now would require us to go back in time.
The problem is that the fix needs to be pulled and a special branch made for it which will then go through the entire build/deploy/qa process which takes time. Given that this week had no Monday we lost a lot of the time to set up a special situation like this. We would have had to have started the process last week to get it lined up for a Wednesday release. It's a very complicated set of procedures that each take time.

__Oskar

Can we go back to 1986 please ?

Link to comment
Share on other sites
Perrie Juran

Perrie Juran

Posted
Posted

Oskar Linden wrote:

Hitomi Tiponi wrote:

I did suggest last week that you should have one RC running just the SVC-8124 fix, unless other fixes have to be applied at the same time.  With the user attention this matter is getting it would seem the best approach to make sure there is no other Showstopper bug that gets in the way of it's promotion.  Would this be possible?

 

It's a good idea Hitomi and one that we have done before depending on the circumstance. It does however take pre-planning and is harder to do mid-release. The fix would be live right now if it weren't for the blocking issue discovered this weekend and everyone would be happy. To do it now would require us to go back in time. The problem is that the fix needs to be pulled and a special branch made for it which will then go through the entire build/deploy/qa process which takes time. Given that this week had no Monday we lost a lot of the time to set up a special situation like this. We would have had to have started the process last week to get it lined up for a Wednesday release. It's a very complicated set of procedures that each take time.

__Oskar

I hope I'm not getting too off topic but I wonder why you don't stagger the releases.  RC's one week, Main Channel the next.  I understand wanting to get updates onto the grid as quickly as possible.  But having observed the various problems that have come up lately as well as Roll Backs, etc, could staggering the release schedule be more efficient.

Right now we are left with the impression of people constantly scrambling.  Wouldn't a staggered schedule allow for better QA so when updates are employed they are right the first time?

There are still so many unresolved JIRA's that while they may be considered minor issues, the time you are spending doing fire control is time you don't have for addressing more of the backlog.

Thanks

Perrie

Link to comment
Share on other sites
Lydia Craig

Lydia Craig

Posted
Posted

Oskar we appreciate what you have done, but you should not be the one apologizing, it is the people who created this code and did not test it enough who need to be speaking not you, and we do not blame you for their neglect.  That said, as of today's restart for some reason the the lag and use of memory has accellerated greatly all over sl, and is at the point where it is beginning to effect log in with the DNS error, which is coming not from our isp not sending the DNS but the SL program not picking it up and relaying it through the log in process.  This is a major issue and if it continues will effect the recovery we have seen in online number over the last week and likely drive more away from sl.  This needs to be looked at and addressed quickly before it either gets worse or becomes the accepted norm for SL service.

Link to comment
Share on other sites
Hitomi Tiponi

Hitomi Tiponi

Posted
Posted

Oskar Linden wrote:

Hitomi Tiponi wrote:

I did suggest last week that you should have one RC running just the SVC-8124 fix, unless other fixes have to be applied at the same time.  With the user attention this matter is getting it would seem the best approach to make sure there is no other Showstopper bug that gets in the way of it's promotion.  Would this be possible?

 

It's a good idea Hitomi and one that we have done before depending on the circumstance. It does however take pre-planning and is harder to do mid-release. The fix would be live right now if it weren't for the blocking issue discovered this weekend and everyone would be happy. To do it now would require us to go back in time. The problem is that the fix needs to be pulled and a special branch made for it which will then go through the entire build/deploy/qa process which takes time. Given that this week had no Monday we lost a lot of the time to set up a special situation like this. We would have had to have started the process last week to get it lined up for a Wednesday release. It's a very complicated set of procedures that each take time.

__Oskar

Thanks for the reply Oskar.  I hope that maybe in future some sort of 'must fix because users are shouting' branch could be set up for similar issues that occur.  I actually think your release process works very well (especially remembering how it used to be), but I think this littlle tweak would be useful. :smileyhappy:

 

Link to comment
Share on other sites
Oskar Linden

Oskar Linden

Posted
  • Author
Posted

Hitomi Tiponi wrote:
Oskar Linden wrote:
Hitomi Tiponi wrote:

I did suggest last week that you should have one RC running just the SVC-8124 fix, unless other fixes have to be applied at the same time.  With the user attention this matter is getting it would seem the best approach to make sure there is no other Showstopper bug that gets in the way of it's promotion.  Would this be possible?

 

It's a good idea Hitomi and one that we have done before depending on the circumstance. It does however take pre-planning and is harder to do mid-release. The fix would be live right now if it weren't for the blocking issue discovered this weekend and everyone would be happy. To do it now would require us to go back in time. The problem is that the fix needs to be pulled and a special branch made for it which will then go through the entire build/deploy/qa process which takes time. Given that this week had no Monday we lost a lot of the time to set up a special situation like this. We would have had to have started the process last week to get it lined up for a Wednesday release. It's a very complicated set of procedures that each take time.

__Oskar

Thanks for the reply Oskar.  I hope that maybe in future some sort of 'must fix because users are shouting' branch could be set up for similar issues that occur.  I actually think your release process works very well (especially remembering how it used to be), but I think this littlle tweak would be useful. :smileyhappy:

 

Often we do. A lot of it depends on how quickly we can hear about it. It usually takes a few days after release for the dust to settle and the real issues to make themselves clear. Then we need to repro them, and investigate fixes. Each step takes time and sometimes we're past the point where that issue can be added to its own branch. Had we been able to find this issue in RC it would have been easy to stop. Once bugs hit main channel it can be a while before they get fixed.

The release this week has the fix and is looking good. Tomorrow morning I will suggest creating a separate channel with just that fix in case there are blockers this weekend.

__Oskar

Link to comment
Share on other sites
You are about to reply to a thread that has been inactive for 4245 days.

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

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share
Go to topic listing
×
×
  • Create New...