which makes it appear that we are being too ambitious in the changes made
between major releases (by major I mean "stable" releases - ie 1.0, 1.2,
2.0).
} On the other hand, I agree that the "cure" of
} continuing development on 2.0 does seem to be worse than the original
} disease. Any change that breaks binary compatibility is a definite no-no
} in a stable kernel - I can't think of any reason sufficiently compelling
} to make such a modification. Performance tweaks can always be released as
} seperate patches against 2.0 (like the ISS stuff was originally) but they
} ought not to go into the mainstream kernels if they will have any impact
} on compatibility.
However the idea of having a fixed kernel and a load of
feature/performance patches is also horrid. If you want a high
performance news server you end up stacking something like a Buslogic SCSI
upgrade, ISS network patches, no atime patches, tulip ethernet driver and
maybe say a Cyrix CPU fix as well. Thats a whole load of individual
patches which may not work at all well together!
Maybe we need 3 streams:-
1. Stable bug fix only. The current 2.0.x as should be
2. Modest development. Additional features, ideally no external API
changes. [ie ISS, masq fixes]. Every so often (say 3 - 6 months),
this tree is used to make a new stable release from a version
that has been running solidly for a while. Changes here are also
fed up to the...
2. The developers playground. Supports everything (ipv12, telepathic
i/o, Intel ZX81 processor), but rarely works :-( At reasonable
points this is frozen, downshifted to the ongoing development
status, prior to release as the new stable version.
However making this work in practice appears unlikely.
Nigel.
-- [ Nigel.Metheringham@theplanet.net - Systems Software Engineer ] [ Tel : +44 113 251 6012 Fax : +44 113 224 0003 ] [ Friends don't let friends use sendmail! ]