Page MenuHomePhabricator

RfC: Standardized thumbnails sizes
Closed, DeclinedPublic

Description

Task to follow the progress of the RfC Standardized thumbnail sizes.

Details

Reference
fl541
TitleReferenceAuthorSource BranchDest Branch
d/changelog: bump to 16.0.10repos/cloud/toolforge/jobs-cli!35dcarobump_to_16.0.10main
envvars-api: bump to 0.0.45-20240525210201-625cdfb7repos/cloud/toolforge/toolforge-deploy!285project_1317_bot_df3177307bed93c3f34e421e26c86e38bump_envvars-apimain
Clone the pinned file while creating a new cloned envrepos/data-engineering/conda-analytics!46stevemuneneclone_pinned_filemain
[envvars-cli] add messages to all responsesrepos/cloud/toolforge/envvars-cli!38raymond-ndibeadd_messages_to_all_responsemain
Auto-Manage Refine Iceberg tablesrepos/data-engineering/airflow-dags!677aquT356762_iceberg_table_managementmain
d/changelog: bump to 0.0.15repos/cloud/toolforge/builds-cli!63raymond-ndibebump_versionmain
[envvars-api] add messages to all responsesrepos/cloud/toolforge/envvars-api!25raymond-ndibeadd_messages_to_all_responsemain
Retry on 503 from ESrepos/search-platform/cirrus-streaming-updater!115pfischerretry-503main
Move items-not-found message into Dialog rather than notificationrepos/commtech/autosuggest-sitelink!51samwilsonitems-not-found-T356836main
Show 'already linked' message in Dialog rather than notificationrepos/commtech/autosuggest-sitelink!50samwilsonalready-linked-T356837main
[builds-cli] remove unused coderepos/cloud/toolforge/builds-cli!59raymond-ndibeminor_refactormain
d/changelog: bump to 0.0.14repos/cloud/toolforge/builds-cli!58raymond-ndibebump_to_0.0.14main
Allow overriding max. bulk request sizerepos/search-platform/cirrus-streaming-updater!112pfischeres-sink-configurationmain
Pin essential conda-analytics packagesrepos/data-engineering/conda-analytics!43stevemunenepin_essential_conda_analytics_packagesmain
Do not fail over leftover bytes during deserializationrepos/search-platform/cirrus-streaming-updater!111pfischerfix-es-writer-deserializationmain
use memory-optimized runnerrepos/mwbot-rs/rust-ci-pipeline!12mirrorktuse-memory-optimized-runnermain
jobs-api: bump to 0.0.269-20240315104203-49ed38c0repos/cloud/toolforge/toolforge-deploy!222project_1317_bot_df3177307bed93c3f34e421e26c86e38bump_jobs-apimain
jobs-api: bump to 0.0.266-20240307133255-36e022bcrepos/cloud/toolforge/toolforge-deploy!216project_1317_bot_df3177307bed93c3f34e421e26c86e38bump_jobs-apimain
jobs-api: add /openapi.json endpointrepos/cloud/toolforge/jobs-api!66aborreroarturo-3288-jobs-api-add-api-vmain
job: adjust max job name lengthrepos/cloud/toolforge/jobs-api!65aborreroarturo-4288-job-adjust-max-jobmain
Show related patches Customize query in GitLab

Event Timeline

flimport raised the priority of this task from to Medium.Sep 12 2014, 1:45 AM
flimport added a project: Architecture.
flimport set Reference to fl541.

hashar wrote on 2014-08-14 13:48:07 (UTC)

I just wrote the first draft, the thumbnail size should now be assigned/handled by the Multimedia and Operations teams.

qgil wrote on 2014-08-14 14:11:05 (UTC)

Ok, understood. https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes has your name as author (which is certainly true, but incomplete, and might confuse more people apart from me).

@MarkTraceur, do you know who should on this RfC?

marktraceur wrote on 2014-08-20 15:40:16 (UTC)

@Qgil it depends on what you want out of it. What are you trying to accomplish now?

@hashar where is your patch?

qgil wrote on 2014-08-20 16:24:04 (UTC)

I just want to know who is currently pushing for this RfC (if anybody): https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes

hashar wrote on 2014-08-21 14:57:07 (UTC)

@MarkTraceur by "first draft" I was referring to the RFC :-D

daniel reassigned this task from MarkTraceur to hashar.
daniel moved this task from P1: Define to Old on the TechCom-RFC board.
daniel subscribed.
daniel changed the task status from Open to Stalled.Feb 27 2015, 11:49 PM

seems nobody is committed to this

So don't assign it to me either? :-D

Re thinking thumbnails processing is in the hands of the Multimedia team. They conducted some changes already.

The RFC itself is merely to gather related informations at a central place since that topic been raised a few times before I wrote it.

MarkTraceur changed the task status from Stalled to Open.Dec 2 2016, 11:10 PM
MarkTraceur lowered the priority of this task from Medium to Low.
MarkTraceur moved this task from Untriaged to Tracking on the Multimedia board.

Again, I don't think this should be blocked on Multimedia, since we don't have much to say about media storage/thumbnailing processes these days. If Performance-Team or others have ideas, they should move forward with them without necessarily waiting on us.

On the other hand, this may be undesired or obviated per more recent discussions.

Krinkle moved this task from Doing (old) to Blocked (old) on the Performance-Team board.
Krinkle added subscribers: Gilles, fgiunchedi, Krinkle.

@fgiunchedi @Gilles If I recall correctly, this proposal mainly came from an operational concern regarding Swift storage use for thumbnails. Concern being that we're currently allowing any arbitrary thumbnail size to be generated, which are then indefinitely stored in Swift.

Removing support for arbitrary sizes from MediaWiki (or made inaccessible via Varnish or Swift-proxy), has impact and compatibility complexity that has thus-far stalled the task without a viable outcome.

I'm curious if this task is obsolete or whether it's worth reviving. Specifically, because we now use Thumbor for generating thumbnails. Speaking with @Gilles, I get the impression that we're planning to instead ensure we only store the subset of common sizes in Swift, but keep supporting requesting of other sizes, by letting them always pass through for on-demand generating from Thumbor. And given Varnish in front of it all, we still cache outliers that happen to be popular.

@fgiunchedi @Gilles If I recall correctly, this proposal mainly came from an operational concern regarding Swift storage use for thumbnails. Concern being that we're currently allowing any arbitrary thumbnail size to be generated, which are then indefinitely stored in Swift.

Removing support for arbitrary sizes from MediaWiki (or made inaccessible via Varnish or Swift-proxy), has impact and compatibility complexity that has thus-far stalled the task without a viable outcome.

I'm curious if this task is obsolete or whether it's worth reviving. Specifically, because we now use Thumbor for generating thumbnails. Speaking with @Gilles, I get the impression that we're planning to instead ensure we only store the subset of common sizes in Swift, but keep supporting requesting of other sizes, by letting them always pass through for on-demand generating from Thumbor. And given Varnish in front of it all, we still cache outliers that happen to be popular.

That's correct, mw prerenders certain thumbnail sizes and we've been cleaning up swift as part of a goal (https://wikitech.wikimedia.org/wiki/Swift/Thumbnails_Cleanup). With my swift hat on I believe the current situation is good enough, IOW the non-prerendered sizes were negligible in terms of requests and space. Some of the bigger sizes were prerendered but rarely requested, so we've stopped prerendering those altogether.

Thanks! For any other work relating to this, we'll file new tasks, but closing this for now.