On Tue, 19 Dec 2006, Robert P. J. Day wrote: > that sounds reasonable but, as i've mentioned before, many of the > sizable cleanups i've submitted are produced by a simple script, which > is written to process *one* kind of cleanup. if i tried to fix > everything else in the same area at the same time, *that* would > involve far more manual labour, not to mention that the patch would be > less well-defined, and the probability of a fatal typo would actually > increase. >
If these cleanups are being generated by a simple script, I would suggest making sure that script works before submitting patches which break the kernel. On the other hand, if that script is only being used to point you in the direction of a possible cleanup, then it takes very little effort to move an asterisk as one person already suggested, get rid of whitespace, or make a kzalloc conversion. > it's also possible that the stuff that isn't getting fixed in *this* > cleanup will be done in a future submission. like i said, it's a > tradeoff. i'm certainly open to suggestions but there's not much > chance that, when i attack one issue, i'm then going to manually > inspect every line that was changed to see what *else* could be done > at the same time. > When you submit patches to the kernel, I would recommend inspecting each line before submitting it. > life's just too short for that. > I'm quite positive life's too short for the people who may apply your patch to their tree to deal with trivial typos that cause their compile to break or, worse, a problem that may not be noticed at runtime but silently manifests itself later. Having four incremental patches for this: remove casts, move asterisks, eliminate whitespace, and kzalloc conversions is not the solution. Roll it into one patch, call it a cleanup, inspect it, then _test_ it. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/