Hi all,

As the Mozilla platform (together with Firefox) has moved trunk to Mercurial now, and 1.9.1 will be released off that, the SeaMonkey< and Thunderbird teams are looking to possibly do such a move as well before our next major releases, as we might want to base them on 1.9.1 instead of 1.9.0.x.

I wrote up a blog post titled "A Possible Way For Hosting SeaMonkey And Thunderbird In Mercurial" (<http://home.kairo.at/blog/2008-06/a_possible_way_for_hosting_seamonkey_and>) which describes how we could do this, using "the best of both worlds from Benjamin Smedberg's <http://wiki.mozilla.org/SeaMonkey/1.9.1_Repository_Options> wiki document. Basically we would be taking the directory structure from "option A" there (which perfectly fits us going XULRunner some time in the future) and still riding on the Mozilla build system like described in "option B" of that doc.

The core point of all this is that we want to share a repository between SeaMonkey and Thunderbird, because we quite often have changes that span all of mailnews/, mail/ and suite/ directories (e.g. a backend change in the former dir needs locale changes in both the latter ones), and we want those to be one single changeset or else our respective trees would probably change too often and easily. This is different for built-in extensions (like ChatZilla, venkman, DOMi or even Lightning), as even in integration code, there's rarely breakage on either side when we commit independently, so they can easily live in their own repositories.

My wiki description of how to get our currently still cvs-hosted source to build with mozilla-central at http://wiki.mozilla.org/SeaMonkey:hg-based_build is now free of any hacks to be done, with the exception of LDAP (directory/), which is one last point we need to solve.

Apart form that, https://bugzilla.mozilla.org/show_bug.cgi?id=437896 needs to fix make-makefile and I need to see how we build L10n, but everything else works pretty cleanly now in my local tree.

I'm trying to get Thunderbird and SeaMonkey decisionmakers to officially agree that we want to go that path in the future, so it makes sense to investigate further details, i.e. what state (with what history) to import, what timeframes we have and how the transition (period) will look like.

Additionally, we need to figure out what to do with directory/ - this discussion might need to involve Firefox/platform people, Mark Banner knows more about that and probably will write something up about that soon.

What's your opinion about that? Is this a way we can/should go? If yes, in what timeframe? How would you solve the transition? What problems do you see with that (if any)?

(Followup to .planning as it probably is of interest to more than one of the other groups)