Canary System for trunk
KaiRo - Robert Kaiser
kairo at kairo.at
Fri Jun 18 23:09:13 UTC 2010
Dan Mosedale schrieb:
> On 6/17/10 1:19 AM, Mark Banner wrote:
>> Based on the recent discussion
>> about a second set of builders / canary system. I've come up with a
>> spec of what we want it to do:
>> At this stage, I'm just trying to come up with a list of aims/basic
>> design features to check that we've got everything that we want from
>> it covered. Once we've agreed on that, then we can start thinking
>> about the implementation.
>> Hence, please provide thoughts/feedback here.
> Nicely put together. I like the goals & prioritization. I also like the
> automated updating of changesets.
> I would suggest making the names more explicit, as it feels to me like
> the current proposed names are likely to lead to confusion. Maybe
> TbKnownGood and TbUntested?
> As far as keeping old data to support regression hunting, would it work
> to automatically check in the most recent known good mozilla-central tag
> to comm-central client.py? That way any given client.py revision would
> have the appropriate working mozilla-central revision encoded in it.
IMHO, that would make the comm-central pushlog mostly unreadable with a
huge number of pointless checkins. Trunk is trunk is supposed to break
and be fixed. If you do a system that breaks with that, please keep it
out of comm-central.
More information about the tb-planning