Hints on releasing a stable product

Holger Freyther zecke at openmoko.org
Fri May 16 15:28:13 CEST 2008


let me re-iterate the rules, this time as hints, on how to release a stable 
product and let me explain my reasoning.

Our goal: Release a software product that turns hardware into a mobile phone.
People: See the last mail (we know this part).

0. Set fixed versions (srcdate, srcrev, pv...) to allow building without 

1. Define a core feature set and allow no regressions to that. Our core 
functionality is being a phone. This includes entering SIM PIN, doing voice 
calls, send and receive SMS.

2. Update our stuff early and often after having tested that no regressions to 
our core functionality are introduced (smoke testing). Make the QA guys do 
fullsystem testing on the nighly autobuilds (hehe, they have to spec 
fullsystem testing...).


We use AUTOREV on the autobuilder. This means a random version of software 
gets built and we have difficulties finding out what was built.

Why is that bad?

	- You have no idea what you actually built. QA can't tell me what was wrong 
with their image. You have no base-line because everything is changing.
	- You need to have internet. I don't have it at home (violation of 0.).
	- You have no idea how big the change is you are building. I have attached a 
png showing some of the interdependencies of the stuff we create. E.g. a 
simple one line change to illume (to disable manual toggling of the keyboard) 
can result in an image that is not able to send SMS, enter your SIM PIN... or 
use keyboard input to any Qtopia app. Depending on my workload we might have 
a image that will not work for a week.
	- Comparing two images with each other is useless, so bisecting issues is not 
possible at all. With upgrading SRCREV one by one you can bisect. Without 
that you can not say if things get better or worse, you can say how things 
are now but not how two images compare to each other...
	- I will flash the nightly build, have a broken phone, I can not send SMS, 
have no date for friday evening and this will annoy me (I use my neo as 
primary phone).

My approach:
	- Have a baseline
	- Let people fix bugs, implement the spec, add the features needed, fix bugs 
myself and integrate that. Compare the result with my baseline. If it is 
better push it, otherwise go back or see how you can get something better 
than your baseline.
	- Create a new baseline and re-iterate.

The downside:
	- Due testing and assuring quality/core functionality you lag behind the 
latest versions of some packages. But you know what? This is a feature and 
not a bug. The distro-team is responsible for integrating the work of many 
developers. It is natural that _one_ developer wants to have his latest code 
in the image but sometimes updating versions has to wait due dependencies 
between the versions (like with Qtopia and illume on disabling manual 
showing/hiding of the keyboard). A developer shouldn't have to wait too long 
for getting updated stuff though but that is part of hint/rule #2. Seing his 
work one day after he did it in the final build would be pretty good and 
should be acceptable. The distro team will integrate the work of all 
developers, at least I think it/we should.

anyway, It is up to someone else to decide if we want to have a stable product 
or use the latest version of everything. I just know it is voiding the things 
I have done the last weeks.

back to actually writing code.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: april-software-update.png
Type: image/png
Size: 116205 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/distro-devel/attachments/20080516/81105a2d/april-software-update-0001.png

More information about the distro-devel mailing list