After reading this whole long thread (though I daresay I've read some parts of it "diagonally") I learned in it that the official MoCo policy is that Firefox developers must NEVER spend time (or at least company time) on giving the least help to Thunderbird and SeaMonkey. This made me sad but didn't really surprise me.
I also noticed that some Firefox developers don't apply that directive to the letter and it made me think that all hope isn't left. To me, anything that can make work easier for everyone is a plus, and reducing friction is IMHO one important way of making work easier. If merging the repositories reduces duplication of work, so much the better. OTOH, if it requires special and costly hacks to make sure that Firefox, Thunderbird, Lightning, and, if it gets integrated too, ChatZilla (which is distributed as part of SeaMonkey, is written in XUL and JS, but lived in a separate hg reopsitory last time I looked) can all build correctly, then it should be avoided. I'm not competent enough to judge between these two possibilities. But as a QA peer for SeaMonkey, I have made it my policy (which doesn't depend on anyone else's decisions because I'm not paid for it) to help other projects' developers to the measure of my capacities. When I move a bug originally filed in SeaMonkey::General to someplace in MailNews Core, Toolkit or Core (or anywhere else but these are the most frequent non-Suite-specific Products for such bugs) I follow that bug for all its life, help debugging it if I can, and contribute to VERIFYing it on SeaMonkey when it's FIXED. To me this is simple courtesy (helping other people, e.g. Firefox people, who happen to have the same problems as I do) and it is also in my own interest (to check how bugs affecting SeaMonkey but originating in Core, Toolkit, etc., get fixed -- or don't, as the case may be. For this reason I will go on helping the MoCo developers of common code to the best of my abilities even if the reciprocal is in general not true. It has been asked if the SeaMonkey developers were committed to go on maintaining SeaMonkey even if and when c-c and m-c get merged, and SeaMonkey Council members have said yes. That was also the impression I had: we are committed to keeping SeaMonkey alive and up to date as long as we possibly can regardless of where its code lives, even though the people who maintain SeaMonkey are few, and they are all doing it in their spare time even though some of them (two, I think; maybe three) also have jobs at MoCo which, admittedly, probably teach them important stuff about the Mozilla (including SeaMonkey) code in general even when they're earning their daily bread working on Firefox. But the "don't care if you break comm-central" policy is not helping us, and the recent news about altogether scrapping full-fledged extensions, complete themes, and even XUL in general has caused us quite some trepidation. AFAIK, the current consensus is that we'll go on using the same Gecko and Tool kit code as Firefox as long as it remains humanly possible considering the kind of Suite we want to have. But we are not at all sure that it will remain possible even for two years, and we don't like the prospect at all. We'd prefer to have less forked code (including both "application code" and "build tools code") rather than more, but not at the price of losing what makes SeaMonkey stand out as "the best SeaMonkey we can make". Best regards, Tony. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
