It worked, but barely. Since then, the Mozilla #build folks did an amazing job adding new features to theirs, fixing bugs, and making it more awesome in general. Unfortunately, the Thunderbird Try Server stayed behind, the way it was. Bugs against it were piling up, especially from folks using both try servers and noticing all the missing features compared to the Mozilla Try Server.
All this is about to change! The Mozilla Messaging Build team has worked on recreating a try server with all the new features (and codebase) that runs the Mozilla Try Server.
On Thursday, we'll be switching over to the new try server. What does this mean?
By just doing:
$> hg push -f ssh://hg.mozilla.org/try-comm-central/
from a comm-* checkout, you'll be able to trigger try builds. It's that easy!
For more detailled instructions, you can just refer to the Mozilla Try Server documentation, just use /try-comm-central/ where it says /try/, that's the only difference. Also check the Mozilla Messaging Try Server wiki page, for documentation specifically about our try server (not updated yet)
Right now, we will only be running regular builds and mozmill runs, as the other type of builds are all waiting on the libxul work to complete before they can be made to work easily. Also, there are various features that we want to see in our try server that will not be done, but they will be tackled one by one over the upcoming weeks.
There are 2 important thing to note. The first one is that we'll be turning off the web interface for our try server that allowed for arbitrary patches to be submitted. It was a mess of code, and would simply not work right in this new push-to-try way of doing things.
I know the Mozilla #build folks are working on a new, shinier web interface to their try server, and once they do, we'll just port it over as well.
The second thing (and I suspect many will be happy about that) is that since push-to-try works via hg.mozilla.org, there is not going to be a need for a special certificate to gain access to it. Anybody who already has hg.mozilla.org access gets automatic access to our try server!
As before, you will be able to follow the status of builds on the ThunderbirdTry tinderbox tree.
For bugs specific to our try server, you can file bugs under Mozilla Messaging > Try Server
]]>Thankfully, it's a pure-javascript webapp, with no dependency on anything but itself. So, I just grabbed the html/js/css files and I had something up in no time. Of course, it didn't work at all, but that was a small detail.
A few fixups later, I had it working and taught it about the 2 Thunderbird trees, and Sunbird, while I was at it.
Originally, it used a PHP script to proxy/massage stuff back to tinderbox.mozilla.org and hg.mozilla.org, but since my PHP-foo is weak, and I didn't have the source code to actual PHP, I did without. A few httpd.conf
changes later, and it was all working.
It's a really nice alternate way to look at the status of a tree. Have a look for yourself!
The original one is here: http://tests.themasta.com/tinderboxpushlog/
The Thunderbird one is here: http://build.mozillamessaging.com/tinderboxpushlog/
I've cloned Markus Stange's original mercurial repository. You can find my clone at hg.mozilla.org too.
Note: Yes, the whole code was in Mercurial to begin with, I just didn't even look for it until after I had it all working, dhu!
]]>Thanks to Gary for having made me notice this was blog worthy.
We've recently released Thunderbird 3 Beta 1, and afterwards, I had a look at our traffic graphs for the Mozilla Messaging website during that period.
See for yourself, can you see when we released Beta 1?
]]>Mozilla Messaging now has it's own planet, planet.mozillamessaging.com, aggregating blog feeds from various Thunderbird sources. It's a complete ripoff copy of Planet Mozilla, just with different feed configuration.
It should get redesigned at the same time as the next incarnation of our main web site, so pay little attention to what it actually looks like, and just subscribe to the feed already.
Cheers.
P.S. If you feel like your feed (or a feed you like) should be on there, file a bug asking for it to be added
]]>I've been recently working on bug 449202:
Get Thunderbird L10N builds working on comm-central. It's been mostly about using KaiRo's existing work for SeaMonkey and s/SeaMonkey/Thunderbird/g in the right places.
Ran into a few more problems, mostly my fault, and some having to do with the way the MoCo build network is setup.
Turns out it's also fairly complex to test this stuff, as the current setup relies on notifiers kicking on changes to the l10n repositories, so triggering a l10n build on purpose is a bit tricky. Instead, it was simpler to just wait for somebody to change something in one of the many l10n repositories and see what happens.
Well, I am happy to report that the first localized build of Thunderbird since the move to Mercurial has been produced and can be downloaded. It's only a single build, and for Windows, but more will follow as the normal churn in l10n repositories will trigger some more.
Then, the fun begins tonight, as the nightly builders should trigger a build of all of Thunderbird supported locales in one go. So, by tomorrow morning, we should have tons (43 locales per platform, to be precise) of new localized builds waiting for us, sweet!
Oh, and in case you had been wondering, the first successfull build is here. I think it's pretty cool that the first locale that successfully build turned out to be ga-IE, so that will explain the topic of this post. Hopefully, somebody from that locale will understand the title (and apologies if I butchered your language, feel free to correct me please)
It's strange to be back home like this. I was driving around town, running some errands, when I heard his name on the radio (Radio-Canada). They were talking about his passing and had interviewed a few folks about the work he did during his practice. It made me realize that, had I not moved back to Quebec, I probably wouldn't have heard it on the radio. Made me proud of my grandpa, that's for sure.
Oddly enough, he doesn't have a Wikipedia entry. I think he should.
iLOM is what's running on their Opteron-based systems, like the Sun 4500 (aka Thumper), and it's miles ahead of eLOM. Can't wait to have iLOM everywhere, instead of the current mixture of eLOM and iLOM.
Unfortunately, to perform the upgrade, you need to take the servers down... Can't have it all, I guess. Fortunately, since we are already fully redundant, it shouldn't cause visible downtime at all. All our build machines will just pause for a few seconds, and reappear on a different VM Host. Stay tuned, I'll blog about how the upgrade actually goes when it's finally available.
First, that's only on OS X, sorry for folks running it on a different platform. Second, it's a bit of a lie, as I am talking about bug 448003.
Since we switched over to building from Mercurial, the code size tests we run were somewhat off on OS X. These tests basically measure the size of the code included in the product. For instance, right now, on Linux, it's reported at 15.7MB.
However, on OS X, they had been reporting 1.56GB! Obviously, this was a bug somewhere in the computation of this number, not the actual code size, so that's why the subject of this post is appropriately misleading.
Various hypothesis were put forward, including the fact it looked like it was off by precisely 100, so possibly a unit conversion problem, or something similar.
I've finally gotten around to it, and after some investigation, turns out it's more interesting than that. On OS X, we don't directly build universal binaries, but instead build once for i386 and once for ppc, then lipo the 2 builds together to form the final product.
To determine code size in this case, it would be misleading to count both architectures, so instead we pick one and size up that one. In our case, for historical reasons, that's the ppc version, even though our build boxes are Intel by now. Determining code size is done by parsing the output of /usr/bin/nm, an object dumping tool that nicely dumps the symbols list out of libraries and executables. Unfortunately, it dumps positions in the code, not size. So, to determine code size for a given function, just make sure addresses are sorted, then subtract the address of the previous function to the address of the current function, and you'll get the number of bytes that it takes up in the object file. Simple, right ?
Well, for some reason, not yet explained, on ppc, there is a strange symbol called trampoline_size that exists first in the list of symbols and sits at address '0'. However, right after it is the next symbol, strangely sitting at the address 0x20000000. That's 536870912 bytes further, if we believe what this is telling us. Of course, this is bogus. I am not entirely certain what this about, but if I could venture a guess, I'd have to say it has to do with the ppc executable format, OS X, and their ability to transparently run ppc binaries on Intel. Anybody that knows OS X/PPC better than me, feel free to correct me on this.
libnspr4.dylib: 00000028 a trampoline_size
libnspr4.dylib: 20000000 t __mh_dylib_header
libnspr4.dylib: 20001a7c t dyld_stub_binding_helper
Now that the problem is somewhat understood, it was a simple matter of teaching the code size stuff to ignore symbols like that on OSX/ppc and start at the next one. As you can see from the Tinderbox boxes, it was still pretty impressive to see such a large code size decrease! Oh, and SeaMonkey got the same drop in size, for the same reason.
]]>Recently, we started receiving nightly logs of the Thunderbird start page hits. It now comes to us nightly, and I also got some historical data back to June 2008.
For the time being, I've just been feeding them all to webalizer, for lack of a better idea. There is not yet a complete plan as to what to do with all that data. Right now, it goes straight to infinite storage every evening. There is a lot of it, averaging at around 8 million hits a day, The included graph is the average traffic per hour of the day. That's in the 300k-500k hits per hour! I am glad that this traffic is being served by the mozilla.org hardware.
I know folks have already started to think of ways we could mine that data to learn useful things about Thunderbird and its user base, but it's only beginning. So, for the time being, I'd like to hear from anybody who can think of a questions that could be answered by all that data. Of course, respecting our users privacy is important, so I don't want anybody to know anything about specific individuals, just about trends. Are Russians users checking e-mails more often than us Canadians, for instance? (Not so sure that's a very useful thing to know)
Got a cool idea ? Have something you'd like to know ? Please, let me know.
<gozer at mozillamessaging dot com>
Before anything else, you need TwistedWords, an instant-messaging library. So I had to go ahead, download and install it.
cd tmp
lftpget -c http://tmrc.mit.edu/mirror/twisted/Words/8.1/TwistedWords-8.1.0.tar.bz2
tar jxvf TwistedWords-8.1.0.tar.bz2
cd TwistedWords-8.1.0
python setup.py install
Once installed, all I had to do is to make a 2-line change to the buildbot master's master.cfg config file
from buildbot.status import words
c['status'].append(words.IRC('irc.mozilla.org', 'thunderbot', ['maildev']))
Next thing you know, you've got an IRC bot announcing builds, and you can even ask for new builds straight from an irc /msg, cool.