Not a release cycle length problem [LWN.net]

Not a release cycle length problem

Posted May 3, 2007 12:16 UTC (Thu) by davecb (subscriber, #1574)
In reply to: Not a release cycle length problem by nim-nim
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" (;-))

--dave

(Log in to post comments)

Not a release cycle length problem

Posted May 3, 2007 18:12 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

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

Sometimes, a company just makes QC work an official prerequisite of collecting one's paycheck; i.e. it hires testers for whatever they cost.

The reason the Linux kernel can't use this well-worn strategy for eliminating bugs is that the special economics of open source and community development don't provide a way to get people to do all that boring alpha testing (testing for the sake of testing) and debugging.

So we've been experimenting for years with release cycle lengths, bug tracking systems, etc. to try to find another way.

Not a release cycle length problem

Posted May 3, 2007 18:38 UTC (Thu) by davecb (subscriber, #1574) [Link]

I think we're in violent agreement (;-))

I noticed people break into Linux kernel hacking via the kernel janitors effort, and into at least one non-Linux kernel team by fixing bugs and escalations, so I speculated one might invite people to look at regressions as a good way of learning the newest code to go into the kernel.

--dave

Not a release cycle length problem

Posted May 3, 2007 19:14 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> The reason the Linux kernel can't use this well-worn strategy for
> eliminating bugs is that the special economics of open source and
> community development don't provide a way to get people to do all that
> boring alpha testing

It seems Adrian complains the alpha testing part is done. What's not done is exploiting all the testing reports.

Not a release cycle length problem

Posted May 3, 2007 22:05 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

The reason the Linux kernel can't use this well-worn strategy for eliminating bugs is that the special economics of open source and community development don't provide a way to get people to do all that boring alpha testing
It seems Adrian complains the alpha testing part is done. What's not done is exploiting all the testing reports.

Chopping the quote where you do, it looks like you're disagreeing. The end of that sentence is "and debugging." I assume it's the debugging part that nobody is signing up for.

I also strongly suspect that in the cases that concern Adrian, the testing done was beta testing, which engineers don't find nearly so objectionable. Beta testing is where you fire up the new code and try to use it for real work. Alpha testing is where you simulate using the code, for no gain other than flushing out bugs in it. That's what's boring enough that engineers seem to have to be paid to do it.