Leo, I agree with you that big commits are hard to review and to understand what was changed. Why not to partition them? At least I don't understand why HARMONY-57 and HARMONY-88 were committed in one day. Integrating these two contributions of course changed the build: wow, the build now downloads resources from the net and it failed to do this ... downloading them by hands ... opsss, no property IdontHappyWithNetworkBuildUseLocalCopies ... hacking the ant script .... wow, the script to run test trying to download the same resources ... hacking the script ... hmmm, there are failed tests, what is wrong? .... aha, old known problems ... well, are there any other surprises? :-)
Thanks, Stepan Mishura Intel Middleware Products Division On 3/16/06, Leo Simons <[EMAIL PROTECTED]> wrote: > > 49 commit messages for a single commit! The continuous wash-in of > Really Big(tm) chunks of code scares me a little (even if its real cool) > -- usually I make it policy to read every single line of code contributed > to a project for which I'm on the PMC but there's no chance in hell I'm > going to spend an entire weekend reading unit tests. Just keeping up > amounts > to something close to a fulltime job. The "usual" "oversight" model that > at > least some parts of the ASF are used to seems near-impossible to apply > here. > > Will all people able to read every line of code as it comes in please > raise > their hands? > > I'm thinking about how to make this stuff scale. Any ideas? The natural > tendency is to want to partition, but that way we lose the "many eyes" > advantages.... > > Anyway, just a random thought... > > - Leo >
