> Basically, I think we should
>
> a) start with a stable kernel
> b) decide which features go into the next stable kernel
> c) work these into a development tree
> d) get it stable
> e) make a new stable release
This scheme is quite nice, but we have to be really
careful to stay in a 'bazaar'-type development model.
A too strict scheme would give us a cathedral, which
will start falling apart at all sides...
(see the 'BSD team')
> in the meantime, those unfortunate souls who don't get their features in
> at point b) would have to work on it separately, and if they have a
> nice, almost-there patch at point e), they will be ahead in the line
> when point b) recurs.
Provided we keep development cycles short enough (6 months),
developers will have the patience to wait and provide patches
until a new version starts.
We probably should do a code freeze after 3 to 4 months of
development kernel work, regardless of what new feature is
just around the corner.
This means that:
- we have a limited 'window' in which we can introduce new
features
- because of this, developers can and will take their time
when designing a new feature
- the features will be introduced as patches first, with
a lot of show effect to get attention
- the features will (mostly) enter the kernel in a somewhat
mature state
- new code will be introduced in less, but larger chunks
- there will be less conflicting patches, so less development
kernels will fail to compile
- developers will team up more and more, because a lot of
work will need to be done 'outside' of the mainstream kernel
Rik.
+-------------------------------------------+--------------------------+
| Linux: - LinuxHQ MM-patches page | Scouting webmaster |
| - kswapd ask-him & complain-to guy | Vries cubscout leader |
| http://www.phys.uu.nl/~riel/ | <H.H.vanRiel@phys.uu.nl> |
+-------------------------------------------+--------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu