Messages in this thread | | | From | "Russell Coker - mailing lists account" <> | Date | Wed, 16 Jul 97 23:06:47 +1100 | Subject | Re: 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
| |