Hi,
Tomorrow a major update[1] will be deployed for the ExtensionDistributor
extension on mediawiki.org. We will start fetching branch information
directly from Gerrit instead of relying on Github. Additionally,
tarballs will be served from extdist.wmflabs.org[2] instead of using Github.
There will be a few differences, namely that tarballs are only generated
every hour, instead of on the fly like Github did. These tarballs will
include submodules inside tarballs for extensions like VisualEditor (bug
44022[3]).
If you notice any issues or have any ideas for enhancements, please file
a bug in Bugzilla[4].
Additionally, I'd like to thank ^demon and YuviPanda for their help in
putting this service together.
-- Legoktm
[1] https://gerrit.wikimedia.org/r/#/c/149474/
[2] https://extdist.wmflabs.org/dist/
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=44022
[4]
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…
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.
>
>
>
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
Hi everyone,
I've written an RfC about changing the way extensions store metadata
about themselves and also how we load them. It's at
<https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration>.
A brief summary:
Extensions register a lot of things, like classes, hooks, special pages,
configuration options, and plenty more. Currently all of these are
usually stored in the extension's main entry point
($IP/extensions/Foo/Foo.php).
This creates two problems. First, it's difficult to tell what an
extension is going to register without actually enabling the extension.
Second, registration currently depends on global state ($wgHooks,
$wgSpecialPages, etc.) which we are trying to move away from.
My proposal is that we store this information in a JSON file (I've
provided an example on the RfC), and have MediaWiki read them when
loading extensions. We would no longer use the current method of
require_once "Foo.php";, but instead $wgEnableExtensions[] = 'foo';, and
MediaWiki would take care of the rest.
Please leave any comments or thoughts you might have on the talk page.
Thanks,
-- Legoktm
Yesterday we had a wide-ranging discussion of
https://www.mediawiki.org/wiki/Requests_for_comment/CentralNotice_Caching_O…
. We did figure out a few things -- for instance, ESI is very broken with
our currently deployed varnish; it's expected to be working for the 4
upgrade but that's a ways off. For more see the summary at
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-07-30#…
.
Matt is revising the RfC again before he takes off. Then Adam Wight and
Andrew Russell Green will most probably be in charge of it.
There's no online RfC meeting next week because of Wikimania; is anyone
planning a face-to-face architecture meeting at Wikimania?
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
You are all invited to our next Tech Talk:
HHVM in production: what that means for Wikimedia developers
Tuesday, July 29 at 19:00 UTC
Video stream: https://plus.google.com/events/cp5mjf6jrihevtdje8lmu5hvm1k
Questions: wikimedia-dev IRC
Wikimedia engineers are quickly approaching the point where we are ready to
replace our current PHP interpreter with the HipHop Virtual Machine (HHVM),
which is a complete re-implementation of PHP that will offer much faster
execution speeds than our current implementation. We're pleased to have
Paul Tarjan and Brett Simmers from the Facebook HHVM team to talk about
HHVM generally. We've had talks in the past to discuss why we should move
to HHVM; this talk will focus on "how?", such as the things that developers
should know about compatibility (e.g. "can I keep using eval in my regular
expressions?") or things you can do to make your code more efficient in the
brave new HHVM world.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
(Forked from Re: [Wikitech-l] "Not logged in" page)
Is it time to revisit this behaviour? It's come up as being a usability
problem a few times now.
Currently if I log out of a public computer it logs me out of my tablet
device,mobile device and home computer. :(
See bug for reference [1]
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=49890
On 15 Jul 2014 18:38, "Bryan Davis" <bd808(a)wikimedia.org> wrote:
> On Tue, Jul 15, 2014 at 7:25 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:
> >> regularly. I've found mediawiki logs me out despite the 'keep me
> >> logged in' box, when logging out on a different device, etc.
> > Well that's the bug then no and that should be fixed. Help us work out
> why
> > it is occurring and let's get that dealt with.:)
> >
> > We shouldn't be designing features for edge cases!
>
> Logout was discussed recently on the QA list [0]. The discussion lead
> to Jon Robson pointing out bug 49890 [1] where Chris Steipp stated
> that logout is global.
>
> [0]:https://www.mail-archive.com/qa@lists.wikimedia.org/msg01559.html
> [1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=49890
> --
> Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
> irc: bd808 v:415.839.6885 x6855
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'm trying to render an image which uses characters from all of the
languages supported by WP. Is there a single font deployed on production
servers that include all scripts? Any simple font would do, preferably TTF
arial-style.
Thanks!