<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
<br>
<div id="smartTemplate4-quoteHeader">
<blockquote type="cite" style="margin-bottom: -20px !important;
padding-bottom:20px !important;">
<div id="newHeaderAG1" style="font-size: x-small; padding:1em;
background-color:rgba(220,220,240,0.4); border-radius:3px;"> <b>Subject:</b>
Re: Why we need Gecko updates<br>
<b>To:</b> Tb-planning <br>
<b>From: </b>R Kent James<br>
<b>Sent: </b>Wednesday, 09/12/2015 21:14:32 21:14 GMT ST
+0000 [Week 49]<br>
</div>
</blockquote>
</div>
<blockquote class=" cite" id="mid_566899B8_8090306_caspia_com"
cite="mid:566899B8.8090306@caspia.com" type="cite">On 12/9/2015
11:37 AM, Magnus Melin wrote:
<br>
<blockquote class=" cite" id="Cite_9566030" type="cite">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.
<br>
<br>
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.
<br>
<br>
</blockquote>
<br>
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.
<br>
<br>
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.
<br>
</blockquote>
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?<br>
<br>
<blockquote class=" cite" id="mid_566899B8_8090306_caspia_com"
cite="mid:566899B8.8090306@caspia.com" type="cite">
<br>
Looking forward, my crystal ball tells me this schedule:
<br>
<br>
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). </blockquote>
sounds good to me<br>
<blockquote class=" cite" id="mid_566899B8_8090306_caspia_com"
cite="mid:566899B8.8090306@caspia.com" type="cite">(Thunderbird 52
builds from mozilla-esr52, or the equivalent combined repo using
merged m-c/c-c, from 2017-01 through 2017-12.)
<br>
<br>
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. </blockquote>
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.<br>
<blockquote class=" cite" id="mid_566899B8_8090306_caspia_com"
cite="mid:566899B8.8090306@caspia.com" type="cite">Thunderbird 59
builds using security patches merged in from mozilla-esr59, from
2017-09 - 2018-08)
<br>
<br>
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.
<br>
</blockquote>
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.<br>
<br>
<br>
<blockquote class=" cite" id="mid_566899B8_8090306_caspia_com"
cite="mid:566899B8.8090306@caspia.com" type="cite">
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, </blockquote>
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.<br>
<blockquote class=" cite" id="mid_566899B8_8090306_caspia_com"
cite="mid:566899B8.8090306@caspia.com" type="cite">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.
<br>
<br>
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.
<br>
</blockquote>
How do we remove reliance on Mozilla's m-c, if not forking? A
complete re-write?<br>
<br>
Axel<br>
</body>
</html>