>HOWEVER, I will say this: the next release is likely to be worth
>it. We'll have the bus_dma stuff fixed (which will fix bounce buffer
>issues now and forever on all architectures), probably real PCMCIA
>support, probably real ATAPI support, far improved VM, etc., etc.

>Would you call these changes big enough to warrant a 2.0 instead of
>a 1.3?

I might :).

But that's just an invitation to kick out a `1.3' release earlier:
declare a code freezeimmediately before the bus-dma changes go in,
start a `release cycle', and then kick out a 1.2E-ish `1.3' in about
two months.

I *like* the idea of a -stable release.  Maybe we could make it work
by always having a `release cycle' in progress; -stable is then just
the frozen, release-bound code.  Users can choose whether they want
-stable or -current.

If we stuch to release timetables, that could give a release about
four times a year.  But that probably isnt' realistic. Allowing time
for alpha and beta testing -- and developer bandwidth! -- we might be
able to do it twice a year, rather than four. But that gives a lag of
at most six months between `stable' releases, support for new drivers,
etc.

I think reducing the time lag between new functionality in -current
and ``stable'' releases (from the current major-release rate, down to
six months) would be useful for everyone, both users *and* developers.
The question is how to do it with the resources we have available?