The state of the feature freeze

The 2.5 feature freeze is now three weeks old. At this point, it mostly appears to be working as intended. The biggest exception (the new module loader) will be looked at in a separate article.

One of the goals of the freeze was to give developers a well-known target date so they would not flood Linus with last-minute patches. There was a big wave of patches that came through in October, but it was small and well organized compared to the deluges that came after previous (surprise) feature freezes. These patches were, for the most part, in reasonably good shape. With relatively few exceptions, the post-freeze kernel is in relatively stable condition.

The freeze is holding reasonably well. The only really new features that have gone in recently are the new module loader and high-resolution times in the stat64() system call. Linus has put his foot down when faced with a number of destabilizing changes, such as some overzealous header file "cleanup" work. He is still considering a few new features (kexec, kernel probes, and POSIX timers), but they are relatively small and went into the queue well ahead of the freeze date.

Of course, it is far too early to conclude that the freeze will actually hold - we have to wait to see what happens in 2003 for that.

The 2.5 stabilization process will, hopefully, be helped by the bugzilla database that has been set up by OSDL. Proper tracking of 2.5 bugs is clearly necessary if they are to be dealt with before the stable release. Whether this database will really fill that need remains to be seen; after a week of operation, it only lists sixty bugs. The 2.5 kernel clearly must have more problems than that; now is the time for people who have encountered problems to put them into bugzilla so they do not get overlooked.

Not all of the kernel developers have shown great enthusiasm for working with the bugzilla system; to some of them, it looks like a lot of bureaucratic work that distracts from the real job of fixing bugs. This should not be a problem as long as people who are interested maintain the bug database and keep it current.

Back at the kernel summit, there seemed to be a consensus that, at this stage, an assistant to Linus would be named to help with stabilization. Linus, by his own admission, does not always do a great job of the release management task. The assistant would help review patches and might also, eventually, become the maintainer of the stable release. That prospect, of course, would help motivate the assistant to look hard at proposed changes and exclude anything that was not really necessary.

This idea was well received at the summit, even by Linus. But this person has not been named, and there has not really even been any discussion of the subject. Following through soon on the appointment of somebody to help stabilize the kernel is probably one of the best things the development community could do to ensure that the freeze (and stable release) are successful.

---

(Log in to post comments)