Re: 2.1.44

Keith Rohrer (
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