<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 24/03/2017 17:04, Ben Bucksch wrote:<br>
<blockquote
cite="mid:56f75f14-d869-1ee4-9568-1abcd508a2a1@beonex.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<p>Summary:</p>
<ul>
<li>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.</li>
</ul>
</blockquote>
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.<br>
<br>
<br>
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).<br>
<br>
So, define an experiment which is limited in scope and goals, has
limited (but enough) resources, but is definitely an experiment. For
that experiment:<br>
<ul>
<li>Define the scope/goals clearly, e.g.</li>
<ul>
<li>Obtain knowledge of the most viable code base?</li>
<li>Is it likely to be able to support the performance we
require? (e.g. multi-threaded/process etc).</li>
<li>Will it be flexible enough that we can support all the
existing Thunderbird features & more?</li>
<li>Can the existing tests be re-used/easily ported?</li>
<li>How are L10n, Add-ons, profiles, etc... supported?</li>
<li>How long might it take to reimplement all of Thunderbird?<br>
</li>
<li>What is the minimum MVP we need to be able to answer the
scopes/goals?</li>
</ul>
<li>As this is an experiment, Thunderbird still continues
developing at roughly its current pace.</li>
<li>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).</li>
<li>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.</li>
</ul>
<br>
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".<br>
<br>
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.<br>
<br>
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.<br>
<br>
Mark.<br>
</body>
</html>