Why we need Gecko updates

R Kent James kent at caspia.com
Sat Dec 12 20:58:10 UTC 2015

On 12/11/2015 7:16 PM, Joshua Cranmer 🐧 wrote:
> I'm imagining that we want each protocol to be available as a separate 
> npm package, and my thought is that they would leave in separate 
> repositories that are kept more-or-less in-sync with comm-central. How 
> I packaged JSMime was intended to follow that model, but since it's 
> built into a single file for comm-central, it makes moving changes 
> between the two versions painful. It's possible that my thought is a 
> distinctly worse development proposal, though. 

If we picture a world where we both receive upstream code regularly 
which we incorporate into our product, as well as maintain modules that 
we hope others will share from us, I think it would be better if we flip 
the model of where the canonical repository is. That is, we should keep 
things like jsmime as separately downloadable packages on github, and 
then have code in client.py (or something similar) that pulls specific 
version of upstream repositories into our code tree. We still need some 
mechanism to allow us to land Thunderbird-specific changes locally, if 
only for urgent changes, perhaps using a CANONICAL_UPSTREAM branch for 
updates, then merge into our default branch.

If someone wants to use jsmime (or other shared packages) outside of 
Thunderbird, they need some convenient way of specifying the changes 
that they need without having to understand all of the complexities of 
interacting with the Mozilla world, and any required changes in 
Thunderbird to support that. Github is the most common way this is done 
these days, and you see much Mozilla code migrating there already. Yes 
it makes our life like a little more difficult, but I think it would be 
great if we would learn to be more cooperative with other groups, and 
making jsmime and similar packages follow typical open source comment 
and pull-request patterns would help with that.

Plus if we ever start using packages like react in our own code, we are 
going to be forced to support this approach anyway.


More information about the tb-planning mailing list