Messages in this thread | | | From | Keith Rohrer <> | Subject | Re: 2.1.44 | Date | Wed, 9 Jul 1997 04:19:38 -0500 (CDT) |
| |
And lo, Pavel Machek saith unto me: > > The responsible thing to do would surely to be to rename it 2.1.44pre4 before > > it does further needless damage. I've no problem with 2.1.x having odd suprises > > like sometimes eating bits of disks - it is test code, but now we know its > > extremely dangerous moving it from the normal place would be smart. > > Bad idea... Having two patches with same number is bad. What about > launching 2.1.45 patching the most fatal things _fast_? Most people > download latest patch... If you're scared about that, name the next "working" devel version 2.1.46 then. Problem easily solved. But the "problem" of people expecting that even development full (non-"pre") releases aren't expected to blow up their filesystems won't go away...
I do support (and use) the strategy of killing bugs by ripping out whole (buggy) sections of code and replacing them with better/simpler/cleaner/not-inlined- by-hand-all-over versions. However, perhaps more attention should be paid to documentation/commenting, so that we get fewer patches with "I think I satisfy everybody's expectations but I don't know what they are" disclaimers (I've seen that so often on patches that are supposed to *fix* 2.0.30, *correctly*!), and so that we can find the 2.1.recent crashing problems once and for all by giving the code to a bunch of grade schoolers. If you start commenting now, someone will probably be able to get the support of a few schools by the time fall semester starts...
Keith (only kidding about the use of underage labor)
P.S. I looked through fs/inode.c, and was amused to discover a comment which begins: `The "new" scheduling primitives (new as of 0.97 or so)'... brings back memories of sticking distributions with 0.94(?) onto floppies...
| |