Daniel Phillips wrote:
> Well, actually a lot of the work done by Kai is simply importing
> portions of Keith's work that break out easily, which is purely
> duplication of effort, since such work is already in progress. In
> fact it creates more work, because then we have to go parse Kai's
> patches and find out what he submitted, then see if it gets applied
> so we can mark it 'applied' in the list. This is a real waste of
> time, and did I mention, it's divisive?
Linus sees Kai as being the most promising fellow to
integrate kbuild2.5 right now (see
http://marc.theaimsgroup.com/?l=linux-kernel&m=102307114005894&w=2 )
and Kai is willing to take it on in just the way Linus wants.
It's probably worth giving Kai and Linus the benefit of the doubt for a while,
even if it does mean having to rejigger the kbuild-2.5 patch
each time Linux accepts one of Kai's patches.
I personally am anxious to see kbuild-2.5 make it into the kernel,
but I also feel it can only benefit from a strong review of
the sort that comes about during gradual evolution
of the kernel build process towards the techniques used by kbuild-2.5.
Thanks to everyone, Keith, Daniel, Thunder, and Kai, who are
working (together or not!) on moving the kernel build process
into the modern era.
- Dan
In article <[email protected]>, Dan Kegel <[email protected]> wrote:
>
>Linus sees Kai as being the most promising fellow to
>integrate kbuild2.5 right now [...]
Side note, just to explain _why_ I prefer it done this way, so that
people can understand - even if they don't necessarily have to agree
with - why this is my preferred approach.
There's actually several reasons:
- I always hate "flag day" patches. Do they happen? Sure. Some people
have already given examples of such big flag-day patches, the ALSA
merge being one prime example. That doesn't mean that I like them
any more for that.
In short: if at all possible, I _much_ prefer gradual merges, where
"gradual" really means that features are added one-by-one (and that
does _not_ mean "build up the infrastructure slowly, so that the
final 'flag-day' patch itself is small but has large ramifications")
- Kai has already shown that he can merge with me easily, and actually
took one traditional flag-day-project (ISDN: every single merge was a
flag-day merge), and has turned that into a very easy gradual merge
for me. I used to dread ISDN merges, these days I don't even have to
think about them.
- Kai obviously already knows the build system, as he has been doing a
lot of incremental stuff on it already.
- Kai isn't an enthusiastic kbuild-2.5 supporter. In fact, he tends to
be a bit down on some of it. Which is a plus in my book: it means
that whatever Kai tries to push my way I'll feel just that much more
comfortable with as having had critical review.
So let's see how it works out. Maybe it won't, but this would seem
workable at least in theory.
Linus