Why we need Gecko updates
axel.grude at gmail.com
Wed Dec 9 21:34:54 UTC 2015
> *Subject:* Re: Why we need Gecko updates
> *To:* Tb-planning
> *From: *R Kent James
> *Sent: *Wednesday, 09/12/2015 21:14:32 21:14 GMT ST +0000 [Week 49]
> On 12/9/2015 11:37 AM, Magnus Melin wrote:
>> I'd like to add to the above that forking m-c isn't likely as long as we could
>> still build Thunderbird from it. If building gets impossible then you'd have to go
>> from there.
>> Besides lacking security updates you'd also build on dead-end technology and nobody
>> really wants to work with that a few years down the line.
> I fully agree with this - up to a point. But the issue we face is this: MoCo is
> telling us that they do not want to spend any time on Thunderbird-related issues. If
> we take them at their word, then all of these requests we make to m-c for changes to
> support Thunderbird will no longer be accepted. In that case, m-c changes WILL break
> us. The option you are presenting is one that MoCo is telling us is not possible.
> As I see it, you are asking that we assume that MoCo will continue with the status
> quo of the last few years, that is that they will give minimum attention to
> Thunderbird, but they will still keep us building. What I keep hearing them say is
> that they want to stop doing this, because the tax on Firefox is too great. Then
> there is elephant in the room, that they are really hoping to convert large parts of
> Firefox away from C++, XUL, and XPCOM and toward the servo-based browser using Rust.
> I cannot see any reasonable chance of converting Thunderbird to Rust, or even
> wanting to.
So here is the thing, if we fork M-C at some stage before it gets unmaintainable, is
there a reasonable way of shrinking it to make it maintainable for the Thunderbird
team? Or can it simply be frozen?
> Looking forward, my crystal ball tells me this schedule:
> Thunderbird 46 - 52 (TB 52 ships around 2017-01): Largely continue the status quo
> (though I think it is time to have our own branch of m-c, or of a merged m-c/c-c, so
> that we are not broken all of the time, and we can merge m-c to our build enviroment
> in a controlled manner including a few of our own fixes).
sounds good to me
> (Thunderbird 52 builds from mozilla-esr52, or the equivalent combined repo using
> merged m-c/c-c, from 2017-01 through 2017-12.)
> Thunderbird 53 - 59: (TB 59 ships around 2017-09) Forked m-c, still using XUL and
> XPCOM, merging in security patches. No longer merging complete mozilla-central but
> only selected patches.
SO this is where it may get more(?) or less (?) work to keep in Sync? Obviously the
big difference here is that the merging is completely done from our side without any
support from the Fx dev team.
> Thunderbird 59 builds using security patches merged in from mozilla-esr59, from
> 2017-09 - 2018-08)
> Thunderbird 60+ Around 2018-08, mozilla-esr59 will EOL, and we will no long have any
> stable Mozilla repo to use as a basis for security patches. mozilla-esr66 will be
> too far from buildable with Thunderbird to be a usable base.
Which is fine if we fork M-C at an earlier stage and then start to own it ourselves.
Hence my question about splitting Gecko. Gecko could potentially be kept in sync for
longer (assuming Fx continues using that as browser engine) and the rest of (forked)
M-C could be frozen so that we can continue to push C-C forward. Completely ripping
out M-C is probably a no-go from all the work that would be necessary.
> Here is the problem: to have any reasonable chance of switching to an alternate
> platform, the time required is probably 2-3 years. If we follow the current status
> quo, but otherwise keeping to the assumptions above, somewhere in mid 2017, the pain
> to try to continue using m-c will become too great,
even assuming it is forked? If we no longer have to keep up with the whole of M-C and
own our own version? I think that's pretty much what Postbox does at the moment.
> but by then we will only have about one year left before any hope of keeping up with
> security patches is lost. If the project dies without security patches, then we are
> dead in 3 years.
> At some point we are going to have to make assumptions about the future, and start
> acting on it. The current assumption is "Mozilla is bluffing". I can't buy that. You
> are welcome to challenge any of my assumptions, but just hoping that this issue is
> going to go away seems to me to be wishful thinking.
How do we remove reliance on Mozilla's m-c, if not forking? A complete re-write?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning