lkml.org 
[lkml]   [2008]   [Jan]   [25]   [last100]   RSS-feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Complete thread (EXPERIMENTAL)
/
From"Rafael J. Wysocki" <>
SubjectRe: Linux 2.6.24
DateFri, 25 Jan 2008 12:58:08 +0100
Digg This
On Friday, 25 of January 2008, Valdis.Kletnieks@vt.edu wrote:
On Fri, 25 Jan 2008 10:10:11 +0100, "Giacomo A. Catenazzi" said:
As a tester I would like:
- slow merges, so that developer could rebase and test (compile test) the interaction of the new code.

An amazing amount of stuff gets caught when it's tested in Andrew Morton's -mm tree. You think -rc1's are bad now, consider that much of what will be 25-rc1 already got tried as 24-rc6-mm1 and 24-rc8-mm1. Without those, the -rc1 releases would be truly horrific.. ;)

- you will introduce a new step on git management:
Every changeset is compile-tested before going out to the world. I think this can be done automatically, and I think that one or two configurations are enough to find most of the problems.

It's true that a compile on x86 and a compile on PowerPC

Please add IA-64 and ARM at the very least.

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.

That's correct, but I'm not sure how to enforce it.
Plus, there's a *lot* of issues that "one or two configurations" won't find - we continually find build issues that literally depend on 3 or 4 different CONFIG_* settings, and only misbehave for one specific combination. And all the things that compile clean but explode at runtime.

Absolutely.

I whish there would be more time for testing things during merge windows.
Greetings,
Rafael



\
ISP Services
Valid XHTML 1.0!\ /
Valid CSS! Last update: 2008-01-25 12:03    [W:0.613 / U:0.270 seconds]
©2003-2005 Jasper Spaans