<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">Am 14.02.2018 um 12:39 schrieb Henri
Sivonen:<br>
</div>
<blockquote type="cite"
cite="mid:CAJQvAudPUvuVREjjQE-eqKjOQ7OyhJUic+P=4=VzgAsHB_VPqw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_extra"><br>
<div>I think the ideas of a greenfield rewrite of everything
at once under the Thunderbird brand are a recipe for the
death of the Thunderbird that has the users. I think
Thunderbird would be better served by realistic plans for
a series of piece-wise rewrites that keep the product
shippable at all times from the repo of record.<br>
</div>
<div> </div>
<br>
-- <br>
<div class="gmail_signature"
data-smartmail="gmail_signature">Henri Sivonen<br>
<a href="mailto:hsivonen@hsivonen.fi" target="_blank"
moz-do-not-send="true">hsivonen@hsivonen.fi</a><br>
<a href="https://hsivonen.fi/" target="_blank"
moz-do-not-send="true">https://hsivonen.fi/</a></div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<br>
<br>
I'd like to quote the reasons Ben B has given in the Wiki and in an
E-Mail message from 1/30/18 (see below) - <br>
<br>
I myself am not a coding expert, but:<br>
so far, I haven't noticed that anybody has proven wrong the
statement below (or even tried to)<br>
<br>
So, let's suppose the statement below is right - should this
"minimal viable product"-approach not be given a try ?? <br>
Such as, for instance: hire 2 developers, with the perspective
that in 1 year this "minimal viable product" should be up and
running. <br>
<br>
Roger<br>
<br>
P.S.: no, I am not paid by anybody to promote these ideas - actually
I don't even know BenB at all. <br>
<br>
<br>
<br>
<b>quotes from BenB:</b><br>
<a class="moz-txt-link-freetext"
href="https://wiki.mozilla.org/Thunderbird/NextGeneration">https://wiki.mozilla.org/Thunderbird/NextGeneration</a><br>
<a class="moz-txt-link-freetext"
href="https://wiki.mozilla.org/Thunderbird/NextGeneration/Motivation">https://wiki.mozilla.org/Thunderbird/NextGeneration/Motivation</a><br>
<br>
<br>
"This means that large parts of the codebase have to be rewritten
anyway, in the mid-term to near future. Of course, the changes in
Gecko are gradual, but eventually, the technology will go away, so
the overall work is there nonetheless.<br>
<br>
Given that XPCOM is the very technology that creates the API between
the modules, is hard to replace step by step. I think we would spent
as much time integrating the new modules with the old code as we
would take writing the module in the first place, which means the
overall effort increases at least 2-fold, by trying to do it step by
step. <i><b>Other negative effects add another 2-fold factor, so
that it eventually takes 4 times as long to operate "on the open
heart" than using the "minimal viable product" approach.</b></i>
Worse, the new component would have to adhere to old and unfortunate
design patterns that emerged between components. "<br>
<br>
<br>
<b>in his E-Mail from 30. January BenB wrote:</b><br>
<br>
"Motion <br>
(...)<br>
<br>
1) We will continue to maintain Thunderbird based on Gecko on the
current level of effort, as long as it is feasible.<br>
2) We will create a second, parallel team that will implement a
replacement of Thunderbird, based on JavaScript and HTML, running as
a desktop application. We will seek funding and hire developers for
this effort. We will first try to create a "minimum viable product"
with a good code design and solid framework, then gradually build
out features to match Thunderbird closer.<br>
3) Where feasible, the first team working on the old Thunderbird
will backport selected components, for example a new address book,
from the new implementation to the old Thunderbird based on Gecko.<br>
<br>
The goal is to have an application with a clean code design,
framework and APIs that's a joy to work on and with. One UI should
imitate current Thunderbird in its design and workflow as much as
possible, but there may be another mobile app UI for the young
generation. <br>
<br>
(...)<br>
Large projects are best done with the MVP "minimum viable product"
approach. Start with the smallest product that has some use (e.g.
first only read email, then write email, then add local storage,
etc.), and gradually gain users as you expand feature surface. 20%
of the features gains 80% of the users. Allow users to switch to the
new product voluntarily, instead of forcing the new modules on
them."<br>
<br>
<br>
</body>
</html>