Re: [Jikesrvm-core] pre-commit testing expectations

[Daniel F. <zyr...@zy...>]

I think I agree with Dave here. We need to aim to get something that
runs between 15-30 minutes that we can commit (sigh ;-)...) to running
before every commit. It isn't like that stops you from working - you can
run the tests in parallel. It is simple about not breaking the world for
other core team members.

=20

Perhaps we should look at having a script and/or machine that makes
doing some of this easier, nut In the end the responsibility is there to
run the tests to ensure you don't burn everyone else's productivity by
breaking the head.

=20

If there is a trade-off between slightly larger commits as opposed to
many tiny (not properly tested) commits, I am in favour of the slightly
larger commits. It is equally annoying to try and walk back through time
and find that a lot of the revisions you are looking through are
failing, as it is finding that the source of a problem is within a huge
improperly factored commit.

=20

Of course I am not saying commits should be huge either, just that I
think there is a balance and having everything tested is worthwhile.

=20

Cheers,

Daniel.

=20

From: jik...@li...
[mailto:jik...@li...] On Behalf Of David
P Grove
Sent: Tuesday, 12 June 2007 2:14 AM
To: Discussion of day-to-day development and design among JikesRVM core
team members
Subject: Re: [Jikesrvm-core] pre-commit testing expectations

=20



jik...@li... wrote on 06/10/2007 05:26:44
PM:

> Steve said:=20
<snip>
> 2. We can't prescribe people's work habits, but we can ask for and=20
> enforce personal commitment to a common objective.  Peter is=20
> absolutely right---we don't want to encourage large commits. =20
> Therefore, I don't think we can enforce each person to run the=20
> commit test before each commit.  We can only ask commitment to the=20
> goal and leave it to each individual as to how they meet that
commitment.=20
<snip>=20

I disagree. I think if we have a test set called commit, then as a
project we actually can and should mandate that it is run before every
single commit that touches code that is tested by the commit test suite.
If we aren't going to mandate that, in my opinion we shouldn't call the
test set commit.  =20

Maybe I'm showing my industrial bias here, but in my opinion part of
effective long-term team development of a complex system is to have
commit standards that are uniformly applied.  Because I want them to be
run by everyone on every commit, I also want the commit tests to be
shorter than they are right now.  Just a few carefully chosen tests that
have the highest probability of catching high-impact bugs and preventing
them from getting into the head and disrupting everyone else's
productivity.=20

I agree that people should be responsible and run more extensive tests
for whatever subsystems they are changing in addition to the commit
tests. We can also help by improving our automated testing system and
running a medium level of tests more frequently than once every 24
hours.=20

--dave