Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 2 Jun 2002 14:57:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 2 Jun 2002 14:57:19 -0400 Received: from age.cs.columbia.edu ([128.59.22.100]:13328 "EHLO age.cs.columbia.edu") by vger.kernel.org with ESMTP id ; Sun, 2 Jun 2002 14:57:19 -0400 Date: Sun, 2 Jun 2002 14:57:16 -0400 (EDT) From: Ion Badulescu To: Thunder from the hill cc: Sam Ravnborg , Subject: Re: KBuild 2.5 Impressions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2 Jun 2002, Thunder from the hill wrote: > On Sun, 2 Jun 2002, Sam Ravnborg wrote: > > Again wrong approah. Extend kbuild-2.4 with the features, tweak them > > until they actually meet the requirements and then on to the next step. > > Obviously the dependency step is huge, but the point is that there is > > steps before and after this. > > You keep missing the fact that you have kbuild-2.4 and kbuild-2.5 in the > same tree. I told you I won't introduce bugs in order to fix them! I'm NOT > Microsoft! And you keep missing the fact that having both in the tree doesn't solve anything. Bugs are not a problem in the development series, bugs are found and fixed. However, having both in the tree can mean only one of a few things: 1. kbuild24 will slowly become unmaintained 2. kbuild25 will slowly become unmaintained 3. both will be partially broken for certain newly added targets (e.g. author FOO adds driver BAR and only adjusts only of the kbuilds for his driver, and you end up with kbuild24 building certain modules and kbuild25 building certain other modules, ugh) 4. everybody will have to put in double work to update both kbuilds, test changes, etc. None of the above looks acceptable, IMNHO. You need to break it up FEATURE BY FEATURE, that's the only way it will go in. Then you add one feature to the existing kbuild, test, release, get bug reports, fix bugs, add the next feature, rinse, repeat. Also, don't say 'well you need the core to do this and that', it only shows that you don't understand the core and you're treating it like a black box. Once you do understand it, you'll see there are many ways to break it up feature-wise. Ion [swearing this is his last reply in this thread] -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/