Why kbuild 2.5 needs to go in as one change [LWN.net]

Why kbuild 2.5 needs to go in as one change

Posted Jun 7, 2002 6:37 UTC (Fri) by DeletedUser1711 ((unknown), #1711)
Parent article: The continuing saga of kbuild 2.5.

"Keith has, so far, refused to break his kbuild work up in this way" is not correct. Read my mail, in particular Q16 and Q17. If somebody comes up with a sensible way of applying the patches a bit at a time then I will listen, but nobody who really understands the problem thinks that this is doable.

Sending multiple patches, only one of which does anything is not the answer. Linus said

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")

In the case of kbuild 2.5, there is no useful overlap between the old and new systems, it is a complete replacement. Hence the need for all the code to go in together.

What Kai is doing is NOT kbuild 2.5. Instead he is fiddling with the existing system, taking the fixes for the easy problems from kbuild 2.5 and ignoring the hard problems. At best this will result in a pale imitation of kbuild 2.5, with fewer features. At worst it will be a continutation of all the build problems that have plagued the kernel for years.

(Log in to post comments)