Community Relations Archive
Thread: Suggestions on Patch Day angst mitigation
cydonia wrote:
SWEET!!!!!!!!! Now that made my day.
Fact is there is no excuse for a bug like no group music buffs excaping the testing phase. Thats just a giant flashing neon sign that says "THE TESTING IS NOT WORKING!!!!!"
I am glad to see your taking the right steps to correct the problems. GO DEVS!!!
Don't be too quick to bash the testers. Very often the TC people report bugs that do not get fixed before it goes live. They do not have a No Bug Policy in place, hence they feel it is acceptable to push out buggy code to a live server. That is their choice I suppose.
Also a year ago they put TC-Bria in place to do a live server patch test before any new patch went out. It worked wonders and all the patches since then have worked fine. They dropped TC-Bria from their testing schedule and of course got burned. As soon as you removea safety feature from any system you have an accident.
And yes, waiting an extra day to make sure you did your job right is ALWAYS a right decision. Not making sure your ass is covered is a sure fire way to waste a lot of time.
Calandryll_SOE wrote:
Bohdi-Tzu wrote:
Thank you for your candor, it is appreciated. Not to beat a dead horse, but I would also like to chime in on the notice for patches. Personally, I would like to see a full day notice before a major patch is pushed out. We (the players) all like new content, and nerfs aside, we're an impatient lot and want the new stuff as soon as we can get it. I suspect that you (the dev team) want to push out your work as soon as it's done.
That said, and in light of the history of patch day glitches, is there some urgent and unavoidable reason that when a patch is "done", and has passed your testing and Q&A, that you can't wait one more day to push it up and give some notice so that the players can prepare? Hotfixes like credit dupes and other exploits--sure, whack them with all due haste, but it won't hurt me to have to wait one more day to sample from my bantha, and if I knew a patch was coming today, I could plan (or not plan) my play accordingly.
Thanks for listening.
The issue with waiting an extra day after the publish is green lit is that it delays future publishes. It's always our goal to green light a publish as early in the day as possible, but sometimes one or two tricky issues can delay it until later into the night.In this particular case, waiting an extra day or even an extra week wouldn't have uncovered the problems that caused the downtime.
I am a developer in RL
Publishes should get delayed if they have bugs. Pushing buggy code with both regression and new errors that are FOUND on TC is irresposible.
In the development life cycle you need to nave proper unit, integration and acceptance testing.
Given that this happens constantly from an outsider it would appear that your testing sizing are inadequite. In each change you should be allocating time and resources to testing. Since the trend seems to be that a lot of bugs are found on TC then the amout of time a patch is on TC needs to be increased to allow the developers to address the issues found there. I would also look at your unit testing procedures.
If this means less on each publish then so be it
When you release code to live with bugs FOUND on TC it makes the developers look like a bunch of "fresh outs" that dont have a clue.
Blunt and to the point, but it's accurate.
You must rememebr to customers perception is reality.
Don't be too quick to bash the testers. Very often the TC people report bugs that do not get fixed before it goes live. They do not have a No Bug Policy in place, hence they feel it is acceptable to push out buggy code to a live server. That is their choice I suppose.
There will always be bugs, even large list of known bugs. But to delay a publish with critical fixes, needed content, and many non-critical bug fixes just because there are minor bugs is not a good idea. Bugs are given a priority and publishes get pushed live based on the priority on outstanding known bugs.
Also a year ago they put TC-Bria in place to do a live server patch test before any new patch went out. It worked wonders and all the patches since then have worked fine. They dropped TC-Bria from their testing schedule and of course got burned. As soon as you removea safety feature from any system you have an accident.
This has been addressed. The TC-Bria hardware is supporting the CU sandbox. It was not pulled because they did not want to do the extra testing, it was pulled to do lots of extra testing.
And yes, waiting an extra day to make sure you did your job right is ALWAYS a right decision. Not making sure your ass is covered is a sure fire way to waste a lot of time.
This is an odd statement, as if a SINGLE day delay would fix every problem. An extra day, in many cases does not allow much extra fixing to occur. It seems many thing a single day slip will fix all the outstanding problems.
As far as bugs getting to live. Most bugs are found by Sony internal testers but priorities get them pushed to test center. Most bugs including some new ones are found and prioritiezed. So the bugs that make it live are in many cases known and are scheduled to be fixed in a future build. But no matter how much you test or how long you test, having thousands of people doing thing that would never be anticipated will find new bugs. It is an unfortunate nature of the size and complexity of the code.
Scoooter wrote:
I am a developer in RL
Publishes should get delayed if they have bugs. Pushing buggy code with both regression and new errors that are FOUND on TC is irresposible.
In the development life cycle you need to nave proper unit, integration and acceptance testing.
Given that this happens constantly from an outsider it would appear that your testing sizing are inadequite. In each change you should be allocating time and resources to testing. Since the trend seems to be that a lot of bugs are found on TC then the amout of time a patch is on TC needs to be increased to allow the developers to address the issues found there. I would also look at your unit testing procedures.
If this means less on each publish then so be it
When you release code to live with bugs FOUND on TC it makes the developers look like a bunch of "fresh outs" that dont have a clue.
Blunt and to the point, but it's accurate.
You must remember to customers perception is reality.
^ QFE.
I am a big supporter of the developers and I defend them when people are bashing them out of turn or for no reason, but this statement seems accurate to me as well. The testing process needs more attention paid to it. The same bugs or iterations thereof often go from TC to live after having been reported by several people.
If the rush is to please the whiners who want more content or fixes NOW, you have to realize that you're just giving them more amunition. Please don't sacrifice quality for speed. Take the time to get it right.