Do you still think that Linux distributions should be deciding on when a feature is stable enough to be included into one of their release kernals?

Of course - why would a distributor ship code which it is not confident of being able to support? Perhaps your question is: is there a problem with features going into the kernel which are not sufficiently stable for distributors to enable? My belief is that this is not happening. By the time a feature makes it into the mainline, it has already seen a significant amount of testing -- enough to be usable by the more adventurous distributors. By the time the enterprise distributions get around to shipping a given kernel, the final problems will generally have been worked out of it.

To my knowledge, there have been very few features merged into the mainline which are then disabled by distributors shipping a given release. This is especially true of core features -- device drivers will always be a little more variable in their readiness. What happens instead is that distributors will ship code which has not yet made it into the mainline -- the realtime patch sets are a classic example here. So I do not think that distributors are being asked to pick and choose between questionable features in the mainline kernel.

What are some of the most important works going on now in the kernel?

After a long period of relative quiet, a lot is happening in the filesystems area. The ever-increasing size of storage devices is putting some real stresses on current filesystems, and the lead time for new filesystems can be quite long. Filesystem developers tend to be very conservative folks - the consequences of filesystem bugs tend to be particularly unpleasant. So the filesystems we'll be using five years from now need to be under development now. The good news is that there are some very interesting projects in this area, a number of which will be represented at linux.conf.au.

The realtime patch set is another interesting area. Realtime performance is useful in a number of surprising places. Banks need it, for example, to be able to guarantee response times to trading requests. When getting an order in a few milliseconds late results in the loss of real money, people pay a lot of attention to response times. Much of the realtime work has found its way into the mainline over the last couple of years, but there is still a lot waiting to be merged. But distributors are shipping it now, and I expect we'll see a lot of it heading toward Linus over the coming year.

Finally, improving hardware support is always an important area of work. Over the course of the next year, though, we will see free drivers for most wireless networking chips and most video adapters, which are traditionally the areas with the most problems. This is happening as a result of extensive reverse-engineering effort and a change of mindset at certain vendors. By the end of 2008, I think, most of the hardware hassles will be behind us.

Do you think the current scheduler is doing OK, or is there still room for improvement?

There's always room for improvement. But I have to say that the complete replacement of the process scheduler appears to have gone quite smoothly. There have been very few complaints so far. That may change as the CFS scheduler makes its way out to more users (most non-developers won't be running it yet), but the fundamental structure appears to be quite sound.

Can you see a tighter integration with ZFS happening now that the flame wars have settled down a little?

No. The licensing for ZFS is not compatible with GPLv2, so that code can never make it into the mainline kernel. There are also software patents involved, and Sun does not appear to have any desire to license those patents for the Linux kernel. So there will not be ZFS in Linux in the foreseeable future.