linux-kernel - Re: regression tracking (Re: Linux 2.6.21)

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: <4673D63D.5020804@s5r6.in-berlin.de>
Date:	Sat, 16 Jun 2007 14:23:25 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Oleg Verych <olecom@...wer.upol.cz>
CC:	Adrian Bunk <bunk@...sta.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Diego Calleja <diegocg@...il.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: regression tracking (Re: Linux 2.6.21)

Oleg Verych wrote:
> On Sat, Jun 16, 2007 at 01:42:02AM +0200, Adrian Bunk wrote:
[...]
>> This means going through every single point in the regression list 
>> asking "Have we tried everything possible to solve this regression?". 
[...]
>> And a low hanging fruit to improve the release would be if you could 
>> release one last -rc, wait for 48 hours, and then release either this 
>> -rc unchanged as -final or another -rc (and wait another 48 hours).
>> There were at least two different regressions people ran into in 2.6.21 
>> who successfully tested -rc7.
> 
> What about Linus' tree is a development tree, Andrew's one is a "crazy
> development one" (quoting Linus)?
[...]

Linus also said that Andrew's tree is abused too often for broken stuff.

My goal for the little driver subsystem I'm maintaining is
  - everything that Andrew pulls from me builds and runs and doesn't
    introduce regressions to my and the submitters' knowledge.  I am
    slowly expanding my test procedures to catch things that fail that
    goal.
  - Everything that Linus pulls from me fulfills the above criteria
    and, in addition, had reasonable time and publication for test and
    review, depending on the kind of patch.

I had a few regressions in Linus' releases.  None of them were known
before release.  All of them were debugged and fixed rather soon after
report, AFAIR.

So what _I_ need is neither better regression tracking nor more manpower
for debugging of regression reports.  What I need is more own spare time
and equipment for tests, more own knowledge and experience, and more
people who run-time test -rc kernels or at least my subsystem updates on
top of older kernels.

    (Note, I'm talking only about regressions here, not old bugs.
    There my requirements are different; the by far most important
    one is more manpower for debugging and fixing.)

Well, if _other_ subsystems would get regressions in Linus' tree fixed
quicker, there might perhaps be more people who would consider to run
-rc kernels and would catch and report "my" regressions.

[Oleg, sorry that I too digressed from the subject of your thread, but
your remark about "[crazy] development tree"s caught my eye.  IMO people
should care for quality already in Andrew's tree --- more so than at the
moment.]

[Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
few FireWire driver users run -rc kernels".]
-- 
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/