Impact of TB organizational changes on SM releases?

[rsx11m]

Probably not everybody is following the discussion in Thunderbird about the upcoming changes in their releases after Gecko 17.0 (due mid November 2012). In brief (and simplified), Mozilla is substantially reducing their investments in Mail/News and pulls much of the thus far committed paid developers or contractors (there are several threads in the tb-planning group). While Mozilla continues to take care of security and stability fixes for TB releases, feature development is expected to come from the community after 17.0 has been released. To that extent, Thunderbird is thus kind-of entering the same boat SeaMonkey has been in already for the last couple of years, so that should not be as alarming as it sounds (and many were complaining anyway that features were pushed too aggressively with the rapid-release system).

Current plans for Thunderbird include to follow the 17.0 ESR (extended support) branch with releases until a new ESR branch is opened (see the summary and detailed posts on tb-planning), thus no longer moving beta versions directly to the upcoming release branch. Furthermore, only one beta is envisioned during each cycle, increasing frequency towards the Gecko 24.0 release.

It is not clear to me what the impact on SeaMonkey releases will be, so maybe someone else has more information on the discussions in the background (the IRC logs ended a year ago, not sure why). In general there appear to be two options:

1. SM follows what TB did and produces releases after 2.14 against mozilla-esr17, which would ensure stability for the duration of this branch but may delay new features from entering the releases (thus, in essence the pre-rapid-release status);
2. SM stays in the rapid-release scheme and builds against current mozilla-release, thus picking up improvements in the browser, but possibly introducing instabilities in the mail/news part given that there is less incentive from the Thunderbird side to fix regressions introduced by Core changes (i.e., SeaMonkey developers and other volunteer contributors may need to be increasingly active to fix those before they become relevant for the next release).

Again, except from what can be read in the tb-planning posts, I'm speculating here, thus anybody please correct me if I'm incorrect with this assessment, but it should be good to think about it in advance before being caught by surprise later.

[therube]

(Not knowing anything about Mail...)

> To that extent, Thunderbird is thus kind-of entering the same boat SeaMonkey has been in already for the last couple of years

That would be my thought too.

[LoudNoise]

Not that my opinion would mean much here since I don't use SeaMonkey but I think they should take the ESR route. Rapid release is little more then a competitive response on Mozilla's part to what Google is doing (and misguided in my mind). Since SeaMonkey is not part of that race the project would benefit from largely ignoring it. SeaMonkey could add features once they had enough time to bake and become stable or backed out. The devs could also spend time making the Web Development stuff a replacement for NVU and maybe add features that would differentiate it from Firefox and Tbird.

[Andrew`]

Maybe SeaMonkey will pick up one or two Thunderbird users, worried about the change.

I have my own question: obviously SeaMonkey uses Gecko, but to what extent does it rely on Thunderbird? (Are there any SeaMonkey devs reading?)

For SeaMonkey, either ESR or rapid-release is fine for me. SeaMonkey doesn't move very fast (good thing IMO) so ESR would almost seem more appropriate.

[rsx11m]

obviously SeaMonkey uses Gecko, but to what extent does it rely on Thunderbird? (Are there any SeaMonkey devs reading?)

Phil Chee is frequently stopping by here and is a member of the SeaMonkey Council, and some people here are hanging out on IRC with them, thus there is some interaction. While SeaMonkey and Thunderbird maintain separate front-end code for user interface and some high-level functions, the backend code (MailNews Core = protocols and database implementations) and some features (Account Settings, Address Book) are shared. So far, both SM and TB developers contributed to that code.

[vazhavandan]

Maybe SeaMonkey will pick up one or two Thunderbird users, worried about the change.

That would happen only if they introduced wizards for creating mail accounts similar to TB's
TB has a much simplified user account creation for gmail and other popular email servers
Seamonkey has a wizard borrowed from Netscape LOL
I don't mean to demean Netscape but there is very little done to make things user friendly

[rsx11m]

That would happen only if they introduced wizards for creating mail accounts similar to TB's

Actually, that wizard is in its third iteration by now and has received some criticism since (though the current implementation has resolved quite a few issues raised with the first versions). Sure, it is great for many popular providers which follow a certain scheme for account setup and server-naming conventions, but frequently gets lost with specific scenarios requiring more complex setups. Sure, the old wizard which SeaMonkey relies on needs a lot of insider knowledge and you cannot set up certain features like encryption in the first step, so that certainly is asking for an overhaul as well, but not necessarily in the way Thunderbird has implemented it (obviously, it would serve as a good template for getting a SeaMonkey version of it started).

[rsx11m]

For SeaMonkey, either ESR or rapid-release is fine for me. SeaMonkey doesn't move very fast (good thing IMO) so ESR would almost seem more appropriate.

Given the recent incident with Gecko 16.0, I tend to agree that moving forward with a "classic" branch scheme would be preferable. Yes, that specific bug also was present in 10.0 ESR (and got fixed in 10.0.9), but was less visible compared to 16.0 which substantially exposed the vulnerability. In retrospect, such oilspill release were much less frequently necessary for the 10.0 ESR branch than for the regular rapid releases.

[Philip Chee]

As far as I know, SeaMonkey will (try) keep to the rapid release train. We currently don't have the resources to do rapid releases plus an ESR at the same time.

Phil

[rsx11m]

Thanks Phil. The idea wouldn't be rapid-release and ESR releases but rather either rapid-release or ESR-based releases (like Thunderbird decided to do for 17.0+), thus hopefully would be resource-neutral.

[Philip Chee]

Thanks Phil. The idea wouldn't be rapid-release and ESR releases but rather either rapid-release or ESR-based releases (like Thunderbird decided to do for 17.0+), thus hopefully would be resource-neutral.

I think Callek (Justin), our Release Engineer, is the one you should ask.

Phil

[LoudNoise]

I think that sticking with ESR would be resource positive since it allows SeaMonkey to make its own way and not be forced to follow the whims Firefox. Also, the theme folks would love you .

[Philip Chee]

I think that sticking with ESR would be resource positive since it allows SeaMonkey to make its own way and not be forced to follow the whims Firefox. Also, the theme folks would love you .

1. Jumping from ESR to ESR will need the same changes only 54 weeks of changes get crammed into a month or so as we scramble desperately to fix stuff. Much better to fix stuff as the release trains chug along.

Here is an example of what happens over a two week period:
https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2012-10-16#2.Next
Now multiply that by 26 and cram all that into a month or two.

2. Our themes change very slowly anyway irrespective of ESRs or not.

Phil

[rsx11m]

I think everybody here is aware of the pros and cons of branch-based vs. rapid-release approaches, and that's not necessarily the point why I was opening this thread for discussion. Apparent fact is that Thunderbird will revert to classic release branches with 17.0, and that's coming up soon. Meaning that they may relax work on MailNews issues and cram them into the 22.0/23.0/24.0 cycles (also depending on how big the vacuum left by departing paid developers will be and how quickly it can be filled up by volunteer contributors), thus SeaMonkey contributors may have to catch that work and fix things before they hit the release channel. That's not just a matter of release engineering but rather of policy (and again, personal resources in the end).

I'm not following the calendar development, but if they decide to follow Thunderbird in building from mozilla-esr17, then SeaMonkey would de-facto "own" the comm-release repository for the time being. We had this before when comm-2.0 and comm-miramar were separately used by either application only, and as I recall there were a few bug fixes on the MailNews side which didn't make it into the early SeaMonkey 2.1+ releases for that reason. Thus, keeping a common repository to build releases from would be beneficial from that perspective as well.

If all of this has been considered by the council already and I should understand "SeaMonkey will (try) keep to the rapid release train" as a decision not to change SeaMonkey's releases despite where Thunderbird is going, that's fine and let's see how this works out. Just as a precaution though, I may be backing up my mail more frequently...

[Philip Chee]

Well I do read tb-planning once in a while and the impression I get is that everyone there is wandering around in a fog. So your guess is as good as mine.

Phil