Bryan Stearns wrote: > I'm sure I've broken all of them; there's been no other way to make > progress, and there's been no community pressure not to.
I have too; I didn't intend to single anyone out. > Unfortunately, this won't solve our current problem. Yeah, because the tree has been bad for so long, and new checkins have piled on top (see above) so that it is hard to come out of this situation with the checkin rules as they are. My point, though, is that I don't think we would be in this situation if we had strictly followed the rules. So how do we get out of this situation? Well, we've already disabled one test that is failing on Linux and filed a bug; Jeffrey has a pretty good idea of what is going on but it is probably going to take a couple of days two fix. So I believe in this case we are in agreement on how to resolve this issue. The remaining orange on Tbox is because the functional tests depend on previous tests that have been run, and they did not like taking out that one test. Jeffrey and Dan have checked in changes that should modify those tests that come after to not break. We still have some intermittent tests failures, but they are much more rare (latest two on Mac were: functional test timeout and Python crash during functional tests). I also checked in a change that should make flickr test failures less frequent (I attempted that yesterday but had bogus exception name). > My initial reponse here was "OK, I hereby promise to follow all the > rules", but that means I won't get anything else done for alpha4, and > (assuming everyone followed the rules to the letter) you won't see any > changes until the tree goes green, when you'll suddenly get a whole The tree will not go green unless there are some changes. And the checkin rules doc does say that if anyone sees an orange tree it is their job to help fix it. So I think it does in fact apply in this situation as well. (But we are going by the 'disable test route' now, which is not in the doc.) > 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. 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? 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? -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
