| |||||||||||||
Not a release cycle length problemNot a release cycle length problemPosted May 3, 2007 11:54 UTC (Thu) by nim-nim (subscriber, #34454)Parent article: A tale of two release cycles
I don't like this article too much.
Adrian was not complaining the release cycle was too short. "You want over-long cycles" is the spin people who didn't listen to him put on his message. Ideed some of the examples Adrian pointed at were problems reported a month ago (so there was definitely no lack of time to look at them).
Adrian was objecting to the general attitude consisting of silently ignoring problem reports if you feel like it.
His argument went this way. Developpers used to complain:
So Adrian:
This is a mass of heavy and painful work to undertake. And despite all this documentation efforts, some problems which had no good reason not to be fixed were not even looked at. And no one saw any problem with this (Indeed people told him to lower his expectations, and that of course they could ignore as many reports as they wanted. And when he asked for process/tool changes to make his work easier people asked him to do even more work without any promise to look at the result)
I perfectly understand his reaction. This was a blatant lack of respect towards his work (and the reporting work others did before, which he was the only one to acknowledge). When you ask a lot of volunteer work of someone the minimum is to do something with the result.
You have healthy projects where dev & test teams respect each other, and you have projects where developpers play prima-donas and consider every other bit of the ecosystem canon fodder. I guess the ugly truth is that the Linux project is in the second category.
We'll soon see if Adrian is replaced and if alienating him to save some inconvenient developper effort was the right thing to do.
(Log in to post comments)
Not a release cycle length problem Posted May 3, 2007 12:16 UTC (Thu) by davecb (subscriber, #1574) [Link] 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
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 testingIt 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.
Not a release cycle length problem Posted May 3, 2007 18:55 UTC (Thu) by iabervon (subscriber, #722) [Link] The problem, as I see it, was that things got to the point where the entire community was waiting for no more than 14 developers to debug things that nobody else had the appropriate knowledge to work on. (And some of these developers were waiting for bug reporters to get back with more information, too). And adding more people to debugging a small number of regressions would just slow down the process (c.f. Mythical Man Month). The only application of additional developer effort I could see actually being helpful at the point when 2.6.21 was released would be if Alan Cox could be convinced to fix serial port drivers (since he's got experience in that area he's not using).
I think, actually, that 2.6.22 wasn't forked soon enough; I think that the delay of the merge window meant that too much code was sitting in development without testing, leading to a drop in the quality of code appearing in -mm (which Andrew commented on for the 2.6.22 merge plans). On the other hand, I don't think the code tagged as 2.6.21 deserved the penguin pee. The real issue is that 2.6.x isn't released according to a release engineering process which creates stable results. Between the last -rc and 2.6.21, non-obvious patches were merged that added regressions. If this sort of thing happens, having more -rcs and spending more time couldn't possibly help. The solution, I think, would be for Linus to release even earlier, but have each series go through a period run by the -stable team with -stable rules before a final release that gets a penguin-pee version number.
Not a release cycle length problem Posted May 3, 2007 19:21 UTC (Thu) by nim-nim (subscriber, #34454) [Link] I think Adrian would have been happy if the various subsystem maintainers had made sure someone looked at each bug (or notified him some would not be processed). Reading his messages it seems no one even bothered with this. I'm pretty sure that does not qualify as "waiting for".
|
|||||||||||||