Appearently Test procedures are [Removed for Content].... fix them before implementing patches

[paco77]

<DIV> <DIV>You need to develop a better testing procedure. Setup a small lan aside from your current configuration and when you actually have a patch. Throw it onto the "test" lan and actually test to see if it works for the "Live" version of the servers. Seems everytime that you take something from the "Test" server and patch it to "Live" something prohibits the gamers from actually playing for 5+ hours. I think you seriously need to reconsider how you conduct your test procedures and fix this before implementing any more patches </DIV></DIV>

[CherobylJ]

<BR> <BLOCKQUOTE> <HR> paco77 wrote:<BR> <DIV> <DIV>You need to develop a better testing procedure. </DIV> <DIV> </DIV> <DIV>Setup a small lan aside from your current configuration and when you actually have a patch. Throw it onto the "test" lan and actually test to see if it works for the "Live" version of the servers.</DIV> <DIV> </DIV> <DIV>Seems everytime that you take something from the "Test" server and patch it to "Live" something prohibits the gamers from actually playing for 5+ hours. I think you seriously need to reconsider how you conduct your test procedures and fix this before implementing any more patches </DIV></DIV><BR> <HR> </BLOCKQUOTE><BR> <DIV>Paragraph 2 and 3 are in conflict (2 assumes no test server, 3 assumes a test server).  The test server (or other test sandboxes) are probably in place atm as that is what the audience of test community plays on?  </DIV> <DIV> </DIV> <DIV>Your chief grievance appears to be the amount of downtime on large patches.  Testting procedures dont determine this so much as migration procedures do.</DIV> <DIV> </DIV> <DIV>I'd imagine that on major patches they are probably making both code and database changes.  Code changes are usually not as involved (only involving a packaging/migration of code) between environents.  Database changes usually require a dump/backup/reload process...this can take several hours.  Not saying this is the case specfically but I'd imagine the downtime we are seeing with this patch invloves either technical constraints liek this OR a round of production level regression test before its brought up for the players.</DIV> <DIV> </DIV> <DIV>Either way I agree I'd like to see a shorter downtime window myself; however I'm sure there is a measure of complexity going on behind the scenes we arent fully aware of.</DIV>

[Proudfoot]

<blockquote><hr>paco77 wrote:<DIV><DIV>You need to develop a better testing procedure. Setup a small lan aside from your current configuration and when you actually have a patch. Throw it onto the "test" lan and actually test to see if it works for the "Live" version of the servers. Seems everytime that you take something from the "Test" server and patch it to "Live" something prohibits the gamers from actually playing for 5+ hours. I think you seriously need to reconsider how you conduct your test procedures and fix this before implementing any more patches </DIV></DIV><hr></blockquote>Answer this: How long does a normal patch take for EQ 1?How long does a normal patch take for DAoC?Anarchy Online?Several hours. Sorry, its not the Test server faulting every time, these games are taking longer and longer to 'patch'.

[Aegori]

<DIV>I'm really curious as to why downtime after a large patch is hitting people like an unexpected sack of bricks. It's happened with MMOs past, present, and will in the future. The difference between EQ2 and every other MMO that i've seen (with exception to WoW who does pretty good in their own respect) is that they admit their screw ups and even have given us bonuses in the past for unexpected downtimes. Also, when something like this occurs, all the employees at EQ2 are undoubtedly learning from their mistakes. Someone is likely getting the talk as we speak regarding the downtime and what it may cost the company. Will this assure it won't happen in the future? surely not... but it will make sure the devs are a lot more careful with how they patch. With the exception of the downtime, this patch has actually performed decently in that i haven't heard too much of an uproar regarding things that the patch horrifically broke. I know that patience isnt listed as a requirement on the box, but sometimes we just need to be understanding. </DIV> <DIV> </DIV> <DIV>-Aeg</DIV>

[prisoner]

<DIV>Downtime in eq2 seems like a snap compared to downtime in WoW.  I play both and lemme tell ya,  WoW seems to be down more than it is up(on the 20 or so "problem" servers at any rate).  Yeah downtime sucks,  but you gotta give props where its due.  Comparitively,  Sony has very little downtime.  Keep up the good work and thanks for a pretty reliable gaming experience.  </DIV>

[Naughtesn]

<BR> <BLOCKQUOTE> <HR> CherobylJoe wrote:<BR> <BLOCKQUOTE>Your chief grievance appears to be the amount of downtime on large patches.  Testting procedures dont determine this so much as migration procedures do.</BLOCKQUOTE> <DIV> </DIV> <DIV>I'd imagine that on major patches they are probably making both code and database changes.  Code changes are usually not as involved (only involving a packaging/migration of code) between environents.  Database changes usually require a dump/backup/reload process...this can take several hours.  Not saying this is the case specfically but I'd imagine the downtime we are seeing with this patch invloves either technical constraints liek this OR a round of production level regression test before its brought up for the players.</DIV> <DIV> </DIV> <DIV>Either way I agree I'd like to see a shorter downtime window myself; however I'm sure there is a measure of complexity going on behind the scenes we arent fully aware of.</DIV><BR> <HR> </BLOCKQUOTE> <P>Um...the biggest reason for the extended downtime on this last patch was caused by the 2147pp item sellback.  They manually searched for the 14 people who did it and corrected them, also the manually changed the stein to 0 sellback.  Better testing could have prevented this.</P> <P>Clone live toons to test now!<BR></P>