[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <479A75D4.6070607@s5r6.in-berlin.de>
Date: Sat, 26 Jan 2008 00:50:44 +0100
From: Stefan Richter <stefanr@...6.in-berlin.de>
To: "Giacomo A. Catenazzi" <cate@...eee.net>
CC: "Rafael J. Wysocki" <rjw@...k.pl>, Valdis.Kletnieks@...edu,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: Linux 2.6.24
Giacomo A. Catenazzi wrote:
>> On Friday, 25 of January 2008, Valdis.Kletnieks@...edu wrote:
[-mm]
>>> should flush out most of the truly stupid mistakes, but those are
>>> usually found and fixed literally within hours. Anyhow, the proper
>>> time for test compiles is *before* it goes into the git trees at
>>> all - it should have been tested before it gets sent to a
>>> maintainer for inclusion.
>
> few hours, but a lot of changeset will broke bisect (few doc tell
> us how to continue bisecting on compile errors).
[...]
> I only want to raise the problem, to see if it is possible to improve
> testing environment without affecting the development of Linux.
How often is "bisectability" being broken already before merge in
subsystem trees, and how often only in the context of the merge result?
(Probably impossible to answer because nobody has the data.)
Much of the former type of breakage (if we really have such breakage)
could probably be found in mostly automated ways and by volunteer
testers, by regularly testing the subsystem trees.
--
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/
Powered by blists - more mailing lists