Question: If the "leaked" patches fix all the major issues with the Bionic...

[dlo-htown]

why isn't there an OTA patch released yet?

This is a serious question. I doubt (ok, I hope not that) Moto is using the "let's see what people post on Droidforums about the leaked patches" method of testing for the issues. Software testing is a very methodical and predictable procedure. Letting the general public customers "try this" method is absolutely one of the worst ways to go about it. It's hit or miss... and totally depends on the customer deliberately making the software go through the suspected paths that generate the problems. If the "tester" doesn't put it through all it's paces, exercising each part of the code, and then reports the phone is working great, what has been accomplished? No, the Motorola engineers have to be smarter than that.

The fact that there's still no OTA patch released tells me that Moto hasn't fixed all the bugs that are on the "punch list" they disclosed over a month ago, in particular the data dropout issue. All it takes is one person to apply the patch and say they still have the data dropout issue, to tell me it didn't fix the problem, no matter how many say their phone works great now.

The lack of an OTA fix only reinforces that things still aren't right with the Bionic firmware.

 

[SgtMike]

Non rooted here, I updated to the 5.7.893 and still experience data drop outs.

 

[GoBears]

Of course they watch the forums, it's cost effective risk free real world testing in addition to their engineers and developers. As consumers we will push these phones 24/7 in far more places and under more circumstances than their team of engineers and testers. I'm more concerned with why some bionics perform perfectly and some are horrible. For example, some people never had any problems at all and some went through 4 phones. My phone is near perfect after the leaks. It's super stable and crazy fast. Some people are still reporting problems, so I hope there is no hardware problems on the phone. I'm pretty sure some problems were on big red's towers needing tweaking too. Hopefully all will get resolved with the final OTA. They probably just have their hands full with trying to get this OTA final and get the Razr successfully launched. Hopefully I should say. Moto has not let me down yet, I sure don't want them to start now.

 

[scdown]

Non rooted here, I updated to the 5.7.893 and still experience data drop outs.

Same here, non-root, stock, 5.7.893, and I get data dropouts, but far fewer of them.

 

[mnowak1228]

Updated to 5.7.893 and still have data dropouts. I just keep my phone on 3G and it seems like its better. Also after update a day later my phone turned itself off for the first time and the only thing I could do to bring it up was a batt. pull. I also reseated SIM card and it hasnt shut down since, but yes, I still have data drop issues along with total signal loss. Im really hoping Moto fixes these issues bc I do love the phone when its working!!

 

[GoBears]

Just download the one shot upgrade zip and install it through stock recovery. No root necessary.

 

[dlo-htown]

Of course they watch the forums, it's cost effective risk free real world testing in addition to their engineers and developers. As consumers we will push these phones 24/7 in far more places and under more circumstances than their team of engineers and testers.

As a firmware developer, I totally disagree with this. It's totally FULL of risk. It shouldn't be the case, but that would explain why there's so many bugs in the Bionic's code. But to think that code is written and then dumped onto the masses for testing is really REALLY naive. No, be assured, this is NOT how it works.

I'm more concerned with why some bionics perform perfectly and some are horrible. For example, some people never had any problems at all and some went through 4 phones. My phone is near perfect after the leaks. It's super stable and crazy fast. Some people are still reporting problems, so I hope there is no hardware problems on the phone. I'm pretty sure some problems were on big red's towers needing tweaking too. Hopefully all will get resolved with the final OTA. They probably just have their hands full with trying to get this OTA final and get the Razr successfully launched. Hopefully I should say. Moto has not let me down yet, I sure don't want them to start now.

Unless you know exactly what conditions trigger the data dropout, you have no way of duplicating those conditions except by chance, to see if it's been fixed in the patch. That's just how you test software. So the fact that "some" people don't see the data dropouts after installing these patches is NOT proof that the problem is fixed. That's the "hope and a prayer" method of software development, and I would NEVER let anyone on my team develop and test software like that, because I'm just asking for bugs!

As far as pinning your hopes on the Razr being much better, maybe there's a different, "better" team of software developers working that phone's firmware, but I can't believe they are not re-using as much code as possible except for the code that actually interfaces with the hardware. So, I'm inclined to say "good luck" with the Razr.

 

[GoBears]

Well I am kind of basing my comments on comments made by a Moto employee. I guess it could be his opinion but I believe it. As far as the Razr, I am just hoping that the launch preparation is what is delaying the final OTA for us.

 

[GoBears]

I'm not saying they intentionally leaked it. Just that since it's leaked and being used they watch the comments on it. I should have clarified that.

 

[mnowak1228]

http://www.droidforums.net/forum/mo...-update-file-str8-moto-no-root-necessary.html

 

[GoBears]

Might as well get the big one that goes right to 5.7 and keeps the webtop.

Easily upgrade to 5.7.893, keep root AND webtop now - xda-developers

 

[guidot]

As a firmware developer, I totally disagree with this. It's totally FULL of risk. It shouldn't be the case, but that would explain why there's so many bugs in the Bionic's code. But to think that code is written and then dumped onto the masses for testing is really REALLY naive. No, be assured, this is NOT how it works.

Unless you know exactly what conditions trigger the data dropout, you have no way of duplicating those conditions except by chance, to see if it's been fixed in the patch. That's just how you test software. So the fact that "some" people don't see the data dropouts after installing these patches is NOT proof that the problem is fixed. That's the "hope and a prayer" method of software development, and I would NEVER let anyone on my team develop and test software like that, because I'm just asking for bugs!

As far as pinning your hopes on the Razr being much better, maybe there's a different, "better" team of software developers working that phone's firmware, but I can't believe they are not re-using as much code as possible except for the code that actually interfaces with the hardware. So, I'm inclined to say "good luck" with the Razr.

While I do agree with your logic here, I can say that being in field operations, you come to rely on your customers to tell you what is going on. Testing in a 'test' world does nothing for the field IMHO. You can 'test' a device being deployed in the field in a month, and as soon as it gets to your customer it fails on installation or within a month. Whether hardware or software related, customers report failures that 'testing' will never see.

For example, we have a machine that tests our equipment that we send to customers. It verifies all ports and buttons are working, as well as the software loaded and responding to commands (114 tests in all). Get it to the customer and have it hooked up and it won't even respond to input and won't load the latest firmware. A 'test' environment does nothing for real world implementation. My job is proof of that.

All devices have a life. Some last their expected life or longer, and others last 10 minutes. They are all built on an assembly line, from other devices built on an assembly line, from possibly others built on an assembly line.

 

[dlo-htown]

I'm not saying they intentionally leaked it. Just that since it's leaked and being used they watch the comments on it. I should have clarified that.

I understand.

But, you have to understand, software testing is very deliberate and methodical. Especially bug fixes... as I said, if the user doesn't know what the conditions are that trigger the problem, then they cannot deliberately test that, but instead it's left up to chance to see if those conditions arise and see how the software responds. You cannot leave software testing to chance like that. Beta testing is usually left to a small group with the specific purpose of trying to break the code, not just using it as a casual customer would day to day.

And, finally, unless the "testers" are documenting precisely what they are doing to create a problem, a software developer reading this forum has no way of knowing if the "reported" problem is the same one being tried to fix, or a totally new problem that "looks" similar but is triggered by something else.

Or, maybe I'm just giving Motorola too much credit?

 

[GoBears]

Or, maybe I'm just giving Motorola too much credit?

Well let's hope they are doing it right the first time, one OTA to set us straight.

 

[dlo-htown]

While I do agree with your logic here, I can say that being in field operations, you come to rely on your customers to tell you what is going on. Testing in a 'test' world does nothing for the field IMHO. You can 'test' a device being deployed in the field in a month, and as soon as it gets to your customer it fails on installation or within a month. Whether hardware or software related, customers report failures that 'testing' will never see.

For example, we have a machine that tests our equipment that we send to customers. It verifies all ports and buttons are working, as well as the software loaded and responding to commands (114 tests in all). Get it to the customer and have it hooked up and it won't even respond to input and won't load the latest firmware. A 'test' environment does nothing for real world implementation. My job is proof of that.

All devices have a life. Some last their expected life or longer, and others last 10 minutes. They are all built on an assembly line, from other devices built on an assembly line, from possibly others built on an assembly line.

I was trying to simplify a complicated process to the casual reader that may not understand the development/test/fix/test/release process.

I agree with your statements, but its my experience that what you speak of usually involves new development. Once you have identified certain bugs in the initial test release, you can be MUCH more specific in your research into what exactly is causing the problem, so you can then identify why the logic is not handling those conditions properly. Likewise, the testing is much more specific too. It is not left to chance as to whether the conditions have even occurred, thus not triggering the faulty software execution, as proof that the software is fixed.

Unless the casual user knows exactly how to trigger the faulty code execution, letting them use it and say it works fine does nothing to tell me if the problem is fixed, however I will give you that if even one person reports the problem has recurred, then I could be fairly sure the problem wasn't fixed, and that perhaps I don't correctly understand the triggering conditions or have simply not corrected the faulty logic.