Not a release cycle length problem
Posted May 3, 2007 12:16 UTC (Thu) by davecb
In reply to: Not a release cycle length problem
Parent article: A tale of two release cycles
Agreed, it's a quality management problem... and a staffing problem in the QA part of the process.
A former employer, having become mature (and perhaps even a bit stogy)
used to use the "bus model" of releasing software, where a release would wait
until the bus was full people, then leave for its destination. This annoyed everyone, not least of whom was QC.
They now use a "train model". Every three months, there is a freeze on the current release stream, and the QC cycle starts on it. It takes about a month to exhaustively test everything, and two more to get the regressions
fixed and the brand-new bugs whacked down to a credible level. Then they release.
While they're finding and fixing regressions, th fixes are applied to the about-to-be-released code and also to the current development stream.
This, however, is just the "cycle" aspect of changing the release
architecture to provide enough time for QA to happen
As it's mildly hard to get developers into QC, the company makes
working in the QC process an unofficial prerequisite to becoming a member of
the kernel team. And it's a good way to learn enough to be able to break into serious development.
Think of a different kind of "kernel janitor" (;-))
to post comments)