<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/15/2016 7:02 PM, R Kent James
<a class="moz-txt-link-rfc2396E" href="mailto:kent@caspia.com"><kent@caspia.com></a> wrote:
</div>
<blockquote
cite="mid:12b6c4eb-e0a5-b693-cbc5-a0dff2de72ba@caspia.com"
type="cite">
<pre wrap="">Postbox's new release is on Gecko 7.0.1, which is now over 5 years old. I have not heard any great outcry about their security issues, and someone on this list (...cough.. BK...cough..ensa) keeps telling us what a great product that is, and how popular it is in Mozilla. So clearly forking Gecko is a CHOICE, and if people at Mozilla are using it then some people at Mozilla must not care that it is based on old Gecko, either.</pre>
</blockquote>
<br>
This supports my feeling that the security risks are actually much
smaller for TB than they would be for, for example, Pale Moon.<br>
<br>
<blockquote
cite="mid:12b6c4eb-e0a5-b693-cbc5-a0dff2de72ba@caspia.com"
type="cite">
<pre wrap="">You don't like that choice, and neither do I, but it is clearly an option.</pre>
</blockquote>
<br>
And using this as an example, if it was forked, say, in a years
time, then TB could theoretically be OK for a number of years after
that, even as many as 5 or more.<br>
<br>
Which, as I said earlier, gives us considerably more time to stage
rewrites of the core components over time, rather than needing to do
it within a short window under the gun.<br>
<br>
<blockquote
cite="mid:12b6c4eb-e0a5-b693-cbc5-a0dff2de72ba@caspia.com"
type="cite">
<pre wrap="">And if we believe what we hear about aggressive plans out of Firefox, and how they want to separate from Thunderbird to reduce the pressure to accommodate our needs, then that is the path we are heading to.</pre>
</blockquote>
<br>
Has anyone asked the Mozillians if they would at least be willing to
continue hosting the build system if/after we forked the necessary
bits, even if it was in a partitioned section of the build system
that they no longer needed to 'maintain'?<br>
<br>
Or would it be 'easier' for TB devs to move forward with creating
our own build/dev infrastructure (preferably under the umbrella of
TDF - I'm really hoping this will become our new home), and just
keep the pieces tied to Mozilla in sync unless/until the time to
fork comes?<br>
<br>
I understand asking these questions is probably exposing just how
huge my level of technical ignorance is on the programming side of
things.<br>
<br>
<blockquote
cite="mid:12b6c4eb-e0a5-b693-cbc5-a0dff2de72ba@caspia.com"
type="cite">
<pre wrap="">Heck we already do it on a file-by-file basis in some cases, moving things to comm-central. We're going to have to fork the addon directory fairly soon if they really remove support for XUL extensions, as my experience with Mozilla tells me we have about a year after they remove it in FF before we will have no choice in TB.
But there is still great uncertainty. Will we be able to maintain parity with m-c for the next few years with an effort of one or two full-time people? Maybe, maybe not, my guess is not but it is only a guess. But even if "yes" the issue remains that there is a tremendous amount of work needed to modernize Thunderbird. And I still maintain that the important question is not "what is the architecture we should be moving to?" but "how are we going to attract or finance the developers needed for such an effort?" (which I have estimated is about 30 person-years of effort).
I have my plans, which are 1) a user coop to greatly increase the conversion of Thunderbird users to paying donors, and 2) unconventional sources of new develops (my upcoming prison project, aka Caspia).
What are other people's plans? Or is the plan to limp along for the foreseeable future to sustain a product that is pretty much already what our users want?
</pre>
</blockquote>
<br>
Why do you believe it is either/or? I honestly don't see your above
as choices, I see them as a viable, maybe even desirable (to take
the pressure off by having a well defined path rather than having
these questions keep coming up over and over).<br>
<br>
Why can't the path be to simply engage your plans 1 and 2 above
asap, wait as long as is feasible before forking anything, when the
time comes where a decision to fork must be made, if it is still
necessary (situation hasn't progressed to the point where forking is
no longer necessary), fork and freeze the necessary parts (gecko,
m/c(?), whatever), making fixes when possible but otherwise leaving
these pieces as is, and just continue with plans 1 and 2, working
towards rewriting core components as resources are available.<br>
<br>
Again, if certain parts become too great of a risk (ie, Gecko
security issues too difficult to fix), reduce HTML rendering
capability as is necessary to minimize/eliminate the risks.<br>
<br>
Thanks again Kent for your patience in explaining these things, I
hope I'm not causing you too much pain.<br>
</body>
</html>