Re: 2.0.31 : please!

Keith Owens (kaos@ocs.com.au)
Wed, 16 Jul 1997 22:38:39 +1000


On Wed, 16 Jul 1997 12:45:16 +0200 (MSZ),
"Daniel G. Link" <scrooge@cyclone.snafu.de> wrote:
>This is not valid for what I said about development kernels. In order to
>test if it compiles, it is only necessary to turn on all options that
>are not mutually exclusive and compile. Kernels 2.1.29 up to 2.1.41 (I
>might be off by 1 or 2) did not even compile with ISDN options activated,
>at least in my case and some other people's. ld complained about
>"undefined references".
>[snip]
>If there is a reason why non-compiling code has to be in the kernel
>sources (I would be hard-pressed to find one), then at least there should
>be a file "LATEST_COMPILING_<whatever>_IS_<version number>" in the kernel
>source directory.

Having complained myself in the past about this set of kernels not
compiling and been soundly chastised - yes there is a reason for
non-compiling sources. That set of kernels was when the entire user
parameter validation was redone and select was converted to poll. AC
correctly rejected my patches that made ISDN compile because it would
not actually run, I had no ISDN to test on. It is better to have
non-compiling code than code that compiles but breaks in strange ways.

With big and fundamental changes, it is unrealistic to expect every
section of kernel code to compile and run. It is better to release a
working *subset* of the kernel so the maintainers can see what major
changes have been done and upgrade their code. The alternative is a
restricted set of developers who get private patches and nobody else
can participate until the patch set is released. If that is what you
want, try the BSD world.

As for "LATEST_COMPILING_<whatever>_IS_<version number>". Anybody who
is not prepared to compile, debug and fix development kernels should
stay on the production kernels.

perl -e 'print "Development kernels are guaranteed to have bugs.\n" x 1000;'