harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: svn commit: r386058 [1/49] ...
Date Thu, 16 Mar 2006 09:54:24 GMT
Stepan Mishura wrote:
> Leo,
> I agree with you that big commits are hard to review and to understand what
> was changed. Why not to partition them?

They are incoming contributions that were committed in bulk and
reference the original JIRA.  We have all had a chance to look at the
contributions and vote on them already.

> At least I don't understand why
> HARMONY-57 and HARMONY-88 were committed in one day. 

Why not?

> Integrating these two
> contributions of course changed the build: wow, the build now downloads
> resources from the net and it failed to do this ...

I agree, I don't like this either.  It will be fixed.

> 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? :-)

C'mon Stepan, we are in a period of change while these bulk
contributions are merged into the code base.  There are a few bumps in
the road but they are being sorted out quickly, and the result is a much
more functional runtime and lots more tests.  Please lend a hand rather
than sniping from the sidelines :-(


> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
> On 3/16/06, Leo Simons <mail@leosimons.com> 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


Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message