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