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

[Joshua Cranmer 🐧]

On 4/4/2017 3:05 PM, Ben Bucksch wrote:
> If you gradually rewrite, *then* you don't have a plan B. The 
> integration of new components into old codebase is hard. If the 
> rewrite fails, or does not finish in time (same thing), you are dead.

No. The plan B is that you *don't* hold new feature development hostage 
to rewrites. If the rewrite succeeds, great we can use it. But if it 
doesn't succeed, well, at least users get new features in some fashion 
anyways.
>
>> This is the sort of risk that concerns me deeply, and the best way to 
>> mitigate is to minimize the criticality of delivering any one 
>> individual feature.
>
> You're welcome to backport individual features of the new 
> implementation to the old Thunderbird.

With what manpower? Thunderbird has a critical problem: it's short of 
manpower, and it's been short of it for half a decade. Everything else 
is just a multiplier on the burden that this manpower shortage 
represents. We stand at a point now where we can rectify that situation 
and, to my eyes, you are proposing that what we should do is continue to 
deprive Thunderbird of resources. And proposing that it doesn't matter 
since Thunderbird can do what it wants anyways, but all initiative 
should come from Thunderbird, and Thunderbird shouldn't inconvenience 
your new project--which is *exactly* the kind of demeaning attitude that 
Mozilla has displayed over the past several years.

>> 3. I am not proposing to maintain the current APIs.
>
> How did that work out for JsMime? See what I mean?

Quite well, in fact. The problem with JSMime is that I lacked the time 
to bring it to fruition, and no one else was willing to pick it up.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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