Thunderbird Discussions with Mozilla (was Marketing Module)
Joshua Cranmer 🐧
Pidgeot18 at gmail.com
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
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 http://dxr.mozilla.org/mozilla-central to
http://dxr.mozilla.org/comm-central. 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.
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning