Wikitech-l August 2014

wikitech-l@lists.wikimedia.org

133 participants
134 discussions

question about standardized thumbnail sizes
by Sumana Harihareswara 02 Aug '14

02 Aug '14

I asked some folks about https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails… . Antoine, the original author, said on the talk page: "We had several mailing list discussion in 2012 / beginning of 2013 regarding optimizing the thumbnails rendering. That RFC is merely a summary of the discussions and is intended to avoid repeating ourself on each discussion. I am not leading the RFC by any mean, would be nice to have the new multimedia team to take leadership there." Gergo of the multimedia team has a question about whether he should start a new RfC, and a question for Ops (below), which he said I could forward to this list, so I'm doing so. :-) If we can settle this onlist, cool. Otherwise I'll be setting up an IRC chat for later this week. Sumana Harihareswara Senior Technical Writer Wikimedia Foundation On Fri, Jun 20, 2014 at 12:27 PM, Gergo Tisza <gtisza(a)wikimedia.org> wrote: > > Hi Sumana! > > We are working on some form of standardized thumbnail sizes, but it is not > exactly the same issue that is discussed in the RfC > <https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails…> > . > > The problem we have ran into is that MediaViewer fits the image size to > the browser window size (which means a huge variety of image sizes even > when the browser window is fully enlarged, and practically infinite > otherwise), > but thumbnail rendering is very slow and waiting for it would result in a > crappy user experience. We started using a list of standardized thumbnail > sizes, so that MediaViewer always requests one of these sizes from the > browser and rescales them with CSS, but even so the delay remains > problematic for the first user who requests the image with a given bucket. > To address that, we are working with ops towards automatically rendering > the thumbnails in those sizes as soon as the image is uploaded. > > Another possibility related to standardized thumbnail sizes that we are > exploring is to speed up the thumbnail generation for large images by > having a list of sizes for which the thumbnail is pregenerated and always > present, and resize one of those thumbnails instead of the original to > generate the size requested by the user. The goal of this would be to avoid > overloading the scalers when several large images need to be thumbnailed at > the same time (GWToolset caused outages this way on a few occasions). > > I can create an RfC about one or both of the above issues if there is > interest in wider discussion. I don't know whether the current thumbnail > size standardization RfC should be replaced with those, though; its goals > are not stated, but seem to be mainly operations concerns (how to make sure > thumbnails don't take up too much storage space). Maybe ops wants to take > it over, or provide clearer goals in that regard for the multimedia team to > work towards. > > >

3 3

Roadmap and deployment highlights - week of August 4th
by Greg Grossmeier 02 Aug '14

02 Aug '14

Hello! Welcome to the special "Get ready for Wikimania!" edition of the roadmap and deployment update email. This next week, in honor of Wikimania (and due to fact that many will be traveling, conference'ing, etc), there will be no planned deployments. Of course, special circumstances may require an exceptional deploy, but we will not, for instance, be rolling out/updating to new MediaWiki versions. Take a look at the upcoming (post-wikimania) items at: https://wikitech.wikimedia.org/wiki/Deployments#Next_month Any questions, as always, feel free to ask, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Brief Labs outage
by Ori Livneh 01 Aug '14

01 Aug '14

(Apologies for cross-posting.) We've been noticing an issue with lock-ups on the beta cluster application servers for the past few days. It happens about once or twice a day. It just happened again on both application servers, and I'd really like to try and get to the bottom of things this time. I'll give up and force a restart if I haven't figured it out by 6:30 UTC, about an hour from now. Please accept my apology if this is disrupting your development or QA work, and ping me on IRC if you need Beta back up urgently.

4 3

Spam filter rules on the Wiki Loves Monuments Mailing list not working
by Cristian Consonni 01 Aug '14

01 Aug '14

Hi all, (not really sure this is the right place, please redirect me if needed) Togheter with Effeietsanders I am administering the wikilovesmonuments-l mailing list[0]. This list is receiveing huge amounts of spam messages (quick stat: we are talking about 20 messages per hour). We have tried to implement some spam filter rules following this[1] (a page which I have edited myself) but basically we were unable to get any effect of sorts. Here's the two spam filtering rules I have created: * Rule 1: X-Spam-Score: [+]{2,99} * Rule 2: X-Spam-Score: [*]{2,99} I have added both rules with "+" and "*" to be sure, and I have specified the numbers (more or equal than 2 and less or equal than 99) because in my first try the rule with just {2,} (i.e. "more or equal than 2") was not working. The fact is that the solution didn't work out in the end (we were still holding in our moderation queue lots and lots of messages with an high spam score) and so we are changing the default policy for the list about non-member messages from "Hold" to "Reject" (If somebody can make a case for "Discard" over "Reject" please do so). This was quite frustrating, but we were unable to fix the problem is some other way. I am sharing this to make sure I wasn't making some sort of stupid mistake in the rules. I would also like to have an opinion about "Reject" vs "Discard" as a policy for non-members messages. Thank you. Cristian [0] https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments [1] https://wikitech.wikimedia.org/wiki/Mailing_lists#Fighting_spam_in_mailman

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l August 2014