<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi All,<br>
<br>
You'll possibly remember the thread we had a while back about <a
href="https://wiki.mozilla.org/Thunderbird/Infrastructure/Canary_System">Canary</a>.<br>
<br>
What most of you probably don't know is that we've been trialling a
skeleton implementation for the last few months (see the <a
href="http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTested">ThunderbirdTested</a>
tree for the 'good' tree).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
I'm thinking that we could redirect efforts and resources to the
following instead:<br>
<ol>
<li>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.<br>
</li>
<li>Repurpose the builders to provide disposable branches, similar
to the <a
href="https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning">Firefox
ones</a></li>
</ol>
<p>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.<br>
</p>
<p>Comments welcome.<br>
Mark.<br>
</p>
</body>
</html>