From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4819 invoked by alias); 17 Sep 2002 18:44:57 -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 4808 invoked from network); 17 Sep 2002 18:44:56 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 17 Sep 2002 18:44:56 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8636A3DAA; Tue, 17 Sep 2002 14:44:56 -0400 (EDT) Message-ID: <3D877828.2050607@ges.redhat.com> Date: Tue, 17 Sep 2002 11:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00348.txt.bz2 > Basically, at any point when you don't have a lot of temporary gunk. I > confess, I'm of two minds about working on a branch for this sort of thing: > I consider it very impractical for things which don't break up into > pieces easily afterwards. GCC has been using an interesting approach, > which I think we could adapt and extend here. GCC's approach relies on GCC's development cycle: break, fix, release. You can only pull stuff in from those branches during the ``break'' phase. And during that phase, things, from what I've seen, really are broken (I got stuck trying to commit a patch because I couldn't build/test GCC for several weeks). I also, to be honest, think that GCC has bigger problems than GDB. With GDB, the basic architecture is fine (if you look at the relationships and ignore all the globals and messed up interfaces :-). GCC, on the other hand, needs some of its fundamental data structures and algorithms completly replaced. > How about a branch which require approval just like the mainline for > large patches, although giving David a little more freedom to play > around. Then, we'd allow large merges from the branch back to the > trunk when they were ready and tested - larger patches than we'd > normally accept all at once, because they'd already been approved. > > Andrew - thoughts? Does it have any interesting possibilities? Let me put it this way, I'm scared shitless of another HP jumbo patch. For GDB, I think change comes in two forms: - external / structural / interface - internal Internal interfaces are the ones that can easily be broken down. Since everything is hidden behind an interface nothing needs to know what happend (just as long as it still works :-). External / structural / interface changes are harder. For these, I think (based on regcache and reggroup) there can be several changes: - proof of concept using a branch I think each branch should be for a single experiment -> no approval required but all patches should be posted so everyone can see what is going down (and if they like point out problems). The purpose being to explore the idea and figure out exactly what the interfaces should look like. (See regcache branch where I changed the interface several times and now that its on the mainline, the interface is still evolving.) While playing, you'll always identify stuff that can be immediatly pushed into the trunk. The MIPS generic dummy frames pulled out a number of things that needed fixing. - interface changes Using the knowledge gained, implement a new interface, possibly implemented using existing structures. This is often just big and mechanical. Here, for instance, I think all the existing queries are based around ``struct block''. Abstract them and then, behind the scenes re-implement the underlying structure so that it does what it is really ment to do -- return the correct symbol given a block. - change internals Which would fill in the missing bits. This and the interface changes often alternate (and occasionally there is a very large lumpy patch :-) . Branches, however, do also involve great risk. Since there isn't that pressure to get things into the trunk, it is too easy to become defocused and change everything else and ignore the objective. enjoy, Andrew