[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

Jason Wessel jason.wessel at windriver.com
Wed Jun 20 15:28:28 UTC 2012

On 06/20/2012 03:46 AM, Glauber Costa wrote:
> On 06/19/2012 09:48 PM, Steven Rostedt wrote:
>> On Tue, 2012-06-19 at 12:38 -0500, Jason Wessel wrote:
>>> Are you saying that patchcheck can check a single patch for the scope
>>> of what it changed and potentially output all the KCONFIG options that
>>> affect any macro definition changes or ifdefs in the code and generate
>>> a complete series of X number of kernels to compile to prove you
>>> didn't break anything?
>> Sorry, I didn't say that ;-)
> The thing is, although there is of course value in ktest.pl, specially 
> in very long series where it is easy to miss something in the middle, 
> most of the breakages comes from setups which are outside of your config 
> realm.
> But the real question is, *even* if you came up with such a tool, that 
> takes a lot of time to do all that over multiple configs considering the 
> average boxes most of us have.
> Automated tests on multiple configs are done in linux-next, but by the 
> time they reach linux-next, it might be too late. There would be value 
> in having a powerful box doing this in a rewindable tree.

This is the point that I was trying to drive at.  There is value in
proving bisection as well as doing something more intelligent than
just arbitrary rand configs against a set of patches that comes into

What is not clear to me is if the linux-next infrastructure even has
close to the kind of cycles that are required to prove something
bisects and build with all the permutations of a .config to fully
build test a patch.  Having a metric and notifications for bisection
and "intelligent .config" would hopefully improve quality.

In the utopia we could also get some boot testing going if a simulator
test existed for the files the patch modified.


More information about the Ksummit-2012-discuss mailing list