SeaMonkey Project Blog

Hi everyone!

Build 3 has been pushed to the regular candidates path.  I’ve coined a ‘new’ term “candidatized”, meaning it’s been sent to the candidates path on archive.mo.

That said, there’s a chance it’ll be dubbed 2.49.5 instead of rc3.

Also, that said, there’s a few changes from the previous automation-based releases/candidates; that being, a lot of the files that are supposed to be there, aren’t and files that shouldn’t be there, are.  The automation is still not working.  The automation that’s in place is manual…  😛

Yes, we’re missing a README file.   No fear…  that’s coming next.  So if you refresh that main build3/ page, it should appear within 24 hrs provided it’s there.  [motif being “it’s there when it’s there.”]

Again, I cannot stress this out.  Both IanN and frg were the mainstays of this release.  So all round applause to them!

:ewong

Hi,

After a long delay, I’ve uploaded the build2 of 2.49.5.

Checksums are there.

Next to be done will be build #3.

:ewong

Hi All,

There seems to be a mistake.  I have generated… well, not *I* per se, but the automation (*lol…  yeah.. *right*) or semi-automation seemed to have sent some of the tarballs/binaries elsewhere (or ignored them…).  This will be fixed.

Seriously..  when will my incompetence end?

My apologies.

:ewong

Dear All,

The checksums have been updated.

Sorry for the fubariness.   I had tested the script on one file and it worked, so I ran it for the rest of the binaries.  The flaw in that idea is that just because the ‘first’ binary’s checksum was right, it didn’t mean the others are.

The script’s been fixed.

:ewong

Hi Everyone,

It’s been a hell of a long time since an update.  So… here’s the long awaited update.

1. I’ve been swamped at work and stumbling over everything related to SeaMonkey.  My apologies.
2. Thankfully, both Ian and Frg have taken upon themselves to get the builds going.  2.49.5 will be released in their honor.

That said, and it bears repeating, IanN and frg have both been hard at work generating the 2.49.5 build1 builds manually and I owe them a debt of gratitude for working on the builds.  While I don’t expect them to need to manually do any other versions other than 2.49.5, I can’t guarantee anything.

Now on to 2.49.5 release comments.

1. The whole build/release process is sooooo different from what everyone’s used to, I’m not sure how to proceed.
2. That said, build1 is being uploaded to the candidates/ section on https://archive.mozilla.org/pub/seamonkey/candidates/2.49.5-candidates…   In the past, any build<n> (where n > 1) usually means n-1 builds were failures.   It’s no longer the case as build<n> should be more or less treated as ‘release candidates’ (aka.  rc<#> in the olden days).
3. Due to how things are done, the release files are uploaded ‘manually’ (as in not part of automation), so there’ll probably be some missing items. (Case in point, README…  those will be generated in the release/).

As for the infrastructure, it is at the bare minimum ‘of ok’ness.   That isn’t the problem or issue.  It’s the automation that’s still being worked on.   I know. My complete bad.  But it is being worked on with due haste.

Now that the current project’s update information has been updated, I’m returning to your scheduled program of preparing the tar and feathers….. um… oh wait.look…   I can explain…

:ewong

Hi Everyone,

tl;dr; I’ve messed up majorly and need to revamp the infrastructure; meaning further delaying any hopes of releasing ANYTHING. Blame lies solely on me as I had contracted the serious case of “Thomas the Steam Engine”-itis.

That said, things probably aren’t that bad; I’m just so deep into this hole that I’ve dug the project into, I certainly can’t see the light of day.

Call me, Mole…  Mr. Mole.

— Long Missive —

I have taken up the mantle of the person who will bring bad news. (Could be good news, depending on your point of view, I guess).

But first, a confession.

I screwed up. I admit it. In the past, our old infrastructure’s CI was manageable; just had to fix up some code. But now, things have become untenable as the current build process is completely incompatible with the current CI code and changing the whole backend codebase is requires understanding the current build process (which has changed dramatically since Mozilla moved to using TaskCluster).
(NB: No.. Don’t get me wrong. I’m not blaming Mozilla. Just saying that *I* can’t keep up with their changes, which probably speaks volumes of my competencies and delusional thought process.) So what is needed is revamping the whole CI code to make it work.

That said, since time is of the essence, I’ve consulted with the rest of the guys and we’re moving to Jenkins, since revamping the old CI code would require some hacking at an already Frankenstein-like code, so the technical debt needs to be paid.

Is it the end of the world? No. I’m just particularly unhappy that we’re in this situation; but hindsight is always 20/20. So yes, this means any future releases will depend on getting the whole build process encoded into whatever way Jenkins requires.

Also note that SeaMonkey needs to completely stop relying on Mozilla’s infrastructure (*every single thing*, including this blog, bugzilla… you name it.. we need to be off it) by end of the year.

Anyway, I sincerely apologize for the mess; both to every single one of SeaMonkey’s users (both past and present) and to my fellow devs (again, both past and present).   As part of my defense, last year, I thought (with the delusions of competencies) moving to Azure wouldn’t be that problematic and while I did get a ‘running’ (though not really building) infra, everything went crazy near the end of last year as I had realized the required builds and branches needed new tool chains; and building these toolchains required a lot of time and energy.  At the end… a failed attempt at keeping up to date with the whole build process.

So… the project is at a standstill.

In any event, I would like to thank everyone for their support in the past and continual support and infinite patience as this project continues to climb this steep (or as Richie from “Bottom” would say, “f’ing” vertical) hill/mountain.

*sigh*

:ewong

NB: In other words… Live and Learn.

Hi all,

(didn’t really have any quip to put in the topic..  so wrote that…  *shrug*)

We have finally started spinning 2.49.5.   This is going to be the most EPIC build process.  Why?  Oh…let me count the ways.

1. 2.49.5 will be spun on a totally new and unproven infrastructure (yay… ;/ )
2. 2.49.5 will require A LOT of trial and errors.
3. 2.49.5 isn’t going to be released that fast as we depend on three systems.  I’m hoping to get another system up to take up the builds.

Here’s the status of the build.

• The tagging process completed with a hiccup but it ‘should’ be ok.
• Current build(s): Linux32 [failed – in the process of being fixed]
• Win64 is not talking to the master so apparently Win64 has had a tiff with the master. (*sigh*  will have to convince those two to become friends again.)
• OSX64 is off doing its own thing (nightly..  need to redirect its attention to more pressing matters.)

I’ll update everyone as it progresses.

:ewong

Hi Everyone,

It’s been awhile since this blog was updated.  No, SeaMonkey hasn’t disappeared or gone.  We’re still plugging away at getting things done; but it’s been a very slow process, of which, we apologize.

The project is still alive and we’re all busy figuring out the whole shebang mess.

To answer a lot of people’s question: “What is going to happen to the project?  What’s in store?”

The tentative answer is: While we’re basing our release on ESR52 (with ESR60 being (afaicr) untenable),  we’re looking at a possible 2.53 or at worst, 2.57 as being the next ‘stable’ platform.

As for the ‘future’, we’re not as optimistic since a lot of our code is XUL based and a lot of the dependent code has been ripped out from the engine already.   So what you’re seeing in comm-central (and dare I even say, comm-beta) is terribly broken. [Expect an edit here, as I’m a bit out of the loop wrt the code.  I’ve been so knee deep in the infrastructure setup. ]  That said, what we will do to continue SeaMonkey is really up in the air.   Should we migrate off XUL and go quantum while trying to maintain some semblance of SeaMonkey, or should we just run as is until the engine completely fails or fork off the most stable Gecko XUL code and work on it?  [For the latter, some have said it will be the death knell for SeaMonkey as we do not have enough knowledge, expertise and resources to maintain such code.]

While this isn’t the right place to discuss this type of decision, I’m just putting it forth out in the open (in the name of transparency) so that users can think and discuss it on the newsgroups/mailing list.  After all, we are working on this project for our users (and ourselves, of course as we also do use SeaMonkey).

Thank you all for your patience and support.  It means a lot to the remaining members of the SeaMonkey dev team.

Best Regards,

:ewong

SeaMonkey’s infrastructure has officially been decommissioned.

May the memory of all these years of building SeaMonkey on these systems remain in the annals of SeaMonkey’s history and in all of the current and past contributors who had the fortune of administrating them (and fighting against their impulsive bustages).  An era has ended.

(Lights a candle for each of the following systems: )

• sea-hp-linux64-{2,13}
• sea-vm-linux32-{2,7}
• sea-mini-osx64-{1,4}
• sea-vm-win32-{1,4}
• sea-win32-{01,04}
• sea-master1
• sea-puppet
• the Windows loaner

A new era has begin.

Thank you for all the contributors and users who’ve supported this project and continue to do so despite the changes and the delays in releases.  We appreciate your continual support and patience as we get the new infrastructure up to par.

:ewong

SeaMonkey Release Engineer