Quality Improvement in Free Software: Release Management [LWN.net]

Quality Improvement in Free Software: Release Management

Posted Mar 20, 2007 16:13 UTC (Tue) by nix (subscriber, #2304) [Link]

Hm. I got a privilege error when I clicked on that link. Peculiar.

Quality Improvement in Free Software: Release Management

Posted Mar 20, 2007 16:30 UTC (Tue) by johnkarp (subscriber, #39285) [Link]

Hm. I guess they fixed the duplicate by removing the original... I can't
find it on the front page anymore.

Back to the topic at hand, though. I'd like to see his analysis of KDE.
The entire KDE-4-mega-release makes me a bit nervous... it was branched
off in July 26, 2005, and its release still doesn't look imminent, almost
two years later. I like the technological direction KDE 4 is taking, but
the release management seems questionable.

Quality Improvement in Free Software: Release Management

Posted Mar 20, 2007 16:49 UTC (Tue) by superstoned (subscriber, #33164) [Link]

I guess you didn't notice the fact they've been whiping up a release
schedule? October 23'th is the target for the final release... First
freeze (subsystem freeze) starts in less than two weeks.

http://techbase.kde.org/Schedules/KDE4/4.0_Release_Roadmap

btw. gotta love techbase...

Quality Improvement in Free Software: Release Management

Posted Mar 20, 2007 17:22 UTC (Tue) by johnkarp (subscriber, #39285) [Link]

Yes, indeed they have that schedule. But having a schedule isn't the same
as following one (example: Debian).

For nearly two years their KDE 4 codebase has been undergoing multiple
structural changes, so far unreviewable by ordinary users. IMO, perfect
growing conditions for bugs and regressions, so they will be spending more
time than they planned between freeze and release.

Quality Improvement in Free Software: Release Management

Posted Mar 20, 2007 18:27 UTC (Tue) by tbm (subscriber, #7049) [Link]

I haven't looked at KDE, but one on of the findings of my research (which I still need to discussing my blog) is that "big bang" releases don't work and that there are benefits with the publication of releases on a regular basis. For example, you create a tight feedback loop with users, contributions get out quickly, etc.

Quality Improvement in Free Software: Release Management

Posted Mar 20, 2007 18:44 UTC (Tue) by dmaxwell (guest, #14010) [Link]

The problem is that what they are trying to accomplish with KDE4 is hard to do with stepwise incremental releases. The port to QT4 alone is a huge change. Add to that the frameworks they want to obsolete and replace (DIE artsd! die! die!) and a "big bang" is pretty inevitable.

Anyhoo, the KDE devs HAVE pulled this off before. The change from KDE1 to KDE2 involved large structural changes that pretty much obsoleted KDE1 at a stroke and it didn't take very long before most people were happily running it. KDE2 to KDE3 was mostly the port to QT3 and QT3 wasn't so different as to require major code surgery; most third-party KDE2 addons were ported quickly.

KDE4 will be rough when it comes out but I have little doubt almost everybody will be running reasonably debugged versions within a year of release.

Quality Improvement in Free Software: Release Management

Posted Mar 20, 2007 18:57 UTC (Tue) by pointwood (subscriber, #2814) [Link]

Exactly, I don't see how they could have handled it much differently?

That of course don't change the fact that KDE4 is a massive change and has taken a long time.

Quality Improvement in Free Software: Release Management

Posted Mar 21, 2007 6:07 UTC (Wed) by akumria (subscriber, #7773) [Link]

The problem is that what they are trying to accomplish with KDE4 is hard to do with stepwise incremental releases. The port to QT4 alone is a huge change. Add to that the frameworks they want to obsolete and replace (DIE artsd! die! die!) and a "big bang" is pretty inevitable.

In hindsight, perhaps having a KDE 3.7 release which just did a very small set of focused changes, i.e. port to QT4 or replace artsd or some other infrastructure, might have been better.

Quality Improvement in Free Software: Release Management

Posted Mar 20, 2007 16:48 UTC (Tue) by iabervon (subscriber, #722) [Link]

I think his tables are a bit too number-centered. For the kernel, the difference between 2.4 and 2.6 is qualitatively similarly to the difference between 2.6.18 and 2.6.19 (because of the new policy; of course, the number of changes is smaller, because it represents unblocking work done over much less time).

It seems to me that there's never been a properly long-term stable series for the kernel, because old-style stable series (and especially distro-modified old-style stable kernels) and 2.6.16 had to incorporate changes that could lead to regressions in order to stay relevant at all (i.e., run on currently-available hardware). I think that a real long-term stable series could be made by having 2.6.x.y only include (backported) patches added to 2.6.x+n.y (i.e., changes that were put in as bug fixes to the -stable series, rather than being considered unnecessary for stability; since there's always a -stable series being maintained, any bug of significance left from the past that's fixed in new development also gets fixed in a -stable patch).

I think the idea of using a more mature version for stability, but backporting changes for functionality is fundamentally misguided, because that introduces the risk of regressions; and the risk of regressions in other areas due to updating is probably not as great as the risk of regressions due to subtle incompatibility of the new feature with the old support code, because the test coverage isn't available for the new feature in the old context.