* Rik van Riel <[EMAIL PROTECTED]> wrote:
> On Tue, 8 Jan 2008 20:32:33 +0100
> Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote:
>
> > Fix plenty of coding style errors
>
> Most of these kernel changes would probably get in the way of real
> development, making patches reject that would otherwise apply.
I'm curious, in what way would they interfere?
Firstly, anyone with a forked kernel with outstanding patches that are
not in x86.git only has themselves to blame. We want to actively
discourage forking and sitting on patches too long.
Secondly, when there _is_ some non-trivial interaction with reasonably
recently-developed patches, the solution is simple and straightforward
we simply undo the relevant portions of the cleanup, apply the
functional patch and later on apply the (still relevant) cleanup patches
to around the functional patch.
Since all new x86.git patches are checkpatch.pl clean, the modified
portions need no cleanups anymore - only unmodified portions.
How many times did we have to do this in x86.git? Once or twice - out of
100+ cleanup patches.
In reality, rarely do cleanup patches interfere. They have two positive
effects besides the obvious readability, debuggability and
maintainability advantages:
- they _do_ cause people to come out of their distro-patched
fork-woodwork and submit their "development" patches (which were "in
the works" for ... years).
- the cleanups make future development _easier_, because it's easier to
develop on a clean codebase.
and because the number of future patches is infinitely larger than the
number of still pending but not submitted development patches, we
strongly favor cleanups.
so in the end it all works out fine.
Ingo
--
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/
