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
