From: David Konerding <dek_ml@konerding.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-kernel@vger.kernel.org
Subject: Re: "mount -o loop" lockup issue
Date: Tue, 27 Mar 2001 00:13:32 -0800 [thread overview]
Message-ID: <3AC04BAC.C21E302@konerding.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0103270229310.8261-100000@imladris.rielhome.conectiva>
Rik van Riel wrote:
> On Mon, 26 Mar 2001, David Konerding wrote:
>
> > It's a bug in Linux 2.4.2, fixed in later versions.
> > Regression/quality control testing would have caught this, but the
> > developers usually just break things and wait for people to complain
> > as their "Regression" testers.
>
> As said before, we're interested in people willing to do regression
> tests on the kernel. Unfortunately, not all that many testers have
> stepped forward and not all that many artificial tests are being run.
No, the point is that the linux developers should regression test their
code BEFORE
releasing it to the public as a version like "2.4.2". When I see a
version like "2.4.2", I have an expectation that all the stupid little
problems (like mounting loopback filesystem) have already been found.
It's even worse that these are obvious, simple bugs (like the "NFS doesn't
work over reiserfs
because somebody changed the VFS layer and didn't fix any filesystems but
ext2" that I reported a while ago) which would have been caught by a
little testing.
Now, don't even get me started on how the developers are fixing every
legitimate bug found by CHECKER when they refused to put a debugger into
the kernel "because a good programmer finds their bug by studying the
code"-- well, obviously, you didn't find a lot of bugs by studying the
code.
I've been using Linux for something like 6-7 years now, quite faithfully.
I've been very impressed with
many of its facilities, and the improvements to the kernel (which I've
compiled since 0.99) have been astounding. But the attitude that "many
eyes make all bugs shallow" and "let the users test the code for us" just
don't hold up. For the former, clearly, many eyes didn't find a lot of
basically obvious bugs, for the latter, it's just impolite.
next prev parent reply other threads:[~2001-03-27 8:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-27 1:56 "mount -o loop" lockup issue David E. Weekly
2001-03-27 3:31 ` Jason Madden
2001-03-27 3:50 ` David Konerding
2001-03-27 4:19 ` Alan Cox
2001-03-27 8:32 ` David Konerding
2001-03-27 13:24 ` Mohammad A. Haque
2001-03-27 18:51 ` J Sloan
2001-03-27 19:33 ` Alexander Viro
2001-03-27 5:30 ` Rik van Riel
2001-03-27 8:13 ` David Konerding [this message]
2001-03-27 12:31 ` Rik van Riel
2001-03-27 13:51 ` Kernel QA James Lewis Nance
2001-03-27 18:02 ` Shawn Starr
2001-03-27 22:09 ` Alexander Valys
2001-03-27 16:25 ` "mount -o loop" lockup issue Alan Cox
2001-03-27 3:50 ` Mohammad A. Haque
2001-03-27 3:59 ` William Stearns
-- strict thread matches above, loose matches on Subject: below --
2001-03-27 19:25 Joerg Pommnitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3AC04BAC.C21E302@konerding.com \
--to=dek_ml@konerding.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox