Thunderbird Discussions with Mozilla (was Marketing Module)

Joshua Cranmer 🐧 Pidgeot18 at
Thu Jan 8 22:07:47 UTC 2015

On 1/7/2015 4:18 PM, Kent James wrote:
> 4) Some sort of official statement from Mozilla about Thunderbird's 
> status within the organization. I'm not exactly sure what I am looking 
> for here, but I have a sense that Mozilla staff don't really know how 
> they should react to Thunderbird anymore. We are not looking for 
> Mozilla to fund our activities, but we do need some recognition from 
> Mozilla that Thunderbird is an ongoing, important project that needs 
> occasional interaction with different parts of Mozilla.
In my experience, the reactions of Firefox developers to Thunderbird 
range from "please also check to make sure that comm-central isn't 
affected" to "You're Thunderbird; fuck off." (To be fair, some of the 
people in the latter boat I suspect also have similar attitudes to 
add-on authors).

What I think (sadly) is needed is explicit statements on what level of 
support mozilla-central developers should expect to provide for 
comm-central. For example, I would propose the following:

A. If you're trying to ascertain if an interface, macro, class, etc. is 
used, and you're grepping through code using MXR or DXR, change the 
query from to If there's a use in comm-central, 
and the change isn't an easy mass-change (example of easy mass-changes 
include things like the PRInt32 -> int32_t et al rewrites), file a bug 
or otherwise notify comm-central developers about the changes.
B. If it's a mass change done by a script, please run the script on 
comm-central, or at least publish and make easy-to-run the script.
C. If a mozilla-central change breaks a mozilla-central test but only 
when run in Thunderbird, the appropriate mozilla-central developers 
should be prepared to help diagnose and potentially fix the failure.
D. High impact changes (e.g., changing load info semantics on channels) 
must be proactively announced in m.d.platform. Proactive means in at 
least enough time for affected consumers of relevant APIs to find and 
fix changes before the appropriate patches land on mozilla-central. It 
DOES NOT mean announcing them five days after landing.
E. In certain portions of the codebase (e.g., the build system), patches 
that knowingly break comm-central are unacceptable. The onus is on 
comm-central developers to watch for breaking changes, but backing 
patches out from mozilla-central because of comm-central bustage is a 
potential recourse if no other option is easily admitted.
F. If code in mozilla-central is needed by comm-central but otherwise 
unused by mozilla-central, and the mozilla-central developer wishes to 
cease maintenance of code, then the developer needs to alert 
comm-central developers to this fact and prepare the patches to import 
the code into comm-central, and to do this before removing code from 
mozilla-central. In turn, comm-central developers need to react in a 
timely manner to these requests.

These are the sorts of things that need hashing out--I don't like making 
it explicit, and I doubt Mozilla does either, but the ambiguity as to 
its level of support means that different people have different 
expectations of what is meant, and consequently you get several 
developers arguing that it's somebody else's problem.

Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

More information about the tb-planning mailing list