Thunderbird and mandatory Rust in m-c

[Henri Sivonen]

In discussion with Debian developers about the impact of Rust becoming
a mandatory build requirement for Firefox, the topic of Thunderbird
came up.

Has there been any follow-up to
https://marksurman.commons.ca/2016/04/25/firefox-and-thunderbird-a-fork-in-the-road/
and https://groups.google.com/d/msg/tb-planning/6TGQYl2pfZ0/HQGpoHHXDAAJ
?

Does Thunderbird expect to be a consumer of m-c trunk after 52 ESR?

(If yes, then it seems that the answer to the Rust topic is that
Thunderbird will pick up a mandatory Rust dependency, too, in the
future.

Note: AFAIK, it hasn't been decided when Rust will become a mandatory
build requirement for Firefox. However, looking at what's being worked
on, it seems inevitable that Rust will become a mandatory requirement
at some point in not too distant future. For example, the Rust stuff
I'm working on, replacing uconv with encoding_rs, doesn't make sense a
build-time option. It seems to me that there are enough reasons not to
require Rust for 52 ESR, but I'm not aware of an actual decision to
that effect, either. That's just my working assumption considering the
obvious pressures not to make an ESR the first release requiring Rust
to build.)

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[R Kent James]

On 8/25/2016 1:38 AM, Henri Sivonen wrote:
> Does Thunderbird expect to be a consumer of m-c trunk after 52 ESR?

TL;DR Yes.

You brought this up mostly in the context of Rust, but that is only one
of many issues. Recently, MoFo offered to provide a consultant to advise
Thunderbird on possible alternative platforms to migrate away from m-c.
Ultimately I advised against that, and this is what I wrote:

"I have enough experience myself in this that I can give a SWAG estimate
of the time it would take to convert the existing Thunderbird C++
codebase into JS as being about 10 person-years of effort, or $2,000,000
at Mozilla payscales. That is only one step of a complex conversion
(from C++ XPCOM to JS XPCOM). Then there is the XUL conversion of the UI
to something else, and migration of the XPCOM code to some other
platform, with accompanying infrastructure changes. Maintaining SWAG
standards, let's say 30 person-years of effort, or $6,000,000 at Mozilla
payscales.

"The harsh reality is that is not going to happen without major
innovation in the funding or staffing methods of Thunderbird. Trying to
imagine migrating the Thunderbird code to another platform is just a
pipe dream without accompanying funding or staffing innovations. So the
question of the proper platform is not really the critical issue going
forward.

"So where does that leave us? For now, Thunderbird is largely in
maintenance mode. We've actually become pretty good at that, though.
We're in a stronger position code-wise for our next major release than
we were this time last cycle, thanks to the efforts of several people
who are amazingly devoted to keeping up with mozilla-central driven
problems. A year ago I thought that at this point we would be barely
keeping up with mozilla-central changes, and ready to abandon
mozilla-central sync. But we are doing much better than that.

"So what that means is that for the foreseeable future, barring any
major funding or staffing innovations, Thunderbird is going to remain a
C++, XUL and XPCOM-based application. We will use what resources and
assistance that we can muster to migrate our code base to follow
whatever direction Firefox goes. We would hope that the platform folks
would be willing to accommodate minor hooks in the platform to allow us
to continue to do that, but we understand that they are free to make
breaking changes, and we have to adapt. If Firefox itself ever
successfully migrates away from XUL and XPCOM, yes that will create big
issues for us. But so far those who bet on that happening sooner have
lost big money, and it is quite probable that we could follow Firefox in
any case."

Thunderbird as a project is not very good at making or stating
decisions, but the above statements I believe largely reflect the
current thinking of Thunderbird leadership.

:rkent

[R Kent James]

On 8/25/2016 1:38 AM, Henri Sivonen wrote:

> Does Thunderbird expect to be a consumer of m-c trunk after 52 ESR?

[Philip Chee]

On 26/08/2016 00:33, R Kent James wrote:

> "So what that means is that for the foreseeable future, barring any
> major funding or staffing innovations, Thunderbird is going to remain a
> C++, XUL and XPCOM-based application. We will use what resources and
> assistance that we can muster to migrate our code base to follow
> whatever direction Firefox goes. We would hope that the platform folks
> would be willing to accommodate minor hooks in the platform to allow us
> to continue to do that, but we understand that they are free to make
> breaking changes, and we have to adapt. If Firefox itself ever
> successfully migrates away from XUL and XPCOM, yes that will create big
> issues for us. But so far those who bet on that happening sooner have
> lost big money, and it is quite probable that we could follow Firefox in
> any case."

Can't we just fork XUL and XPCOM? We don't need to do any development of
XUL itself so we can just freeze the feature set and put it into
maintenance mode. XPCOM may be a bit more problematic.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Henri Sivonen]

On Thu, Aug 25, 2016 at 7:33 PM, R Kent James <ke...@caspia.com> wrote:
> On 8/25/2016 1:38 AM, Henri Sivonen wrote:
>> Does Thunderbird expect to be a consumer of m-c trunk after 52 ESR?
>
> TL;DR Yes.

Thanks. I take this to mean that Thunderbird will inherit Firefox's
eventual Rust dependency for Linux distro purposes.

[R Kent James]

On 8/29/2016 3:38 AM, Philip Chee wrote:
> Can't we just fork XUL and XPCOM? We don't need to do any development of
> XUL itself so we can just freeze the feature set and put it into
> maintenance mode. XPCOM may be a bit more problematic.

In my crystal ball about the future of c-c development (which may not
agree with majority opinion among c-c developers) there will come a
time, perhaps relatively soon (originally predicted at gecko 53) where
c-c sync to m-c will be untenable in the short run, but still manageable
at release. So in that prediction, m-c usage in TB and SM builds will
freeze to a known-good revision for awhile, then that known-good will be
brought into sync with m-c close to release time.

The next phase is what you say, when m-c sync is abandoned forever, and
c-c developers take responsibility for a fork of m-c. My guess is that
fork is viable for about a single release cycle, but it is possible that
a forked m-c could could be maintained for much longer. Hard to say.

:rkent

[Jörg Knobloch]

On 30/08/2016 18:17, R Kent James wrote:
> So in that prediction, m-c usage in TB and SM builds will
> freeze to a known-good revision for awhile, then that known-good will be
> brought into sync with m-c close to release time.

Are you saying that we will then fix all bustage accumulated during 7*6
= 42 weeks in a few days? That's just totally unrealistic with currently
about 1-3 bustages per week(!!). Also, the idea of "*continuous*
integration" is to feed problems back to M-C as they occur, see for
example bug 1294500 or bug 1293759. If we complain about M-C changes
weeks later, we stand zero chance to get problems fixed. IMHO it's
either continuous integration or fork *and* forget about ever catching
up. Anything else is just wishful thinking (no offense intended).

Jörg.

[R Kent James]

See "which may not agree with majority opinion among c-c developers"

:rkent