Yes. We observed similar pattern.
Adopt an I-Build is a very costly process
for us. It is measured in man-days.
Every time, we adopt I-Build that
doesn’t go as far as the previous one, we take big hit on productive and
we would not able to proceed with some implementation. Without proceed with
implementation, we won’t discover critical bug that need to discover
before 0.7.
Because we only have 2 weeks, I would
think that we want to go one level further. We should respin nightly build
every 4 hours, and make it the first priority to have all compile error and
JUnit test fixed once it is discovered in nightly build. And, all JUnit test
should be deemed critical.
This suggestion might appear to be costly.
But, I believe the saving from the unstable build’s cascade effect is
beyond the cost. After all, compile error and JUnit tests need to be fixed
anyway. Fixing it early enable people/team in the downstream to start working
on that earlier.
In short, I counter propose:
1/ We move the expectation of a nighlty
build up, as what we would had expected from a I-Build
2/ We respin the nightly build every 4
hours.
3/ We fix all compile error and all JUnit
error within a I-Build.
4/ We produce a warm-up I-Build on
Thursday.
Thomas
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Timothy Deboer
Sent: Tuesday, June 28, 2005 6:19
PM
To: wtp-dev@xxxxxxxxxxx
Subject: [wtp-dev] Stability of
I-builds during release shutdown
Hi everyone,
The
0.7 release candidate builds are proposed for the 13th and 22nd, with the
release at the end of the month. What I haven't seen is what happens between
these times - presumably we are going to run nightly I-builds or something
similar. My concern is that with constant I-builds typically comes constant
churn - every team ends up taking a turn at breaking the build and we have
brown-outs that are nobody's fault - most of the build is good, but there are
some less stable parts which change from build to build. Our past I-builds are
a good example - although they are fairly stable on Tuesday, we typically have
a series of build and JUnit failures until sometime Thursday when everyone
starts focusing on it.
To
ensure that we have frequent, high-quality builds that can be used for testing
and external teams building on top of WTP, I propose one of the following:
1. We
do less frequent I-builds (e.g. every 3-4 days), but use warmups like we have
done with previous I-builds. For example, we could start spinning I-builds on
every Monday morning and spin every 4 hours until we get it clean, then do it
again on Thursday.
2. We
stay vigilant - every nightly I-build should be as good as the previous
milestone/release candidate. Any compile errors or JUnit failures are deemed
critical and must be fixed asap by a respin.
Thought?
Opinions? Other suggestions?
Thanks,
Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503 (tieline 969)
deboer@xxxxxxxxxx
