lkml.org 
[lkml]   [1997]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 2.0.31 : please!
>>> A lot of people don't seem to realise just how tricky it is
>>> building a stable across all platforms/configurations system.

>Daniel> I do realize that. I'm saying there should be at least *SOME*
>Daniel> sanity checks before releasing even a "development" kernel.

>[snip]

>Daniel> I don't think it is a good service to the advancement of Linux
>Daniel> if released kernels do not compile.

>Daniel> Like I said, I would volunteer to test-compile 2.1.X kernels.

>Daniel> If kernels are not tested in any way, they should be in a Daniel>
>different directory and be called pre-<Version>.

>Bollocks!

>2.1.x kernels are developer versions, if they work for you fine, if they
>don't try to sort it out and fix it.

>a) I do not want to wait until some PC owner has verified that all PC
>drivers works on his particular machine. This would make the turn times
>for kernel releases several days for no sane reason.

That is a fair comment. However I believe that we could do with some
serious effort to ensure that things don't get broken in the course of
adding new features. I don't think that a 2.1.x release should be held up
because of this, however if a serious testing effort was applied to the
pre-patches it would provide a list of things that need work. Then
hopefully most of these issues would be fixed before the full releae of the
2.1.x version.

>b) You cannot verify everything, and I bet just because ISDN compiles for
>you, doesn't mean that the SCSI driver for my Amiga compiles for me.

I believe that I have proved that it is impossible to test all
combinations of kernel options. But I believe that if we test a reasonable
number of kernels then we can discover (and therefore fix) bugs that might
otherwise hang around for ages. One reason for doing this in the
development kernels is that it's easier to keep track of what you're doing
if you do it all at once. Some people such as Alan Cox and Dave Miller
work on many different parts of the kernel. If they were politely informed
that a new feature they had added had broken something else shortly after
the release of the code then I'm sure that they would be able to either fix
the problem or give some background information that allows a less skilled
programmer to fix it with a minimum amount of effort. However if the bug
goes undiscovered for 6 months because no-one tries compiling a certain
combination of modules (or whatever the trigger is) then they are likely to
require much more work to fix it.

>We can put out pre releases for 2.0.x kernels and I agree that is
>important, but for 2.1.x kernels its only necessary where we want to avoid
>things like filesystem corruption etc.

This section of the discussion is about making sure that all parts of
the kernel compile without errors. A module that doesn't compile won't
cause file system corruption. In fact it might prevent it by making you
stick to an older and maybe more reliable version of the kernel. :-#

>Many of the 2.1.x releases are HUGE and waiting for everything to be fixed
>can take weeks, especially if the people with the knowledge of a
>particular part of the code are either unreachable or busy with other
>things.

True. However just knowing that a bug is there after the code has been
released is a huge benefit. In one commercial project that I worked on
they had a set of scripts which compiled the entire system (1M lines of
code) every night. Then when a module gave an error or warning the compile
output was delivered to the person who last checked the relevant file into
SCCS. I found this very useful because then I'd find out about any bugs in
my code within 24 hours of writing it so I knew exactly how it worked and I
could solve the problem within minutes.


Russell Coker

\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2011 Jasper Spaans