harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: svn commit: r386058 [1/49] ...
Date Thu, 16 Mar 2006 08:11:16 GMT
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 <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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message