Proposal to start a new implementation of Thunderbird based on web technologies
Mark Banner
mbanner at mozilla.com
Wed Apr 5 08:42:33 UTC 2017
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>
More information about the tb-planning
mailing list