Back in November I wrote a blog post called "Eating dogfood and shipping software": http://dbaron.org/log/20121119-dogfood
Shipping good end-user software requires that the people developing the software and managing the development of the software actually use that software and understand the experience of users using that software. I think that understanding has been critical to Mozilla's past successes in shipping end-user software. Using the software leads to an understanding of which problems are the important ones, and it leads to the ability to test and polish the user experience. Those of us who have worked on Firefox for a long time often take this feedback cycle for granted. But I'm worried that Firefox OS isn't getting enough of this sort of feedback. Getting this feedback requires, of course, that people use the phone daily. And that, in turn, requires that they consider it usable. I've been trying to use builds of v1-train for the last few months, and my experience lately hasn't been that great; it's been quite a few weeks since I've pulled a new tree and found the result usable on a basic level. The most recent example (this week) is https://bugzilla.mozilla.org/show_bug.cgi?id=855021 . Frankly, I'm *shocked* that this sort of thing doesn't lead to immediate backout. (I don't think this is an issue related to anybody involved in that particular bug; I think it's about a culture that the project as a whole needs to build.) Whether or not we have the test coverage to indicate that basic functionality is broken, when basic functionality breaks, it needs to get fixed immediately, the same way that an orange or red tree needs to be fixed immediately. (Backing out isn't a punishment. Backing out is a way to keep the tree in an always-usable state. And landing again, when the problem is fixed, should be easy. Developers should expect to be backed out some (small) percentage of the time.) It would obviously be better if these problems *did* turn the tree orange. But even when they don't, they need to be treated with the same priority. It should be an expectation that everyone working on the product is using the product (and updating it regularly). And it should be an expectation that discovering a problem serious enough to interfere with that is a high priority (i.e., needs to be dealt with within hours most of the time, which may mean simply checking that somebody else has filed a bug and is looking for the regression range, or it may mean doing that). -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
