Bryan Stearns wrote: > I thought the general idea (see > http://wiki.osafoundation.org/bin/view/Projects/CheckinRules) was:
Yes. > That doesn't always work, however: we've occasionally gotten into > situations where, in spite of the above, multiple changes cascade into > an extended period of failing tests -- like, *now*. In times like this, And I believe it has happened partly because the rules haven't been followed. I've seen all of the rules you mentioned broken in the last two weeks. > I thought the idea was: > - P1 bugs get filed for each failure > - The failing tests get disabled on the platforms on which they fail > (with bug numbers in the comments) > - People are assigned to fix those bugs and reenable the tests. This is not my understanding. The last time we discussed these publicly (winter?), I believe we recognized it a problem that several tests were disabled and you could not rely on your code being correct because so many tests were disabled. Because of that we agreed that it would be a priority to re-enable all disabled tests, and no longer disable tests but fix the issues instead, quickly (by backing out if nothing else). I believe we have followed that more or less, but when a code freeze is getting nearer it seems the pressure to get fixes in is the driving factor. I agree it is frustrating that Tbox has been orange so much lately. I think the solution is to follow the checkin rules as written. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
