Likely timing of future Thunderbird Gecko builds
mkmelin+mozilla at iki.fi
Wed Apr 19 14:00:36 UTC 2017
On 19.4.2017 05:23, R Kent James wrote:
> On 4/18/2017 12:57 PM, Magnus Melin wrote:
>> There might be some more breakage around 57 when extension-only code can be
> "Some more breakage" as in all of our addons no longer work? What do you
> think we are going to do at that point? We have three choices: 1) stop
> supporting XUL addons, 2) convince Mozilla to NOT remove the code we need,
> or 3) start building from a mozilla-central branch (or compile-time code
> branches), as we have done in TB 38, TB 45, and TB 52 for the last two
> years. I don't see 1) or 2) as viable, so 3) WILL happen. I really don't
> understand why that is so controversial, to me it is just planning ahead for
> an inevitable future. Thunderbird did not die when we started building TB 38
> and TB 45 from mozilla branches, not will it end when we start building TB
> 57 and greater from a mozilla branch at the point when maintaining
> mozilla-central compatibility forces compromises we are not willing to make
> (like abandoning XUL addons).
It's hard to say how much work it will be for us to keep extensions working.
Not entirely trivial, but my assumption has been we'd fork that particular
aspect of the current code ("move current add-ons manager to comm-central").
It's not like the XUL overlaying is going away anytime soon internally, this
is just about the actual installation/provision procedure.
Just as context for people not closely involved: those branches you talk about
have been branches branched of from the ESR release branches. Branches to
which we have cherry-picked some changesets to mozilla-central code so that
they would land sooner instead of having to wait on the release train. What
you are talking about with a permanent branching from mozilla-central is
*totally* different. If you have a permanent fork as tip you can't
realistically expect to every get back in sync with trunk and you're therefore
left to die. You could compare it to a space shot with planned re-entry as
opposed to just going of for Jupiter with no plans to ever return. Yes, you
will run out of supplies.
Re add-ons: we want to allow the old-style add-ons since we that's a greater
benefit for us that being compatible with Chrome et al - but supporting
add-ons can't be done at all costs. If it turns out that we can't support the
old style ones that's really too bad, but it's no reason to sacrifice
Thunderbird core. Looking at this in a perspective, add-ons are very niche. We
only have around 10 add-ons that are are popular enough to have > 1% of user
share. Not representative to this groups for sure, but that means the very
vast majority of users would be happy without add-ons (lightning excluded).
> I don't believe that talk of how quickly Thunderbird will die when we
> branch, nor hope that we will muddle through somehow, are particularly helpful.
I'd like to understand why you think it's helpful then. Add-ons support apart,
what could you possibly win?
While I'm at it, let me just spell out what I'd imagine happens: after the
branch is EOL for mozilla-central, you could potentially back-port security
fixes for some months. After then all expectations could be way off - other
code the back-ported changes didn't include could have changed so nothing
applies, or if it applies, how it works could have changed behind your back.
You'd have a system where nobody could tell you anything because X or Y didn't
exist anymore or Z been invented yet. All this not even mentioning the
man-power wasted to back-port stuff, while it could be used elsewhere. Support
no expectations you could even try to port those.
More information about the tb-planning