Proposal to start a new implementation of Thunderbird based on web technologies
Joshua Cranmer 🐧
pidgeot18 at gmail.com
Tue Apr 4 21:54:22 UTC 2017
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
>> 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.
Thunderbird and DXR developer
Source code archæologist
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning