Hints on releasing a stable product
Holger Freyther
zecke at openmoko.org
Fri May 16 15:28:13 CEST 2008
Hey,
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
network
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...).
Issues:
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.
z.
-------------- 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