Re: [PATCH 3/5] x86: coding style fixes in arch/x86/ia32/ia32_aout.c

[Ingo Molnar <mingo@elte.hu>]

* Sam Ravnborg <sam@ravnborg.org> wrote:

> > > 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?
> 
> Developer A work one some complicated stuff in foo.c which is not yet 
> -mm fooder.
> 
> Developer B submits and have applied a massive cleanup to some of the 
> files touced by Developer A's patch.
> 
> Developer A now needs to fix up his stuff.

Solution: Developer A does a trivial patch -R for the changes that 
generate rejects. Cleanups are NOPs and they are almost infinitely 
splittable. You can apply and unapply them chunk by chunk, almost 
always.

and we actually have first-hand experience with the effects of 
largescale cleanups:

> > How many times did we have to do this in x86.git? Once or twice - 
> > out of 100+ cleanup patches.

i've never seen cleanups truly interfere with development work, in fact 
i mostly saw the positive effects of them. They are easily undone and 
easily redone. But they do keep developers honest (no lame "oh, i'll 
clean this up after i do feature X, Y and Z") and they do keep newbies 
involved. The Linux kernel does have a fundamental "we are too hostile 
towards newbies" problem. It's also fundamentally Linuxish: nobody 
really "owns" the code in an exclusive fashion. If you dont keep it 
clean, someone else will clean it up for you.

and even if there are patch conflicts, it can all be done intelligently 
and trivially. Mail us: "please do not clean up pgtable.h because i'm 
working on unifying it and will do the cleanup after that" and we dont 
clean it up.

But broad statements of "cleanups hinder development work" are just 
plain _WRONG_. Cleanups are good by default - full stop. There are 
exceptions, and we all recognize them when we see them.

> > 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.
> 
> Curious - what is the purpose of the x86.git tree these days?

what do want to imply by 'these days'?

	Ingo