Page MenuHomePhabricator

RfC: Standardized thumbnails sizes
Closed, DeclinedPublic

Description

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

Details

Reference
fl541

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

Qgil moved this task from Inbox to External on the Architecture board.Oct 1 2014, 7:12 AM
Qgil edited projects, added TechCom-RFC; removed Architecture.Oct 22 2014, 8:45 PM
tstarling set Security to None.
daniel reassigned this task from MarkTraceur to hashar.
daniel moved this task from Inbox to Backlog on the TechCom-RFC board.
daniel added a subscriber: daniel.
daniel changed the task status from Open to Stalled.Feb 27 2015, 11:49 PM

seems nobody is committed to this

hashar added a comment.EditedFeb 28 2015, 8:22 AM

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.

hashar removed hashar as the assignee of this task.Feb 28 2015, 8:24 AM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptMay 8 2016, 12:37 AM
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.

Legoktm reopened this task as Open.Dec 1 2017, 6:37 AM
Krinkle moved this task from Inbox to Doing on the Performance-Team board.Jan 16 2018, 2:38 PM
Krinkle claimed this task.Jan 18 2018, 9:20 AM
Krinkle moved this task from Doing to Blocked or Needs-CR 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.

Krinkle closed this task as Declined.Jan 18 2018, 4:32 PM

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