Why we need Gecko updates

Magnus Melin mkmelin+mozilla at iki.fi
Wed Dec 9 22:22:00 UTC 2015

On 09.12.2015 23:14, R Kent James wrote:
> 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 

There's a difference between stopping to give the kind of support 
currently provided and outright refusing to take patches that would keep 
us building. A vast majority of these bugs requiring m-c changes has 
been due to the m-c/c-c split and not "code" changes. With the split 
gone, they should be quite few.

> 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.

Whatever happens behind the scenes, Firefox has the desire to do the 
front-end using HTML/JavaScript. That would be a fine solution for 
Thunderbird too, and likely it's the only good long-term solution for us.

> 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, 

As I see it the only platform reasonable switchable to is doing things 
in HTML/JavaScript. Now, this should be inline with Firefox's desires, 
so in that regard there's a reasonable expectation we could run in the 
same kind of app shell eventually.

> somewhere in mid 2017, the pain to try to continue using m-c will 
> become too great, 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.
It's probably a good assumption that moving code to the web platform 
would be more robust. At the time things have been moved over the 
question of what kind of app shell to run it on should be decided based 
on what's available then. At the moment we can't really tell.

I don't think it's a question of "Mozilla is bluffing" or not, it's just 
a lack of resources to do the transition which is years of work.


More information about the tb-planning mailing list