What happened to hiring an architect?

Ben Bucksch ben.bucksch at beonex.com
Tue Dec 20 18:48:22 UTC 2016

Re 1)

No company "chose" to fork Gecko.

Those who did that "choice" usually did it without realizing what they did, and most simply slipped into it by accident by not updating often enough. And many bitterly regret it now. I have at least 3 client companies with applications in a similar situation. Most of them are in an unworkable situation. I should know, because I'm often hired exactly to clean up these bad decisions.

I don't want Thunderbird to make the same fatal mistake. Slipping into it is one thing. Running into it consciously is just inexcusable. 

As magnus said, it's a "choice" that effectively means abandoning the product. I hope nobody wants that for Thunderbird.

Please stop posting "fork gecko" as choice. It's a straw man. It's the "kill thunderbird" choice.
(And kill its users at the same time, because they'll get hacked by worms and loose control over their computer. It's actually worse than just closing the thunderbird project. Even one such home is competently unacceptable. And we'd have dozens.)


Why am i insisting on this, you asked? We might not have another choice, you said? 

I'm saying: we need to accept that fact that foregoing gecko is not an option. Unmarrying thunderbird doesn't work either. So, that leaves only one choice: Write a new client. Yes, that will take 1-3 years. That's why we need to start now. Once gecko is not usable by thunderbird anymore, it will be to late to start. It will be game over. Accept that, and act accordingly. That's my point. 


Am 20. Dezember 2016 00:02:22 MEZ, schrieb R Kent James <kent at caspia.com>:
>On 12/19/2016 2:34 PM, Ben Bucksch wrote:
>> Normally we don't do "me too", but given that rkent is actually
>> seriously arguing it: 
>I'm not arguing for it. What I am saying is:
>1) Forking or freezing Gecko is a choice that others have made
>differently from us, so saying it is not a choice is unhelpful.
>2) We do not want to fork Gecko for a variety of reasons.
>3) If we believe what the Firefox folks are saying, then it is going to
>be increasingly difficult to follow on our current path of compiling
>Thunderbird as a variant of Firefox. At some point in the future,
>forking will be our only choice. Since that is not a choice that we
>to be forced to make, then we need to be actively moving away from
>compiling as a binary variant of Firefox.
>What I /have/ argued for in the past is having the check-in source of
>Thunderbird in comm-central be based on a "last known good" revision of
>m-central, or even on known releases of m-c, with someone actively
>managing the last know good revision, and working on patches to allow
>that last known revision to advance. That is how every other project
>with an upstream code source works, and I don't understand why this is
>considered such a radical proposal here. If we start using React, is
>someone going to demand that we build using nightly developer updates
>React instead of known releases?
>Really the only difference between Magnus' and my position is that he
>more optimistic than I am about how difficult it is going to be to
>continue build on the Firefox code base. How about you, BenB? Are you
>optimistic? I'm guessing not, so I would guess you are closer to my
>position than Magnus'.
>tb-planning mailing list
>tb-planning at mozilla.org

Sent from my mobile phone. Please excuse the brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161220/e95cfee1/attachment.html>

More information about the tb-planning mailing list