From: James Lewis Nance <jlnance@intrex.net>
To: linux-kernel@vger.kernel.org
Subject: Kernel QA
Date: Tue, 27 Mar 2001 08:51:42 -0500 [thread overview]
Message-ID: <20010327085142.A982@bessie.dyndns.org> (raw)
In-Reply-To: <Pine.LNX.4.21.0103270229310.8261-100000@imladris.rielhome.conectiva> <3AC04BAC.C21E302@konerding.com>
In-Reply-To: <3AC04BAC.C21E302@konerding.com>; from dek_ml@konerding.com on Tue, Mar 27, 2001 at 12:13:32AM -0800
On Tue, Mar 27, 2001 at 12:13:32AM -0800, David Konerding wrote:
> 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.
You bring up a good point. We call the even branches the stable branches
and we do other things that promote the idea that people should be able to
download a 2.even.X kernel, install it on their machine, and expect it to
work. I think we need to back away from this idea. It seems to me that
the real (perhaps not the intended) function of kernel releases is keeping
kernel developers in sync. Promoting the idea that they are thought to be
suitable for production use just gets us in trouble.
Instead I think we need to encourage people who want to use Linux,
rather than develop it, to use kernels from a distribution. After all,
the distributors put a lot of effort into doing QA and putting together a
compatable system, we should leverage that. We need to ensure that people
know that when they install the latest kernel from Linus, they are the QA.
Please note that I am not trying to say that we should not try and
make the kernels we release as good as possible. It certainly makes
things a lot better for everyone if bugs dont get introduced by new
kernel versions. I do think we need to be more explicit about exactly
what people should and should not be able to expect from a "Linus kernel".
Thanks,
Jim
next prev parent reply other threads:[~2001-03-27 13:50 UTC|newest]
Thread overview: 17+ 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
2001-03-27 12:31 ` Rik van Riel
2001-03-27 13:51 ` James Lewis Nance [this message]
2001-03-27 18:02 ` Kernel QA Shawn Starr
2001-03-27 16:25 ` "mount -o loop" lockup issue Alan Cox
2001-03-27 22:09 ` Kernel QA Alexander Valys
2001-03-27 3:50 ` "mount -o loop" lockup issue Mohammad A. Haque
2001-03-27 3:59 ` William Stearns
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=20010327085142.A982@bessie.dyndns.org \
--to=jlnance@intrex.net \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®