[Chandler-dev] Checkin process when the tree isn't green?

[Andi Vajda]

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..