When to release 2.6.28?
The 2.6.28-rc8 kernel prepatch is out. That means that the final 2.6.28 release must be getting close. I once heard Linus say that he would never hold a kernel release past -rc9 regardless of the situation; there comes a point where you have to send it out into the world and get on with development. In this case, though, 2.6.28 appears to be stabilizing nicely. The list of regressions is getting fairly short. So this kernel will truly be ready to go soon.
That leads to an interesting question, though: when should this release actually happen? One would not normally be concerned about releasing a new kernel just before the holidays; if anything, that would just give a few extra days for any remaining issues to be found and fixed before they cause trouble for more people. But one should remember that the merge window - the two week period in which major changes for the next kernel cycle are accepted into the mainline - traditionally opens just after the final release. So a pre-holiday 2.6.28 release would imply that the merge window would happen over the holidays. Their geeky reputation notwithstanding, the majority of kernel developers are not going to be that thrilled about having to get their 2.6.29 changes merged in the middle of holiday celebrations.
So Linus is considering delaying the 2.6.28 release until after the holidays - either that, or releasing before but holding the merge window closed for a couple of weeks. That idea appeals to a number of developers, but it risks running into another problem: linux.conf.au begins in mid-January. Quite a few kernel developers will be there, and dealing with merging in the middle of a conference is almost as bad as doing it over the holidays. Last year’s LCA happened during the merge window, and there is a strong preference to avoid repeating that experience.
So we may see a pre-holiday release after all - either that, or it may happen right around the new year. We’ll probably not know for sure until Linus pulls the trigger.
Trying to fit in releases and merge windows around real world events like this is a bit of a pain. But it is certainly a lot nicer than having release dates determined by (1) product schedules, or (2) the simple fact that the software is not yet ready. In fact, having a development process that works well enough to allow for this kind of worry is a luxury, all things considered.