Reductio ad absurdum is often enlightening.
> potential problem in place rather than fixing it as I did would be the
> passive-aggressive approach, not the other way around.
But that's not exactly what you're doing - you're replacing one
(very small) problem with another (very real) problem, the breakage
of people's patches. Fixing up patches because of spelling
errors is a total waste of developer's time.
>> I'd rather solve this problem by making standalone spelling fixes and
>> other cosmetic changes taboo. Cosmetic changes combined with actual
>> useful code changes are fine with me. If you're risking breaking the
>> build, there should be some benefit that justifies the risk.
>
> Breaking the build is a low probability (many hundreds of fixes and one
> build break AFAIK) and low consequence failure (a build fix of that
> nature is obvious and quickly and easily done).
Breaking the build is indeed a low probability (assuming you compile
test your tree). Breaking other people's patches is a high probablility.
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/