From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Daniel Jacobowitz Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [rfa] symbol hashing, part 2/n - ALL_BLOCK_SYMBOLS Date: Thu, 11 Oct 2001 18:18:00 -0000 Message-id: <3BC644E6.9060102@cygnus.com> References: <20011009123457.A28534@nevyn.them.org> <15302.12121.778853.77938@krustylu.cygnus.com> <20011011195450.A22256@nevyn.them.org> <3BC63C81.5000102@cygnus.com> <20011011204828.A24288@nevyn.them.org> X-SW-Source: 2001-10/msg00162.html > On Thu, Oct 11, 2001 at 08:42:41PM -0400, Andrew Cagney wrote: > >> As you said, it is a double-edged sword. The other edge has a very >> unusual feature. Identify simple mechanical self contained changes and >> often go in as obvious. The review cycle goes down and can often be >> reduced to zero. > > > The problem is that I'm working entirely on intrusive changes in code > owned by other people. There are no parts I'm willing to commit as > obvious, and every time I break them up further I introduce > intermediate stages that I have to adequately test. I do this when it is code I maintain. I'm about to attack target.[hc] and that is going to get real messy. The only way I can do it is in two passes. First prototype the changes I want - proving they are possible, and then go back and break the change down into digestable chunks so that I can explain them. As for obvious. The most common is indentation. After that comes small logic changes - the ``I think this is obvious but I want someone to double check'' strategy is often useful. The last would be mechanical changes across files - there pre-approval is a good strategy. The word ``obvious'' is like a red flag to a bull, it gets everyones attention and is carefully examined :-) enjoy, Andrew