What happened to hiring an architect?

Disaster Master disasterlistmanager at gmail.com
Fri Dec 16 15:24:27 UTC 2016


On 12/15/2016 7:02 PM, R Kent James <kent at caspia.com> wrote:
> Postbox's new release is on Gecko 7.0.1, which is now over 5 years old. I have not heard any great outcry about their security issues, and someone on this list (...cough..  BK...cough..ensa) keeps telling us what a great product that is, and how popular it is in Mozilla. So clearly forking Gecko is a CHOICE, and if people at Mozilla are using it then some people at Mozilla must not care that it is based on old Gecko, either.

This supports my feeling that the security risks are actually much
smaller for TB than they would be for, for example, Pale Moon.

> You don't like that choice, and neither do I, but it is clearly an option.

And using this as an example, if it was forked, say, in a years time,
then TB could theoretically be OK for a number of years after that, even
as many as 5 or more.

Which, as I said earlier, gives us considerably more time to stage
rewrites of the core components over time, rather than needing to do it
within a short window under the gun.

> And if we believe what we hear about aggressive plans out of Firefox, and how they want to separate from Thunderbird to reduce the pressure to accommodate our needs, then that is the path we are heading to.

Has anyone asked the Mozillians if they would at least be willing to
continue hosting the build system if/after we forked the necessary bits,
even if it was in a partitioned section of the build system that they no
longer needed to 'maintain'?

Or would it be 'easier' for TB devs to move forward with creating our
own build/dev infrastructure (preferably under the umbrella of TDF - I'm
really hoping this will become our new home), and just keep the pieces
tied to Mozilla in sync unless/until the time to fork comes?

I understand asking these questions is probably exposing just how huge
my level of technical ignorance is on the programming side of things.

> Heck we already do it on a file-by-file basis in some cases, moving things to comm-central. We're going to have to fork the addon directory fairly soon if they really remove support for XUL extensions, as my experience with Mozilla tells me we have about a year after they remove it in FF before we will have no choice in TB.
>
> But there is still great uncertainty. Will we be able to maintain parity with m-c for the next few years with an effort of one or two full-time people? Maybe, maybe not, my guess is not but it is only a guess. But even if "yes" the issue remains that there is a tremendous amount of work needed to modernize Thunderbird. And I still maintain that the important question is not "what is the architecture we should be moving to?" but "how are we going to attract or finance the developers needed for such an effort?" (which I have estimated is about 30 person-years of effort).
>
> I have my plans, which are 1) a user coop to greatly increase the conversion of Thunderbird users to paying donors, and 2) unconventional sources of new develops (my upcoming prison project, aka Caspia).
>
> What are other people's plans? Or is the plan to limp along for the foreseeable future to sustain a product that is pretty much already what our users want?

Why do you believe it is either/or? I honestly don't see your above as
choices, I see them as a viable, maybe even desirable (to take the
pressure off by having a well defined path rather than having these
questions keep coming up over and over).

Why can't the path be to simply engage your plans 1 and 2 above asap,
wait as long as is feasible before forking anything, when the time comes
where a decision to fork must be made, if it is still necessary
(situation hasn't progressed to the point where forking is no longer
necessary), fork and freeze the necessary parts (gecko, m/c(?),
whatever), making fixes when possible but otherwise leaving these pieces
as is, and just continue with plans 1 and 2, working towards rewriting
core components as resources are available.

Again, if certain parts become too great of a risk (ie, Gecko security
issues too difficult to fix), reduce HTML rendering capability as is
necessary to minimize/eliminate the risks.

Thanks again Kent for your patience in explaining these things, I hope
I'm not causing you too much pain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161216/5be6e8c7/attachment.html>


More information about the tb-planning mailing list