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 for Android: free password hash cracker in your pocket

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

Message-ID: <4C3A203F.4080203@s5r6.in-berlin.de>
Date:	Sun, 11 Jul 2010 21:49:19 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Martin Steigerwald <Martin@...htvoll.de>
CC:	linux-kernel@...r.kernel.org, Lee Mathers <wwbbs2008@...il.com>
Subject: Re: stable? quality assurance?

Martin Steigerwald wrote:
> One reason for a demand for me is best expressed by this question: Does 
> the kernel developer community want to encourage that a group of advanced 
> Linux users - but mostly non-developers - compile their own vanilla or 
> valnilla near kernels, provide wider testing and report a bug now and 
> then?

Yes, testing is desired --- in order to shake out bugs that are not
manifest on the developer's systems.  Remember that the kernel is a
special program in which there are many classes of bugs that can only be
reproduced on special hardware and/or with special workloads.

Alas, there are not only new bugs in new features but also new bugs in
existing features, a.k.a. regressions.  But like new bugs, many
regressions can alas not be found by the developers themselves on their
test systems.

You mentioned two particular regressions in your initial posting.  Do
you have suggestions how they could have been prevented in the first
place?  Or how they could have been handled better than they were?

Do you see subsystems of the kernel in which regressions are not taken
as seriously as in other ones?

> Well Linus has at least been a bit more reluctant to take big changes 
> after rc1 this cycle, so maybe 2.6.35 will be better again.

2.6.35 will only be better if this (gradual) change of procedure means
that -rc kernels are going to be tested more and new bugs are going to
be found and fixed quicker in the -rc phase than before.  And 2.6.36+
will only be better if the stricter post -rc1 merges do not motivate
developers to put even more hastily assembled under-tested crap into
their pre -rc1 pull requests than they already do.

[PS: 2.6.34 works very well for me, as most 2.6.x releases do.]
[PS2:  When on lkml, please use reply-to-all, not reply-to-list-only.]
-- 
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/