It would be great if on kernel.org there were a note indicating which
releases of the linux kernel had been favourably received.
If you could organize a bit you could even mark a release as "TESTED",
or even "APPROVED". All it would mean is that after it had been out for
a week or two nobody found any really serious problems.
"Really serious" would be something like it corrupts the filesystem, or
crashes a lot, or fails to build, or introduces a remote root exploit.
Releases like 2.4.14 (fails to build loopback) and 2.4.15 (corrupts)
would not be tagged as "APPROVED".
Also "APPROVED" or "TESTED" doesn't mean there are no issues or problems,
just that they're the usual kind of issues and problems, rather than
really serious issues.
I expect there to be quite a bit of human judgement involved in applying
the label. I'm not looking for a rigorous criteria--just the general
feeling of the community a week or two after the release was posted.
Justin
On Fri, Nov 30, 2001 at 05:04:51PM -0500, Justin Wells wrote:
>
> It would be great if on kernel.org there were a note indicating which
> releases of the linux kernel had been favourably received.
>
> If you could organize a bit you could even mark a release as "TESTED",
> or even "APPROVED". All it would mean is that after it had been out for
> a week or two nobody found any really serious problems.
>
> "Really serious" would be something like it corrupts the filesystem, or
> crashes a lot, or fails to build, or introduces a remote root exploit.
> Releases like 2.4.14 (fails to build loopback) and 2.4.15 (corrupts)
> would not be tagged as "APPROVED".
>
> Also "APPROVED" or "TESTED" doesn't mean there are no issues or problems,
> just that they're the usual kind of issues and problems, rather than
> really serious issues.
>
> I expect there to be quite a bit of human judgement involved in applying
> the label. I'm not looking for a rigorous criteria--just the general
> feeling of the community a week or two after the release was posted.
>
> Justin
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Fri, Nov 30, 2001 at 05:04:51PM -0500, Justin Wells wrote:
>
> It would be great if on kernel.org there were a note indicating which
> releases of the linux kernel had been favourably received.
>
> If you could organize a bit you could even mark a release as "TESTED",
> or even "APPROVED". All it would mean is that after it had been out for
> a week or two nobody found any really serious problems.
>
Are you volunteering to keep up on which kernels had what erratas?
> "Really serious" would be something like it corrupts the filesystem, or
> crashes a lot, or fails to build, or introduces a remote root exploit.
> Releases like 2.4.14 (fails to build loopback) and 2.4.15 (corrupts)
> would not be tagged as "APPROVED".
>
> Also "APPROVED" or "TESTED" doesn't mean there are no issues or problems,
> just that they're the usual kind of issues and problems, rather than
> really serious issues.
>
> I expect there to be quite a bit of human judgement involved in applying
> the label. I'm not looking for a rigorous criteria--just the general
> feeling of the community a week or two after the release was posted.
>
The problem is that this is much like documentation. It (should|needs to)
be done, but usually it'll be started, and then abandoned.
Something like LWN (Linux Weekly News) might be a good place for this.
Since you probably wouldn't want to know daily if you're going to be a few
versions behind.
mf
> Are you volunteering to keep up on which kernels had
> what erratas?
well, at least there's a very simple way to get
valuable information : install a voting system on a
web site (kernel.org...) so that people who go there
to get a new kernel can also tell which kernel
they're using, the approximative uptime they have,
if they encountered problems, if they had to
patch it to gain stability, and eventually what they
do with it (io/net/desktop/all).
A further step could be to qualify recensed patches
on the net in the same manner. There *are* ways to
get very stable kernels even now, for a given
application. Not everyone has the same needs of
course, but it could help even the maintainers by
giving them a more global feedback about which
patches could most likely be included with low risk.
I think that if even one tenth of the LKML
subscribers rank their kernels at least once a week,
we'll quickly see some stable and unusable kernels.
Just my 2 cents,
Willy
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Courrier : http://courrier.yahoo.fr
On Sat, Dec 01, 2001 at 02:05:21AM +0100, willy tarreau wrote:
> I think that if even one tenth of the LKML
> subscribers rank their kernels at least once a week,
> we'll quickly see some stable and unusable kernels.
>
I like this idea a lot.
Who can get such a system up and running? Which web site?
mf
>
> On Sat, Dec 01, 2001 at 02:05:21AM +0100, willy tarreau wrote:
> > I think that if even one tenth of the LKML
> > subscribers rank their kernels at least once a week,
> > we'll quickly see some stable and unusable kernels.
> >
>
> I like this idea a lot.
>
> Who can get such a system up and running? Which web site?
I've proposed in the past a more extensive version of this.
make register
or similar.
Which you run, and it grabs a snapshot of system setup, optionally
with comments, and sends it in to a registry.
You can then do
make comment
and report issues.
These would vary from "it crashes", to "my hard drive died/is dying"
So we get information on systems, and some idea on which are reliable
or not.
Last time some people disagreed with this obviously brilliant idea. :/
On Sat, Dec 01, 2001 at 02:42:02AM +0000, Ian Stirling wrote:
> >
> > On Sat, Dec 01, 2001 at 02:05:21AM +0100, willy tarreau wrote:
> > > I think that if even one tenth of the LKML
> > > subscribers rank their kernels at least once a week,
> > > we'll quickly see some stable and unusable kernels.
> > >
> >
> > I like this idea a lot.
> >
> > Who can get such a system up and running? Which web site?
>
> I've proposed in the past a more extensive version of this.
> make register
> or similar.
I think I remember reading about that on kernel traffic...
> Which you run, and it grabs a snapshot of system setup, optionally
> with comments, and sends it in to a registry.
> You can then do
> make comment
> and report issues.
> These would vary from "it crashes", to "my hard drive died/is dying"
> So we get information on systems, and some idea on which are reliable
> or not.
>
I think people would have trouble with the versions of their apps being
reported. Some people that is...
But, all something like this really needs is just to be blessed by someone
high in the kernel strata...
It doesn't actually *need* to be in the kernel though. A user space package
would work great. Run from a cron job, and report kernel version, and
optionally some other pertinent info.
Perodically, (monthly?) you would get an email asking you to fill out this
form and you'd get your registry with bug/status reports.
Even bigger, some sort of bug tracking system could be tied to this...
mf
> Last time some people disagreed with this obviously brilliant idea. :/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
In article <[email protected]> you wrote:
>
> It would be great if on kernel.org there were a note indicating which
> releases of the linux kernel had been favourably received.
>
> If you could organize a bit you could even mark a release as "TESTED",
> or even "APPROVED". All it would mean is that after it had been out for
> a week or two nobody found any really serious problems.
Approved kernel are usually come in files ending in i386.rpm,
ia64.rpm or .deb.
Come on, no one expects stock kernel to be tested. Distributors
on the other hand spend a lot of effort on testing their releases,
so go for a distribution kernel if you need something tested. Really.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
In article <[email protected]>,
willy tarreau <[email protected]> wrote:
>> Are you volunteering to keep up on which kernels had
>> what erratas?
>
>well, at least there's a very simple way to get
>valuable information : install a voting system on a
>web site (kernel.org...)
Right, linux-2.4.cowboyneil.
Mike.
--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former" -- Albert Einstein.
In clouddancer.list.kernel, you wrote:
>
>In article <[email protected]> you wrote:
>> And the kernels on kernel.org *are* tested, by lots of people, by kernel
>> developers, by lots of ordinary folks even. I bet right after theren's
>> an announce on slashdot you see lots of traffic on the ftp/http sites.
>
>The problem is that there is absoloutly no defined QA-cycle for these
>kernels. Please take a look at what distributors (at least most, I know
>at least one counter-example):
Actually, I find it pretty easy to sort out which to run. Just look
at the email subjects of lkml for a few days after release. Bad stuff
is rather rapidly detected, so "no news is good news". As for
protecting the info on your hard disk, you do make backups of course?
--
Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that."
Christoph Hellwig wrote:
> In article <[email protected]> you wrote:
> > And the kernels on kernel.org *are* tested, by lots of people, by kernel
> > developers, by lots of ordinary folks even. I bet right after theren's
> > an announce on slashdot you see lots of traffic on the ftp/http sites.
>
> The problem is that there is absoloutly no defined QA-cycle for these
> kernels. Please take a look at what distributors (at least most, I know
> at least one counter-example):
I'm not asking for any change in the development process, the
creation of a test suite, or any quantification of quality. I'm
asking for the consensus.
Here's my level of comfort: I don't want to be on the bleeding edge,
but I want to be on the blade, just a little back from where all the
bloodshed is. I want to run something pretty new, but which lots of
other people have been able to run without much pain.
The voting idea sounded good, or just tracking what people are running,
or having someone judge the consensus by gut feel. Any of these would
guide people like me to the better kernels.
I just want to see some indicator like this on kernel.org pointing me at
which kernels are worth my while to test out and try.
Justin