Proposal to start a new implementation of Thunderbird based on web technologies

[Mark Banner]

On 24/03/2017 17:04, Ben Bucksch wrote:
>
> Summary:
>
>   * While we implement the new version of Thunderbird, the old
>     codebase based on Gecko will be maintained until the rewrite is
>     ready to replace the old one.
>
I've been reading your original proposal as "Start a new fresh email 
client on a new code base from scratch, eventually swap users over to 
that new code base". You now seem to be saying "Start a new fresh 
client, but integrate parts of it back to Thunderbird". Is that correct? 
If not can you please clarify.


Starting a client from scratch does have a huge amount of risk, but that 
is not to say we shouldn't. What I would suggest is to start in a 
different manner, with some experimentation (similar to what Servo did 
originally).

So, define an experiment which is limited in scope and goals, has 
limited (but enough) resources, but is definitely an experiment. For 
that experiment:

  * Define the scope/goals clearly, e.g.
      o Obtain knowledge of the most viable code base?
      o Is it likely to be able to support the performance we require?
        (e.g. multi-threaded/process etc).
      o Will it be flexible enough that we can support all the existing
        Thunderbird features & more?
      o Can the existing tests be re-used/easily ported?
      o How are L10n, Add-ons, profiles, etc... supported?
      o How long might it take to reimplement all of Thunderbird?
      o What is the minimum MVP we need to be able to answer the
        scopes/goals?
  * As this is an experiment, Thunderbird still continues developing at
    roughly its current pace.
  * The experiment is reviewed regularly and at some stage all the goals
    are answered or are impractical to be answer (e.g. would take too long).
  * There should then be enough known about the expected future code
    base that a decision could be made for how compatible is the
    technology - should we migrate the existing code base/continue
    fresh/continue fresh but with porting parts of the existing code base.


This could be seen as "let's delay the decision", which in part it is, 
but I think it would give a much better basis on which to make a 
decision than what seems to be "let's stop work, start something new, 
currently undefined and hopefully switch to it later".

The 'trick' will be in correctly forming the scope to get enough 
top-level questions answered, but not going into too much detail and 
never getting answers.

The advantage is that this will help inform a clearer path and eliminate 
some of the risk up-front. There will still be lots of risk, but 
hopefully it'll be a better size than the current proposal.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20170405/3d3ba963/attachment-0001.html>