Support can mean either depending on the context.
Most of this is uncontroversial, but I found it useful to think through and
sum up.
From a platform perspective to support a browser means that the user
experience is considered acceptable, tested against, and we're committed to
keeping it that
Pywikibot bug triage is finished now and during the event 189 bugs
were changed and 39 one of them were closed. Considering that
pywikibot currently has about 450 bugs, that's quite good.
A big thank you to people who joined and participated.
Best
On 7/3/14, Amir Ladsgroup ladsgr...@gmail.com
Hi Everyone,
Please join me in welcoming Joel Sahleen as software engineer in the
Language Engineering team.
Joel joins us from Adobe where he has been a globalization engineer for the
past 5 years. He developed the internationalization and localization system
for PHP components used in the
On 28 July 2014 07:45, Alolita Sharma asha...@wikimedia.org wrote:
Hi Everyone,
Please join me in welcoming Joel Sahleen as software engineer in the
Language Engineering team.
Welcome aboard, Joel!
Yours,
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
Hi everyone,
Different chapters are looking into organizing next years hackathon. One
of the recurring questions is how much it costs to organize such an
event. To make it easier to answer this question we published the budget
of the Amsterdam hackathon at
I would probably recommend using the existing EventLogging infrastructure
for sending the data to our back end, assuming it won't explode under heavy
load spikes... Which it might. :)
Eventlogging is not the best choice. Besides
not handling bursts of traffic it is -currently- a tier-2
Am 28.07.2014 18:36, schrieb Maarten Dammers:
Different chapters are looking into organizing next years hackathon. One
of the recurring questions is how much it costs to organize such an
event. To make it easier to answer this question we published the budget
of the Amsterdam hackathon at
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2014.07. This bundle is compatible with MediaWiki 1.23.x and
MediaWiki 1.22.x releases.
* Download:
https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.07.tar.bz2
* sha256sum:
tl;dr: I am going to break your workflow and your wiki. Skip to the
last section and read on.
== Background ==
As you know, I've been working on a GSoC project to better separate
skins and core MediaWiki [1]. Moving Vector and MonoBook to separate
repositories is the final step of it, and it's
Hi everybody,
I was on the brink of celebrating the one-year anniversary of a patch I
submitted being open, but today it was finally merged!
https://gerrit.wikimedia.org/r/77645
The old User::comparePasswords() and User::crypt() functions have been replaced
with a new password hashing API.
Hi Bartosz,
Sounds good.
Bartosz Dziewoński schreef op 28-7-2014 20:53:
If you're upgrading a wiki or you're a developer working on master,
THIS IS A BACKWARDS INCOMPATIBLE CHANGE. Your wiki will continue to
work, it will just look ugly (no styles).
And I assume whatever MediaWiki version this
Why not just move them to an extension? moving them to their own repo begs
for a headaches
On Mon, Jul 28, 2014 at 4:50 PM, Maarten Dammers maar...@mdammers.nl
wrote:
Hi Bartosz,
Sounds good.
Bartosz Dziewoński schreef op 28-7-2014 20:53:
If you're upgrading a wiki or you're a developer
Thank you. Out of curiosity, why bcrypt and not scrypt? There is debate in
the security community about which is better so my comment isn't intended
as criticism. I'm just interested in the thinking behind this decision.
Thanks,
Pine
On Jul 28, 2014 1:35 PM, Tyler Romeo tylerro...@gmail.com
On Mon, 28 Jul 2014 22:50:49 +0200, Maarten Dammers maar...@mdammers.nl
wrote:
And I assume whatever MediaWiki version this will be packaged into
should will include an upgrade script for people who just bump one
version?
There is no need for an upgrade script. If you're upgrading using
On Mon, 28 Jul 2014 22:59:40 +0200, John phoenixoverr...@gmail.com wrote:
Why not just move them to an extension? moving them to their own repo
begs
for a headaches
I don't understand the problem you see here nor the solution you're
proposing. Elaborate?
--
Matma Rex
I use a standard git checkout. Moving these to their own separate location
is going to be a pain in the ass. If the skins are moved to the existing
extension system it causes far fewer problems and does not introduce
additional steps in upgrading/maintaining a site. When we start having sub
repos
I am pleased to announce (after far too long of a delay, my apologies),
that Mark Hershberger and Markus Glaser will take on the task of
managing the third-party releases of MediaWiki for another year.
Congrats Mark and Markus!
I'd like to explicitly thank the International Consortium team for
On Mon, Jul 28, 2014 at 5:24 PM, Pine W wiki.p...@gmail.com wrote:
Thank you. Out of curiosity, why bcrypt and not scrypt? There is debate in
the security community about which is better so my comment isn't intended
as criticism. I'm just interested in the thinking behind this decision.
It
- Original Message -
From: Tyler Romeo tylerro...@gmail.com
It is a matter of stability in PHP. Bcrypt has built-in support in PHP, as
does PBKDF2, whereas scrypt requires an extension. It should be noted,
however, that the patch that was merged implements an extensible password
API,
19 matches
Mail list logo
