This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [rfa] symbol hashing, part 2/n - ALL_BLOCK_SYMBOLS


> 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]