I think we are saying the same thing, by pervasive, I meant a change that would "prevade" the source tree, and touch a lot of files. Yeah, your reply does answer my question, which if you boil it down was "Is there a reason why we cant make all the smallish changes all at once". If you think such a change would be too pervasive/invasive and therefor a bit difficult to review, then I say "God Speed" to your approach :-)
Eric Matt Ingenthron wrote: > > Eric Lambert wrote: >> Hey Matt, I don't have a problem with the strategy you've outlined below >> but just out of curiosity how pervasive would the changes be if you >> submitted them in larger chunks as opposed to these small type changes >> you suggest? >> > > Do you mean invasive? > > Well, the point of doing it in pieces is so hopefully no single piece > will be invasive. Any that are more invasive than others should > include tests. The goal is that the last commit that gives us > pandorabuild goodness is 'just' changing out the build environment. > > An example of what I found to be invasive before was a series of int > and size_t values being interchanged. I would end up making some > small changes, finding the header needed to change, that would then > require a bunch of other small changes to 4-5 other functions. > Gathering a series of these together into a single code commit would > mean touching a bunch of files in a bunch of places. It just felt > like too much to send over at once. > > Does that answer your question? > > - Matt
