OK that's true, but think: how much work has Keith put into this? How much
did he or his employer get paid? And how many times has he been told to go
off and fix something, as a prelude to getting the thing in? The last time
it was the first-time build speed. He went away and came back with a *huge*
improvement, even more than what people were demanding. You'd think that
would be enough.
Keith has to do *two* full time jobs as long as the patch isn't merged:
developing the patch itself and tracking the whole 2.5 tree as it (rapidly)
> > > If Keith is indeed leaving it, I'm hoping someone will maintain it, or
> > > work with Kai to integrate it into 2.5.x.
> > When I suggested to Keith he push kbuild25 the way Linus likes, he (Keith)
> > considered that was a "stupid comment" and that he'd ignore stupid comments.
It is of course always regrettable when one is so rash as to call a stupid
comment a stupid comment ;-)
> What remains to be answered is, how does one split a system of a myriad of
> build rule files into a reasonable amount of small patches.
> Of course, you could have hundreds of patches each consisting of a single
> Makefile.in, but how would that make the reviewing/integrating easier? In
> the end you'd end up reading the same input, only you'd complement it by
> frequently pressing your favorite show-me-the-next-mail key.
I thought BitKeeper was supposed to be able to deal with precisely this sort
of merge problem. In this case, splitting the thing up just seems
unnatural, and a dubious use of time.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/