Messages in this thread | | | Date | Tue, 15 Apr 2014 01:38:40 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH 00/38] tick cleanups and bugfixes |
| |
On Mon, 14 Apr 2014, Viresh Kumar wrote: > Hi Thomas, > > These are separate cleanups from the timers/hrtimers ones I did. I was waiting > for the merge window to close in order to send these and by the time it > happened, I got a long pending list. > > These are mostly cleanups, reorders for better readability or efficiency, and > few bugfixes.
And that's wrong to begin with.
Bugfixes first and then all other stuff. We dont want dependencies of bugfixes on cleanups, reordering of code ...
I'm not applying a wholesale checkpatch.pl patch which creates noise for no value.
I don't mind if you cleanup stuff while doing other changes, but definitely not as a stand alone starter of a large patch queue with bugfixes which depend on that.
Now looking at the thing some more, it contains gems like this:
- printk(KERN_ERR "tick-broadcast: ignoring broadcast for " - "offline CPU #%d\n", *oncpu); + printk(KERN_ERR "tick-broadcast: ignoring broadcast for offline CPU #%d\n", + *oncpu);
If you fix that checkpatch.pl line wrap issue, why do you not change printk(KERN_ERR) to pr_err() as well?
checkpatch.pl is happy, right?
I'm tired of this, really.
Please send me the next series in the following way:
- send a bug fix series, which does nothing else than fixing bugs.
when that is applied, then
- send a small batch of improvements for a particular issue and not a mixed bag of random patches.
Thanks,
tglx
| |