Brooke Linden Posted September 29, 2011 Share Posted September 29, 2011 Here’s a quick update on where we are with some of the issues that we have been seeing since the Marketplace release a couple of weeks ago. WEB-4138 (Order confirmation email failures): we are still investigating the issue and hope to get a fix deployed next week. WEB-2920 (Add item number to distributions): This has been fixed in our development environment (with the listing id) and is being tested for a release to production next week. The order number portion of this issue was already deployed to production last week. As part of the deploy next week, we will be including the Merchant name on distributions you receive. WEB-4143 (L$ balance not updating automatically inworld): This has been fixed in our development environment and is currently being tested for a release to production next week. WEB-4152 (Listing count and pagination in merchant admin inventory): this has been fixed in our development environment and is currently being tested for a release to production next week. WEB-4150 (Unavailable and unlisted are incorrect in inventory view): This is the same underlying issue as WEB-4152 and will be addressed with that fix. We will post an update here once we get these fixes deployed (we are currently targeting Oct. 5, but this is not a confirmed deploy date) or if there will be a delay in getting these fixes out. Brooke UPDATE: Unfortunately, we will need to delay this release until next week. All of the above JIRAs are a part of this release. The target for next week's deployment is Tuesday, October 11, 2011. Link to comment Share on other sites More sharing options...
Josh Susanto Posted September 29, 2011 Share Posted September 29, 2011 "Has been fixed"... "is being tested". Am I the only one who sees this as inconsistent? Link to comment Share on other sites More sharing options...
WolfBaginski Bearsfoot Posted September 29, 2011 Share Posted September 29, 2011 I think there's a bit of jargon creeping in here, though I've seen other Lindens using the label "resolved" in the JIRA, for when the "fix" is going through the formal test process. From my own experience, I know how easy it is to miss your own dumb mistakes. I don't mind the jargon, as long as I can check what "resolved" means, and as long as the Lindens are consistent. Fot other reasons I don't feel any confidence in the testing Link to comment Share on other sites More sharing options...
Josh Susanto Posted September 29, 2011 Share Posted September 29, 2011 When they said they fixed other things in the past, they had not. "Jargon" is "jargon" for "bull$hit". Link to comment Share on other sites More sharing options...
Pamela Galli Posted September 29, 2011 Share Posted September 29, 2011 Thanks for the update Brooke :matte-motes-grin: Link to comment Share on other sites More sharing options...
Brooke Linden Posted September 30, 2011 Author Share Posted September 30, 2011 Updated to clarify what being "fixed" means. Hopefully that makes this clearer. In general, we fix a bug and then deploy it to our development environment to test before we release to production. Brooke Link to comment Share on other sites More sharing options...
Josh Susanto Posted September 30, 2011 Share Posted September 30, 2011 So LL is now operating with some other English Language Dictionary in which "fixed" is defined as including "not fixed"? Where might I be able to find such a dictionary? Link to comment Share on other sites More sharing options...
Anaiya Arnold Posted September 30, 2011 Share Posted September 30, 2011 You test stuff before deploying it? :matte-motes-evil: Link to comment Share on other sites More sharing options...
Nalates Urriah Posted September 30, 2011 Share Posted September 30, 2011 Rought crowd. It takes time for people to learn how the Lindens talk in their circles. When they have sorted out the cause of the problem they write a fix, which turns the word fix into a noun. (Reference) It is a common happening in the English language. It has nothing to do with whether YOUR problem is fixed or has stopped happening. I suspect their development environment is like the ADITI grid for testing project viewers and server updates. Sort of an alpha testing process. I wonder if there is a release channel like thing for the web changes? I doubt it. If I'm right, there is less QA and user testing for web fix than there is for viewers and servers. They probably can't roll a fix out for part of the users like is done for server versions. So, we'll see more problems. Link to comment Share on other sites More sharing options...
Darrius Gothly Posted September 30, 2011 Share Posted September 30, 2011 Anaiya Arnold wrote: You test stuff before deploying it? :matte-motes-evil: I can attest to the fact that they DO have a test platform for Marketplace. As part of the various "test jigs" I've created for the Marketplace Dev Team to use, I get "glimpses" of what they're doing ... and I see them testing. Now, with that said, I can't attest to how deeply they test or what factors and functions they test after a revision, but I can state beyond all doubt that they do have a test platform and they use it. Link to comment Share on other sites More sharing options...
Nefertiti Nefarious Posted September 30, 2011 Share Posted September 30, 2011 Josh - Remember, the tinfoil hat must be worn shiny side out. For those of you who slept through English classes, the bolded, underlined phrase is a modifier that modifies the phrase that precedes it. This has been fixed in our development environment and is currently being tested for a release to production next week. For those who have no software development and testing experience, large projects are typically created, improved and debugged in one set of computers (the "development environment"), then the changes are tested in a second set of computers (the test environment), before being inflicted released to the users in the "production" environment. What this means is that they found a bug and and fixed it. They are now trying various tests to see if the bug that was fixed makes the problem go away before they upgrade all the servers we use. Link to comment Share on other sites More sharing options...
Toysoldier Thor Posted September 30, 2011 Share Posted September 30, 2011 Darrius Gothly wrote: Anaiya Arnold wrote: You test stuff before deploying it? :matte-motes-evil: I can attest to the fact that they DO have a test platform for Marketplace. As part of the various "test jigs" I've created for the Marketplace Dev Team to use, I get "glimpses" of what they're doing ... and I see them testing. Now, with that said, I can't attest to how deeply they test or what factors and functions they test after a revision, but I can state beyond all doubt that they do have a test platform and they use it. Its not really a question if the LL Development & Commerce Team has an actual physical non-production system - or has labled something to be their "test" system (although it would interesting to know exactly how isolated their test system is from any aspect of the production system - i.e. do they share DB / APP server infrastructure with production? Do they tie their Test instance of App code to Production DBs? Do they have a true end-to-end test system?) The bigger question and what most of us already have answers to based on their long history of pushing atrociously bug ridden code into production is their maturity in proper code/system testing? For them to miss bugs on some of the most basic functionals that any test group with even a simple test plan would have caught screams of LL's inability to properly test code they produce. Just look at the list of JIRA's from their last production deploy of code. What is even more scary is that the LL Commerce Team created a Public Gagged Beta Test of Merchants signed up to test the Direct Delivery code. So not only did the LL Commerce Team not catch some of the most basic functionals, but even their 2nd line of testing - the Beta Testing Merchants - also missed all these basic bugs. With that in mind..... to my fellow MP Merchants.... can you all now see what we are all relying upon when LL Commerce rams the main Direct Delivery service into production? Honestly.... This is going to be scary white-knuckle days for all us MP Merchants that rely on MP for most of our SL sales. And that Brooke and even Rodvik still have ignored all calls in the forums and direct requrests to finally be more open and transparent on how and when the main DD will be rammed into MP tells me that no matter how ugly their deployment is - they dont learn any lessons. I only hope that Rodvik will tell Brooke that DD "WILL NOT" be deployed prior to the busiest holiday season. In the big-boy RL world of IT, most companies and IT Shops are forced to abide by "FREEZE PERIODS" where they are not allowed to make any significant changes in production systems. Lets hope LL will deem that the period from Halloween to New Years is a CHANGE FREEZE period. But we all know that wont happen with LL. Toy http://ToyTalks.weebly.com Link to comment Share on other sites More sharing options...
Anaiya Arnold Posted September 30, 2011 Share Posted September 30, 2011 Someone always has to come along and ruin perfectly good fun with facts.... /me shakes fist Confound you facts, you spoil all the fun! I actually more less meant this (but was trying to make light of the situation, particularly the fact that the subject matter of this thread is the numerous bug-fixes they intend to deploy to fix the bugs their testing missed last time they tinkered with the marketplace): For them to miss bugs on some of the most basic functionals that any test group with even a simple test plan would have caught screams of LL's inability to properly test code they produce. Just look at the list of JIRA's from their last production deploy of code. It may have been a little devlish of me, hence the emoticon thingie Link to comment Share on other sites More sharing options...
Ela Talaj Posted September 30, 2011 Share Posted September 30, 2011 Actually the term "freeze" usually means something totally different. A freeze period is a time period between testing completion and release to customer. During this period the release build is "frozen", that is no more makes are done for this version; developers still can make changes in their source code but it will not be submitted to source control for this version. But this all is a matter of terminology. The matter of substance is that the bugs introduced in the latest marketplace upgrade appear unrelated to the upgrade itself and to each other. This may indicate that the overall design did not properly encapsulate processes, that is they are not kept sufficiently separate from each other but affect each other in somewhat unpredictable manner. Data and methods that should be private are probably public so any developer can access and inadvertedly damage. In other words, basic principles of OOD/OOP may be violated in the design. This considered, the question becomes whether or not the design or at least sufficient portions of it are inherited from the old XSL street. Delivery relying on magic boxes seem to indicate so. If indeed true, we should look forward to the new direct delivery release as it may replace the flawed design elements with correct ones. Link to comment Share on other sites More sharing options...
Toysoldier Thor Posted September 30, 2011 Share Posted September 30, 2011 Ela Talaj wrote: Actually the term "freeze" usually means something totally different. A freeze period is a time period between testing completion and release to customer. During this period the release build is "frozen", that is no more makes are done for this version; developers still can make changes in their source code but it will not be submitted to source control for this version. But this all is a matter of terminology. The matter of substance is that the bugs introduced in the latest marketplace upgrade appear unrelated to the upgrade itself and to each other. This may indicate that the overall design did not properly encapsulate processes, that is they are not kept sufficiently separate from each other but affect each other in somewhat unpredictable manner. Data and methods that should be private are probably public so any developer can access and inadvertedly damage. In other words, basic principles of OOD/OOP may be violated in the design. This considered, the question becomes whether or not the design or at least sufficient portions of it are inherited from the old XSL street. Delivery relying on magic boxes seem to indicate so. If indeed true, we should look forward to the new direct delivery release as it may replace the flawed design elements with correct ones. Actually no it doesnt mean something totally different unless your scope of knownledge is only a Software Developer. And even when reading your your description that supposedly was "totally different" it seemed to be pretty close to what I said. Under ITIL processes, a CHANGE FREEZE is very simple and it is also much larger in scope than what you mentioned. A change freeze (or even a Change Chill) is a restriction or complete stop of ANY CHANGES to a scope of I.T. Systems that operate any critical PRODUCTION business operations for a period of time. This restriction or freeze is not something only relating to software, it applies to any changes the current operating porduction system with the exception of changes that are repairs or return to service of downed system. This includes, Application software patches, upgrades, code changes, Operating System patches, Upgrades / Expansion of Hardware, configuration changes to any systems, etc. ITS ANYTHING. These Change Freezes / Chills are for identified critical period of a business cycle where an impacted system could cause major losses of revenue or possibly cause the missing of important reporting periods. A good example is during a company's YEAR END processing or during the Christmas/Holiday Sales season. So Ela, that is what a Change Freeze is and it includes your scope of change freezes but way more. As for your conclusion that the rash of changes that all occured the moment after the Sep 13th change were not related.... How did you come to this conclusion? From all I see, they all seem to be related. Please share your insight as to how you know that they are not related. As a partner of LL, I am sure you know more about what happened inside the bowels of LL during this horrid set of failures and missed bugs..... Please enlighten us. Thanks Link to comment Share on other sites More sharing options...
Ela Talaj Posted October 1, 2011 Share Posted October 1, 2011 Toy, for the hundredth time, my only relation to the LL is exactly the same as yours, that is being their customer. I've no access to their code, never had and have no idea how it works. Yet, I fail to see a relation between such issues as for instance "Order confirmation email failures" and "L$ balance not updating automatically inworld". To my experience, these would be totally different subsystems. Even assuming they get the data from the same generic queue (I sincerely hope it's not the case), the balances update just fine on the dashboards so wouldn't be the queueing problem. Link to comment Share on other sites More sharing options...
Brooke Linden Posted October 5, 2011 Author Share Posted October 5, 2011 I just wanted to update this thread that we will not be able to deploy today. We are working to get this ready for a deploy on Thursday--we'll update here or just post the Release Notes if we can deploy. Brooke Link to comment Share on other sites More sharing options...
Toysoldier Thor Posted October 5, 2011 Share Posted October 5, 2011 Brooke Linden wrote: I just wanted to update this thread that we will not be able to deploy today. We are working to get this ready for a deploy on Thursday--we'll update here or just post the Release Notes if we can deploy. Brooke Didnt know your team had a planned deployment of an MP update today. Thankfully it didnt happen until Thursday. So in hopes you learned your lesson on not telling us about the changes until after the update from the Sep 13th deploy... PLEASE POST THESE RELEASE NOTES ASAP & BEFORE THURSDAY'S DEPLOY!! What is your fear about posting these release notes prior to the change?? Please give us a chance to prepare this time. Link to comment Share on other sites More sharing options...
Brooke Linden Posted October 5, 2011 Author Share Posted October 5, 2011 Unfortunately, we need to delay the Marketplace release until next week. The target release date is October 11, 2011. Here is a complete list of the changes that will be released: WEB-4138 (Order confirmation email failures) WEB-2920 (Add item number to distributions): The listing ID will appear on distribution transactions. As part of this fix, we will also include the Merchant name on distributions you receive, and will update the transaction type for revenue from sales. WEB-4143 (L$ balance not updating automatically inworld) WEB-4152 (Listing count and pagination in merchant admin inventory) WEB-4150 (Unavailable and unlisted are incorrect in inventory view) We apologize for the delay. Thank you for your patience and let us know if you have additional questions about what we are planning to fix in next week's release. Brooke Link to comment Share on other sites More sharing options...
TatianaDokuchic Varriale Posted October 6, 2011 Share Posted October 6, 2011 Thanks for the update, Brooke. Link to comment Share on other sites More sharing options...
Toysoldier Thor Posted October 6, 2011 Share Posted October 6, 2011 thanks for the update. Better you guys get these changes right than rushed. pin that your LL Development wall at LL... Better RIGHT THAN RUSHED Link to comment Share on other sites More sharing options...
Facebook
Instagram
Twitter
YouTube
Flickr
Recommended Posts
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