On Tue, 19 Sep 2006, Heikki Toivonen wrote:
This will snowball us back into the situation we're in now. Therefore,
I'm proposing that a change to the policy for situations like this is
necessary, and further, that the policy should be what I said in my last
message: when the tinderbox is yellow for an extended period of time
(and I think the current situation qualifies: it hasn't been green
across the board in the eight days!), we *close the tree* and declare a
switch to this policy:
I still disagree. Here's why. If we strictly follow the checkin rules
doc, we will not have a situation where the tree is orange for longer
than half a day, maybe a day at most. There won't be a long list of
checkins to investigate and back out; we'll just back out if it has gone
for that long.
Even by 'strictly' following the rules, when a failure is intermittent, you
easily get into the situation of a bunch of check-ins having happened since
the possibly bad one. I think Bryan's alternative is an improvement.
What I don't understand is the extreme displeasure some people express
even at the mention of backing out bad changes. It is easy to backout,
and easy to recommit with fixes, and it will make the tree green
quickly. Why is this bad?
Because it is unrealistic. See my previous comment.
I'd like to hear opinions from other people as well. What is your
preference to deal with tree breakage in general, and this current
situation?
We've had flaky functional tests for ever. Having undocumented dependencies
between functional tests is just one example. Having strict rules around flaky
tests is not a good combination, something has to give. What's given so far is
that the rules have been bent, ie, flakily followed.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
