An umbrella task to track the various changes we may want to make to the mwoffliner logic specifically for the Android app.
Let's discuss these changes with Kiwix to determine how they could best be structured, with the goal of making them generally useful and upstreamable.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | Dbrant | T163706 [Spike] [4hrs] Investigate loading a random page from a zim file using an interceptor | |||
| Resolved | RHo | T166599 [EPIC] Create the user interface flow for readers to use offline content packs | |||
| Resolved | • Mholloway | T163714 Create a page content pack info client | |||
| Invalid | None | T172732 Create a production-ready zim content pack generation and upload service | |||
| Invalid | None | T172738 Update mwoffliner for WMF client-specific needs | |||
| Invalid | None | T172739 Treat audio separately from video | |||
| Invalid | None | T172764 Remove unnecessary/Kiwix-specific content massaging |
Agreed that a Wikimedia fork would only be desirable to the extent the WMF in-house clients have needs that are of no general interest upstream.
Please do not assume this for any feature, let us discuss this together before if possible.
We won't make any such assumptions! The only changes I've made in my personal fork are a couple of tweaks to get it working correctly in Jessie (including the RangeError fix I upstreamed), and I also patched in in some temporary, ad-hoc timing code so we could get a sense of the range of running times we're looking at (for discussions with ops). We'll definitely discuss planned changes with you and upstream them where they're useful!
By the way, the other change I needed to make to get things working correctly in Jessie was to remove the --strip option from the pngquant call here, as it's not available in the pngquant version in the official Debian Jessie repo and was throwing errors and causing png optimizing to fail. Would you like a PR for that? What's your general philosophy on distro/version compatibility?
Aside from tweaks for running on not-quite-cutting-edge software, there are also some restrictions on where we can pull software from for running in WMF production. It's much more restricted than Cloud VPS/Labs. I think, roughly speaking, software running in WMF prod must come from either the official Ubuntu/Debian repos (almost certainly Debian in this case, as we're phasing out Trusty) or from repos we maintain in-house, so a fork might be needed for that reason (even if identical to upstream or nearly so). (Speaking of which, it looks like openzim software development has moved to Github since this past April—is https://github.com/wikimedia/openzim deprecated?) But I'm not in ops and so I'm not well versed in the details on where we may pull software for running in production, so I'm not sure a fork is needed for this reason.
I really created this task as more of a placeholder for discussion of desired changes.