* Sam Ravnborg <[EMAIL PROTECTED]> 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
--
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/
