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.
:rkent
More information about the tb-planning
mailing list