[meta] Merge graphics to m-c

RESOLVED FIXED in mozilla54

Status

()

Core
Graphics: WebRender
P3
normal
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: kats, Assigned: kats)

Tracking

({meta})

Other Branch
mozilla54
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

We want to get the stuff in the graphics branch merged to m-c. I started a couple of discussion threads to hammer out the details. See [1] and [2]. This is a metabug to track the initial merge and all the prerequisites thereof.

[1] https://groups.google.com/d/msg/mozilla.dev.tech.gfx/Foxlm-c-Md8/y6khtK1CCwAJ
[2] https://groups.google.com/d/msg/mozilla.dev.tree-management/C3FMS39JzOE/elQMFbCrBwAJ
Keywords: meta
Summary: Merge graphics to m-c → [meta] Merge graphics to m-c
Depends on: 1335197
Depends on: 1335525
Depends on: 1335748
Depends on: 1336549
Depends on: 1336820
No longer depends on: 1335197
Depends on: 1337050
OK, so the bulk of the file changes on tip of the graphics repo are now in mozilla-central. A gzip bundle of those changesets (bafbb19be9a4::12c02bf624c4) is 2,514,305 bytes. That includes WebRender and a few Rust dependencies. Not bad.

A diff of central (12c02bf624c4) against graphics (c3195fb2f038) is only a few hundred KB (most of that in gfx/layers/wr and gfx/webrender_bindings). However, when I go to merge graphics into central, that pulls in ~380 changesets and the gzipped bundle comes out to ~5.5MB. Included in that bundle is a copy of freetype (~2.5 MB) and a handful of other packages in third_party/rust that have since been deleted on the tip of the graphics repo.

Yes, ~5.5MB may seem small. But in this case it is pure, avoidable waste. I strongly prefer to not introduce this bloat.

I recommend rewriting the history of the graphics repo to drop all changes to third_party/rust. We can then merge that result in. Of course, this would change commit/changeset SHA-1s. We'd likely "reset" the graphics repo then push the rewritten history. Anyone who has cloned would need to strip changesets or reset refs.
(In reply to Gregory Szorc [:gps] (disappearing for a month after 2017-02-10) from comment #1)
> Yes, ~5.5MB may seem small. But in this case it is pure, avoidable waste. I
> strongly prefer to not introduce this bloat.
> 
> I recommend rewriting the history of the graphics repo to drop all changes
> to third_party/rust. We can then merge that result in. Of course, this would
> change commit/changeset SHA-1s. We'd likely "reset" the graphics repo then
> push the rewritten history. Anyone who has cloned would need to strip
> changesets or reset refs.

I don't have any objections to doing this. We might lose some information (links in bugs that are no longer valid, etc.) and buildability (intermediate commits with the files stripped won't build) but it's not a big deal.
Just an update: gps is still working on a way to strip out partial history from the graphics branch. The first attempt produced incorrect results, because the merges from m-c -> graphics in the history are hard to deal with (they reintroduce files that are being stripped out, and so lead to unexpected results). I suspect just stripping the third_party/rust/servo-freetype-sys folder will produce better results and a good chunk of the size win. If there are other similar "large" crates that are no longer in the graphics branch tip they could also be stripped, but I think freetype was the largest.
Depends on: 1338220
No longer depends on: 1338220
I talked to gps today and he said he unfortunately won't get around to doing this today, and that we should probably just merge the graphics branch without rewriting the history. The merge has now landed, thanks to KWierso for pushing it to get around the servo/ webhook.

https://hg.mozilla.org/mozilla-central/rev/a288fe35e494cec3620717eab66eaff6f68a6369
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
You need to log in before you can comment on or make changes to this bug.