What happened to hiring an architect?

Disaster Master disasterlistmanager at gmail.com
Tue Dec 20 14:46:08 UTC 2016

To borrow a recent phrase from Ben:

> Normally we don't do "me too", but:
> What rkent said. exactly that.


On 12/19/2016 6:02 PM, R Kent James <kent at caspia.com> wrote:
> 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

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

More information about the tb-planning mailing list