Why we need Gecko updates
antoine.mechelynck at gmail.com
Sun Dec 13 10:04:54 UTC 2015
On Sat, Dec 12, 2015 at 9:58 PM, R Kent James <kent at caspia.com> wrote:
> 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.
In fact, we (Thunderbird and SeaMonkey) are already doing this for
part of our code: specific mail, mailnews and suite code lives in
comm-central, onto whose clones client.py grafts clones of
mozilla-central, the LDAP SDK, ChatZilla and DOMi, each of which has a
separate Mercurial repository with its own specific code. To keep
things simple for client.py, I would recommend Mercurial repositories
in preference to git repositories for anything we want to outsource
the same way, and that would mean "not github", but we could put
anything not already found on hg.m.o. on e.g. BitBucket, your concept
wouldn't need to change.
> 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.
(in view of my comment to the previous para.) s/Github is the most
common way/BitBucket is a common way/. IMHO adding appropriate
Mercurial tags for anyone (including comm-aurora, comm-beta and
comm-release) not willing to use the repository tip wouldn't be a big
> 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