From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8339 invoked by alias); 20 Sep 2002 16:13:32 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 8332 invoked from network); 20 Sep 2002 16:13:30 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 20 Sep 2002 16:13:30 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g8KFwuO12810; Fri, 20 Sep 2002 10:58:56 -0500 To: Andrew Cagney Cc: Daniel Jacobowitz , David Carlton , gdb-patches@sources.redhat.com Subject: Re: [RFA] convert blocks to dictionaries, phase 1, main part References: <20020917143553.GA28408@nevyn.them.org> <20020917174928.GA23058@nevyn.them.org> <3D877828.2050607@ges.redhat.com> <20020917193007.GA27789@nevyn.them.org> <3D87874F.8010603@ges.redhat.com> From: Jim Blandy Date: Fri, 20 Sep 2002 09:13:00 -0000 In-Reply-To: <3D87874F.8010603@ges.redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-09/txt/msg00527.txt.bz2 Andrew Cagney writes: > > That's not the point. That's why I suggested a branch which does > > require approval, precisely so that we wouldn't get into that problem. > > But you don't seem to like that idea, so it's dead. > > Me not liking an idea doesn't kill it. It is the symtab maintainers, > and not me that would do the review and hence, they and not me would > need to be ok with it. I don't know how Elena feels, but I generally defer to Andrew's judgement in these sorts of things. I'd suggest the following process: - Get things working on a branch. That is, produce a branch on which namespaces actually work --- the block -> dictionary conversion isn't enough. This branch will never be merged directly; it's dead code. - You'll almost certainly find some small messes which can be cleaned up indepenently of any other work. These can be submitted for inclusion in the main sources as you go. - You'll also probably learn some things that you'll wish you had known when you started. But the design backtracking won't happen in the public sources --- it'll happen on your dead branch. Backtracking is hard enough in pristine code. If you're simultaneously trying to break the change into incremental steps, I imagine the backtracking will be even more difficult. - Once you've got it working, the way it really should, then you can decide how to submit it. At that point, you'll have better ideas about how to approach this. If some of the patches are large, so be it. The downside about this process is that it looks like you do the work twice: on the branch, and then again in the public sources. But I think that is partly an illusion. What actually takes time in these situations isn't the typing: it's the research (figuring out how the damned thing works), and the backtracking (oh, this can't support `using namespace' directives, we've got to do it another way). The "second time", when you're working from tested, running code, goes much faster.