Canary & Feature Trees

Mark Banner mbanner at mozilla.com
Tue Feb 14 16:07:56 UTC 2012


Hi All,

You'll possibly remember the thread we had a while back about Canary 
<https://wiki.mozilla.org/Thunderbird/Infrastructure/Canary_System>.

What most of you probably don't know is that we've been trialling a 
skeleton implementation for the last few months (see the 
ThunderbirdTested 
<http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTested> 
tree for the 'good' tree).

As you'll see that at the moment the ThunderbirdTested tree is red. 
That's because we had some build bustage from mozilla-central a while 
ago, which we've now fixed, but our trunk tree has not had a green cycle 
since (because of test failures), so the "good" changeset hasn't been 
updated.

If we took test failures out of the equation, that would make it more 
likely to keep up to date, but I'd assert we're seeing more test than 
build failures due to mozilla-central changes at the moment.

Therefore I think to make Canary really work, we'd need to put some 
effort into reducing the amount of oranges, and some more into a 
"manual" update facility so that we could manually tweak the revision as 
an when necessary (hence some sort of webapp).

Whilst I know we've just come out of a long tree closure due to test 
bustage, I'm currently thinking that to spend the effort getting Canary 
fully working at this time isn't worthwhile.

I'm thinking that we could redirect efforts and resources to the 
following instead:

 1. Fixing the build system to reduce the duplication of the
    configuration files. This would save us a bunch of time for porting
    changes, and further reduce the likelihood of build bustages.
 2. Repurpose the builders to provide disposable branches, similar to
    the Firefox ones
    <https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning>

This latter option would certainly help current projects like big files 
- whilst we can get more hardware, we're also transitioning to the 
Firefox network at the moment, so I'd like to keep our hardware 
requirement relatively stable over the next month or so.

Comments welcome.
Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120214/fcedd2ad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120214/fcedd2ad/attachment.p7s>


More information about the tb-planning mailing list