What happened to hiring an architect?

Benjamin Kerensa bkerensa at gmail.com
Wed Dec 21 07:33:19 UTC 2016

+1 to acting now

I think TB is dragging its feet and putting itself at risk when technical
choices need to be made very soon not just on direction of the codebase but
jnfrastructure (eventually Mozilla is going to end resources and I'd make
an informed bet that you have less than 18 months left)

On Dec 20, 2016 10:48 AM, "Ben Bucksch" <ben.bucksch at beonex.com> wrote:

> 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.
> Ben
> 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 want 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 of React instead of known
>> releases?
>> Really the only difference between Magnus' and my position is that he is
>> 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'.
>> :rkent
>> ------------------------------
>> tb-planning mailing list
>> tb-planning at mozilla.org
>> https://mail.mozilla.org/listinfo/tb-planning
> --
> Sent from my mobile phone. Please excuse the brevity.
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161220/c6873a06/attachment.html>

More information about the tb-planning mailing list