[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
rostedt at goodmis.org
Tue Jun 19 17:23:55 UTC 2012
On Tue, 2012-06-19 at 12:08 -0500, Jason Wessel wrote:
> Comments in code and such that don't get caught and get fixed later
> are one thing but... as long as we are on the grump topic, I sure get
> annoyed with the number of completely impossible to bisect problems in
> the kernel like in an rc-0 window. I would guess if you asked for a
> show of hands of how many people in the last year had to bisect
> something and had a compile fail you would see more than one hand up.
> This becomes particular acute at times with certain non-x86 trees.
> While there are plenty of arguments for not rebasing things in
> development etc..., I always do a final re-base and test before
> putting something into linux-next to make sure it bisects properly. I
> also understand the risks you might break something to make it bisect
> correctly if you have to piddle with code, but this can be avoided
> completely by diffing the original result with the end result. On at
> least one occasion this led me to even re-factor some code.
> I don't know how many cycles are available in linux-next builds, but I
> wonder if about the collaboration aspect with the guy who said he
> could do 25,000 kernel compiles a day. Of interest to me is some
> reporting and encouragement to fixing bisection quality in the
> kernel as a whole.
This was the very reason I created ktest.pl. The first test that was
created for it was the 'patchcheck' test. It works with a git repo (but
may fail with merges), you give it a starting commit and an ending
commit and it will build, boot, and test each commit to ensure that it
will bisect nicely.
The patchcheck, is also the only test that will check the files that the
commit touches, and fail if a file produces a warning during build. I
need to add a flag that disables this, but it is very useful.
More information about the Ksummit-2012-discuss