linux-kernel - Re: stable? quality assurance?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C3B9F56.5090806@s5r6.in-berlin.de>
Date:	Tue, 13 Jul 2010 01:03:50 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Martin Steigerwald <Martin@...htvoll.de>
CC:	Willy Tarreau <w@....eu>, linux-kernel@...r.kernel.org
Subject: Re: stable? quality assurance?

Martin Steigerwald wrote:
> I think I wait for 2.6.34.2 or .3 and then try again. If it then happens 
> again, hopefully in a moment where I have nerve to deal with such bugs, I 
> fire up my second notebook and try to SSH into the machine. If that works I 
> at least could look into dmesg and X.org logs.

netconsole might be required.

...
> Is the Linux kernel development really in balance with feature work and 
> stabilization work? Currently at least from my personal perception it is 
> not. Development goes that fast - can you all cope with that speed? Maybe 
> its just time to *slow it down* a bit?

If those who added the regressions are found out and asked to debug and
fix them, the balance should be corrected and perhaps more precautions
being taken in the future.  Alas, finding the point in history at which
the kernel regressed might take a lot more time than to actually fix it
then.  In that case, maybe give the author of the bug an estimate of the
volunteered hours that were spent on reporting this bug, to put the
repercussions into it into perspective.  OTOH I suspect a lack of
responsibility at the developers is not so much an issue here, more so
that the number of people who take the time for -rc tests (not to
mention linux-next tests) _and_ to file reports is rather low.  Plus, a
good bug report often requires experience or good intuition, besides
patience and rigor.

There were discussions in the past on how more enthusiasts who are
willing and able to test prereleases could be attracted.  But maybe
(just maybe) there are more ways in which the developers themselves
could perform more extensive/ more systematic tests.
-- 
Stefan Richter
-=====-==-=- -=== -==-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/