So SeaMonkey 2.18 was supposed to be out today, so where is it?

We have had a hardware error in the systems that allow us to reliably generate the release — Without these systems anything we create will be of unknown quality/stability.

In order to meet our own quality and stability requirements we are NOT releasing SeaMonkey 2.18.

While there is a chance we could have these systems back up in time to do an intermediate release (say something corresponding to a possible Gecko 21.0.1) we can not promise nor plan for it at this time.

We are actively working on repairing the system and its data, once that is complete we will go forth with a new BETA based on the SeaMonkey 2.19 train, and we expect to release SeaMonkey 2.19 on time, on June 25′th.

We thank you for your understanding.

Yesterday, we were given the confirmation that we are now able to turn those tests back on, and we have done so.  You should now see Fedora32 tests on all your Inbound, Central, and Try pushes, as well as any twig/project-branches.

Any questions/issues join us in #releng on irc.mozilla.org.

Since our last conversation a lot has changed with me (and Mozilla!) I was a contractor since March, and just got my official offer to come on as a “real” employee. I will be detailing my journey in the community to a full time employee through a series of upcoming blog posts. (now don’t get me wrong, I’m still working on SeaMonkey in my free time too)

To also mix it up, I intend to throw in many blog posts about the state of our Mobile Infrastructure/Tooling, and where we intend to go from here. However I need ideas on posts! So to get me started, I’d like to enlist you, planet readers, to send me questions/topics you would like to learn more about when it comes to Mobile Automation (in Release Engineering) that I could blog about for you. History Lessons, Future Direction, Current Setup, Whatever!

Send your Topics/Questions to me at callek+blog@mozilla.com I cannot promise I will address every question/topic requested, but I can promise to try.

This work so far has been both challenging and a thrill!

Until Next Time!

He and his lovely wife just had a baby!

I won’t share any more details than that, since I just found out, and have not asked permission, but I did grant him access to post on my blog here, and I invite him to do so pictures and all!

A few new software installs, as well as a few software upgrades.

Most notably is an upgrade to our buildbot code in production here (to match what is currently in use at Mozilla for Firefox). [special thanks to dustin for his help getting me rpms and files as mozilla prepared them for their own use]

There should be no issues, since most of the changes were in the way our automation is setup not in what actually produces/creates builds. and this work affects all branches. (SeaMonkey 2.4 final is already built, so did not affect that).

If you see anything that seems broken to you on linux, or any weird issues, please let me know by filing a bug (blocking Bug 687797), or finding me on IRC.

There was some accidental breakage in the Mac builds of Nightly last Friday (Sept 16th), which results in a crash when you try to update your build. The revision & buildID for the broken build is

• ad202468df63, 20110916003001

You can check what you have by loading about:buildconfig, or evaluating navigator.buildID in the Error Console.

The solution is to download the latest Nightly build from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/latest-comm-central-trunk.

Thank you Nick for calling out this issue!

SeaMonkey 2.3.2′s download internal files, internal version, and all else of 2.3.2 except our website and files at our download directory location are indicating that it is SeaMonkey 2.3.1. (details in Bug 683473)

There is nothing to worry about there, we did properly include the DigiNotar cert block, as did Firefox 6.0.1. We are however also getting ready to release a SeaMonkey 2.3.3 release for a related Gecko issue, so we will correct our version number with that release, and not bother with any more updates with SeaMonkey 2.3.2 (See the bug driving this respin of Firefox at our bugzilla instance)

We are sorry about all confusion, and any issues this may have caused.

Stay tuned at our official blog for the release of SeaMonkey 2.3.3!

To quote:

From my project leader point of view, as needed I deployed myself as an extra developer to speed things along. In the debrief, Luke called this the “glue person” role. He said having a glue person allowed everyone else to get into the zone and do lots of design work and big blocks of coding–everyone else on the project doesn’t have to worry about random bugs and and other small technical issues because the glue person picks them all up.

That is a quite astute description of WHY this type of contributor is such a blessing to any large project, especially one like our JavaScript engine.

The SeaMonkey Project also has someone filling this role, quite helpfully. Surprisingly role is NOT being filled in our case by our Former Project manager (Robert Kaiser) nor myself (my duties primarily reside in Release Engineering) and also not within our current SeaMonkey Council (The primary “Project Management” group) though many of the above do varying tasks, of course.

For us the person the “Glue Person Role” resides with, came to us a bit over a year ago, looking to help. He then met us at our Face to Face meeting in October, in Vienna Austria (invited due to the value we all perceived in his contributions, and the future value in having him come)

In our Bi-Weekly IRC meetings his Bug Fixed list is frequently very very long, and he actively seeks out bugs to fix, mostly choosing from our “Good First Bug” list. I’m coming to call him a jack-of-all-trades myself, even though we all still help with hand-holding every now and again.

I’m sure being a “Glue Person” was not his intention, but his efforts here are greatly beneficial to us in keeping SeaMonkey progressing at the pace we need it to, and ensuring that the minor annoyances don’t file up too high for most of our users.

So after all that,

THANK YOU EDMUND WONG![ewong on irc]

Your work is invaluable and I hope you keep it up. And for those of you reading this, if you always wanted to help, feel free to ask around a project you would like to help with. Being a glue person may not feel glamorous, but it is MUCH more helpful to the rest of us developers than you would believe.

To address leading developers on any project around here, realize the “Glue Person” is also a great reason to spend a bit of extra time helping new people to learn the ropes, or a bit of vocal “well you should peek here” to fix any relatively simple bugs someone wants to help with. We need more people like ewong across all our projects!

For those who are not paying attention, mozilla-central (what was the lead up to Firefox 4.0) has branched, and Firefox 4.0 (Gecko 2.0) now resides in hg at releases/mozilla-2.0 along with this change, mozilla-central has been opened up for checkins again.

What about versions?

• we created a comm-2.0 buildbot tree, which uploads builds based off of mozilla-2.0 to the latest-comm-2.0 directory on ftp.
• Made builds which are based off of mozilla-central now listed as version 2.2a1pre (Our next version will be based off of Gecko 2.0)
• The builds in comm-2.0 will continue to be SeaMonkey 2.1b3pre (and 2.1 final upcoming)

FAQ

I am a nightly tester, what version should I expect?

If you were testing a 2.1 build, you will automatically be upgraded to a newer 2.1 build; this does mean that from the point we flipped the trunk switch for version numbers, you may have a failed partial update; Do not worry if so though, as it will fallover to a complete instead.

But, I want to test nightlies on 2.2a1pre (Gecko 2.0.next)

If you want to follow the extremely undertested mozilla-central versions you can download a 2.2a1pre build from the latest-comm-central-trunk dir on ftp, and your updates will continue along that path. Do note, that we know of a few existing bugs on this configuration already, however both ourselves and the Thunderbird team are concentrating our efforts into the Gecko 2.0 based builds.

I am a local developer and want to build/checkout for SeaMonkey 2.1

You will have to pass to client.py the –mozilla-repo option for the stable mozilla-2.0 builds, we left client.py checking out mozilla-central. The recommended way is to rename the existing mozilla directory to something else (.mozilla-trunk is my recommendation) and then run client.py co –mozilla-repo=”http://hg.mozilla.org/releases/mozilla-2.0″

I am a developer, wanting to checkin what do I care about?

For all intents and purposes you can checkin to comm-central based on the status of the SeaMonkey2.1 or Miramar (Thunderbird 3.3) tree’s the SeaMonkey and ThunderbirdTrunk tinderbox trees are nolonger blocking landings. Also watch SeaMonkey2.1 and Miramar trees for tree-rules/status primarily.

I am a localizer, what repository are you using for SeaMonkey2.1 builds?

We are currently building l10n repacks with the releases/l10n-mozilla-2.0/{locale} set.

It has not yet been explored if we can/will do a l10n-central<->releases/l10n-mozilla-2.0/{locale} merge for seamonkey/thunderbird specific locale files yet, we will keep you informed.

I have another question, or am confused about something.

We’d love to hear from you if this is the case, please see the newsgroup (or mailing list) mozilla.dev.apps.seamonkey. Or just comment here and I’ll respond.

The Good

• I upgraded all our Windows slaves for the DirectX SDK, enabling us to ship the redistributable parts of that with our binaries, allowing most of our users to have GPU acceleration just liek in Firefox, where they normally would not have; also enables us to build ANGLE a critical part in that acceleration. — Mostly benefits our trunk/SeaMonkey 2.1 builds.
• Upgraded our [windows] slaves to HG 1.7.5, enabling me to work on Bug 643324 which enables HG_SHARED support on our Windows Machines. My work there only enabled the use of share for the larger repo’s we have; namely comm-* and mozilla-* and left LDAP/etc. pulled as normal. (mac and linux coming soon). The idea and the basis for this was due to the work Chris Atlee performed on try recently, read his blog post for more information and why this is so good!
• Spun up the oilspill builds for 2.0.13 [ftp] in line with the upcoming chemspill releases for Firefox 3.5.18. (I have not yet announced these builds yet, but I should have a call for testing up within 24 hours, feel free to jump into it with this blog post though)

The Bad

• While doing the hg upgrade on our slaves, I created the hgrc’s I needed using the slave-side windows notepad; Forgetting of course, that notepad saves in Unicode by default, including a BOM; which our Hg was unhappy with, breaking some builds. At the same time I did not save some of the |.hgrc| files correctly, and they got windows-translated to |.hgrc.txt|, cleaned that up swiftly.
• While preparing for the 2.0.13 release, I updated the configuration file locally, but forgot to specify the ssh://* repo url when I went to push, so my local push failed. I did not notice and reconfigured our build master and triggered the buidls anyway. This caused the already-on-ftp 2.0.12 build1 builds to get overwritten along with the support files. And delayed me having 2.0.13 ready sooner.

The Ugly

• Because of the bad mistake with 2.0.12, I made matters worse. When I went to start to sync in from the pushed-to-release files, I clobbered in the wrong directory on stage (ftp), which meant I cleared the WHOLE build1 dir of SeaMonkey 2.0.12, causing me to miss some intermediate files that are needed by automation (I did lose the crashreporter symbols too, but those are unneeded by our automation at present).
• Due to clobbering those files, I tried recreating them by hand, after a few hours of re-syncing in the necessary files as they should appear in that folder. I created the BuildID, but sadly, I used the abbreviated buildID (YYYYMMDD) rather than the full one (which varies by OS/Build here). The reason that matters is that the 2.0.13 automation, when generating/verifying the updates writes that build-id as specified on ftp to some files needed for sanity-check automation only and then uses them to download and test updates. So I then had to go back in and update those values correctly, update the config files for that automation step, and re-run.
• I have not yet managed to have a trouble-free release since I took over, from “GO”->”Release”, here is hoping for next time.