[Ksummit-2013-discuss] [ATTEND] static checking; COMPILE_TEST

Steven Rostedt rostedt at goodmis.org
Fri Jul 19 23:57:28 UTC 2013


On Fri, 2013-07-19 at 15:00 -0700, James Bottomley wrote:

> This does bring up an interesting process issue of how we handle these
> reports on existing git trees.  My own process is to either kick out or
> amend in place patches that excite the checkers, but this does cause an
> effective rebase of my git trees.  I think this is justifed because in
> the early stages, a clean development record (and a bisectable tree if
> it's a compile failure) are more important than git history, but I know
> others think differently.

I run a bunch of tests against different configs before pushing it to
for-next. If a new compile breakage happens, I add that config to my
future tests. It's been a while since I've had a compile breakage since
I started testing this way. I do get little errors here and there
reported by the automatic tests now, but nothing that required a rebase,
even for bisectability.

> 
> Perhaps we should have a rebasing for-checker branch in the same way we
> have a for-next one?  This would be for stuff we've not yet actually put
> into any other branches of our git trees, so it can be cherry picked
> from and dumped?

Make a "rebase" branch. That way people will know that it can rebase and
wont build against it. The checkers will still process that branch.

-- Steve




More information about the Ksummit-2013-discuss mailing list