[T-Mobile myTouch 4G Slide] Blue6IX:
I've waited a long time for your post.

...and I agree with everything you've said thus far in principle.

The concept of stable is in and of itself a dynamic thing in a place like this under the many varied intentions of the people developing anything here.

Consider that in many cases things are made as examples, or proof of concept. Such things may be deemed stable by the creator on the particular proof, yet be unstable for other uses.

In many cases, such things are outlined by the developer and the bounds determining stability vary widely from project to project, and developer to developer.

In the retail world of say, phone sales, and the manufacturers guarantee against defects, the business world is held to a certain threshold of accountability for providing a working product.

For us here, there is no money involved - people aren't paying for a product, and so lose at most up time with the device while it gets sorted out. The total loss of the device itself, as in hard brick, due not to user error but to developer error is where I would say the minimum standard of stability lies.

That bears, in my eyes, the closest relation to the business world standard of a manufacturers guarantee against defects. Buggy software, and the clarification thereof being the topic to pick apart - i'd like to get a consensus of how many other people feel that simply not hard-bricking the device due to developer error is the complete polar opposite of:

...where the quote is in-context of being a final, finished product.

The minimum threshold being the easier end of the debate to reach agreement on and build our understanding from.

....

So how does a developer get to stable projects?

Drawing a parallel from the manufacturing industry, the answer is quality control.

If your business is running assembly lines of product, at the end of the line needs to be a certain amount of quality control before shipping. Else the product could vary widely in stated ability and function. A shop with little to no quality control could be one equivalent to an unstable release.

This points us in a direction in the determination of stability - the comparable equivalent from our point of view is testing. You have to test your product (project) before sharing, else you don't know if it will work right.

Unlike an assembly line where testing is done on a random small sampling of pieces, a developer must rigorously test and retest the project (product) to ensure stability and reliability of function.

Of course, this begs the question of the standards involved in testing.

Ever seen this movie? The Pentagon Wars

It's a riot - but also illustrates the importance of standards in testing.

To us one way, arguably the most important way, is developing a consistent method of testing to properly evaluate the desired results.

Consider my first project of involvement at XDA was in understanding the differences in MicroSD cards for running CM7 booted off the Sdcard and not the internal memory of a device. Some cards were downright buttery smooth and amazing, other cards were downright impossible to work with. They were directly found to be the culprit of force closes, if it could be run at all.

Once we determined that there was a specific brand that could be consistently counted on to perform to spec (through a massive posting of speed test results by ever so many members of the community!!! :highfive: ) - I set about trying to determine how accurate the posted information was.

This thread: A Closer Look At MicroSD and Reader Speed

...was primarily established to determine how much the type of card reader used skewed the testing results.

Granted, i'm biased based on having written the article, but I would consider that project to be an example of rigorous standards of testing for a particular piece of information.

I use this example to make the point of stability. In this case it directly equates to validity of results. By recording all of the data, publishing all of the data, people can point out where my math may be wrong if i've made a mistake based on calculations of the raw published data.

( just like people can offer suggestions on published open-source code )

...or incorporate the results into further testing of their own - based on the validity ( stability ) of the data.

Another example of what I would consider trying to achieve a "stable release" of an answer to a question through rigorous testing: My first real doubleshot contribution.

So I put forth those two projects of mine to illustrate what I consider stable releases of information. If not, explain why?

So a stable release not only is important from a user perspective, but also from an open-source developers perspective.

How solid is the code(knowledge, information, etc...) being built on, if a coding (or other...) project? Is the code you are nudging in a direction you think would be interesting buggy to start with?

Is your own new code buggy to start with?

Do you just throw it out there and keep working with it until it works? Do you take the time to ensure it works to the best of your ability before releasing?

Both are very valid approaches - some radical concepts are seen to reality much more quickly because the incomplete thought was tossed into cyberspace to grow to maturity.

The developers ability to relay the type of project it is, and the expectations of use can in fact create the business world equivalent of 'buyer beware' in the context of placing the onus of determining stability on the end user.

Because stability really depends on perspective.

Saying that something is a daily-driver, i'd use it everyday kind of thing is most akin to the:

...that we are trying to define as the upper end of finished.

There again though, this varies based on perspective.

Pretend a large enough user base decided they didn't care about not having any bluetooth ability. Along come some ROMs that don't include that function. They state such, and otherwise have bugs on a very individual user level basis, if at all.

To that user-base, those ROMs are stable. What about you? You lose your bluetooth headset and can't do without that. Being as bluetooth is a functional piece of equipment within the device, any ROM without it is technically unstable. Can we agree with this?

Stability can also be defined, at least in part, by a developers ability and attention to resolve issues "Immediately, if not sooner". This becomes a determination of stability based on the developers ability and timeliness in resolving issues.

Otherwise stable software can become corrupted through interaction with other code that doesn't agree with it. There are a lot of apps out there, and Android is an environment allowing for much more freedom then the app store.

Due to the increase of involvement of chaos theory throughout the Android environment, I'd put forth that the stability of any software is in part tied to the developers attention to unforeseen interactions due to the scope of Android at large.

Here again, is another example - by this definition:

"Bulletproof was more stable when I was actively working on it - before I had to take a leave of absence." During that leave time, the ROM is less stable then it was before, because any new problems aren't attended to.

But we can say that not only the level of attention, but the quality of that attention is important too.

A consistent voluntary lack of desire in chasing down new bugs and fixing them could be seen as the equivalent of that crappy customer service call. Maybe you just exceeded the developers interest in the project, and to that developer it was stable for it's intentions at the time, and has moved on.

From one perspective, the project was completely stable. From another, quite the opposite.

There again, you have developers moving on to other phones, or using projects as stepping stones to other goals. We would need to agree to be able to define something as "stable to a point" if the project was brought so far forwards before the developer left it behind for others to build on.

Sometimes while building bulletproof I threw out stability and claims/remarks thereof in order to challenge the community to define what it was to me.

In the end, stability to me correlates to the endless anal attention to detail - on all fronts. To write clean code, to properly wipe and prepare the device, and the burden of utilizing a stable product rests with both the producer and the user - even if the only user is the producer.

Given the many facets of 'Stability' in trying to define it - how accurately can we do so?

I look forward to the postings on this thought experiment.