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
>> <http://groups.google.com/group/tb-planning/browse_frm/thread/7cd3e8ab756f910e#>
>> about a second set of builders / canary system. I've come up with a
>> spec of what we want it to do:
>>
>> https://wiki.mozilla.org/Thunderbird/Infrastructure/Canary_System
>>
>> 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.

Robert Kaiser



More information about the tb-planning mailing list