FYI
---------- Forwarded message ----------
From: Philip Chang <pchang(a)wikimedia.org>
Date: Thu, Sep 20, 2012 at 8:53 PM
Subject: WLM Android app v1.2.4 Daigo-ji
To: Wiki Loves Monuments Photograph Competition <
wikilovesmonuments(a)lists.wikimedia.org>
Dear WLM Members,
The WLM Android app has been updated to v1.2.4, named Daigo-ji.
Release notes:
* Dynamically loads localization updates
* Clears large image previews before taking another photo - may help with
"out of memory" errors
* Stops "Mobile to desktop upload" category from being added to uploads
from the app - this category should be limited to desktop uploads from a
mobile upload
Please note: there are issues with the Cordova interface to the camera that
are outside of our control (Cordova is the app framework used to build our
mobile apps).
There are a significant number of users experiencing crashes and we are
limited in our ability to debug these problems, for several reasons:
* We are not able to reproduce these problems on the same devices that
seems to be experiencing the problems
* Google Play captures a part of the error which does not include the
Cordova aspects
* Google Play does not allow us to contact reviewers or people reporting
crashes
Therefore, if you hear of any users having such problems, please have them
contact us by email at: mobile-feedback-l(a)lists.wikimedia.org.
Thanks for your support.
Phil
--
Phil Inje Chang
Product Manager, Mobile
Wikimedia Foundation
415-812-0854 m
415-882-7982 x 6810
--
Phil Inje Chang
Product Manager, Mobile
Wikimedia Foundation
415-812-0854 m
415-882-7982 x 6810
There are a few upcoming breaking changes in the Wikibase API.
* The items id as exposed to the outer world is now a numeric id. This
will be prefixed with a letter and this letter will be used internally
during lookup. Do not hardcode interpretation of this letter as it can
be configured, but once configured it will be type-specific for the
type of entity.
https://bugzilla.wikimedia.org/show_bug.cgi?id=40381
* The encapsulating "items"/"item" in the reply will be replaced by
"entities"/"entity" and it will be a new type-field in each entity.
This field will have an identifier that says which kind of entity is
in there.
https://bugzilla.wikimedia.org/show_bug.cgi?id=40407https://bugzilla.wikimedia.org/show_bug.cgi?id=40408
John Erling Blad
Hello all,
As recently announced [1], WMF will move forward in creating a
Wikimedia travel project based on community request and support.
We’re currently in discussions with the Wikivoyage community, who’ve
expressed interest in joining Wikimedia’s project family as part of
this launch. We’re coordinating certain practical issues, such as
content migration, account reconciliation, and attribution, with them
directly. Please note that the new project will be subject to
Wikimedia’s terms of use, privacy policy, and licensing policy. Like
with any of our projects, the bulk of content-related policies and
practices will be designed and managed by the community.
Launch discussions are continuing here:
https://meta.wikimedia.org/wiki/Talk:Travel_Guide
An additional open question is the project name. Wikivoyage has
offered to contribute its name. So, we could stick with Wikivoyage,
which is already established, and has a non-profit organization
supporting it. We have also obtained a number of alternative domain
names, as have individual community members. We’ll initially straw
poll the "Wikivoyage yes/no" question as this seems like the simplest
path forward if there’s wide agreement in favor; more on that in a
separate note by Philippe.
For the Wikivoyage content import and project launch, our current plan
is to do an in-person sprint in San Francisco in late October to
support the project launch (we may defer this based on everyone’s
availability). There’s also plenty of work ahead of time. If you’d
like to be part of the technical launch team, please sign up here:
https://meta.wikimedia.org/wiki/Travel_Guide/Technical_coordination
We’ll also continue to monitor comments on
https://meta.wikimedia.org/wiki/Talk:Travel_Guide and will engage
there as the process continues.
For the time being, I am coordinating the overall project launch,
supported by Philippe. Questions/comments welcome.
I look forward to getting this project off the ground. :-) As we’ve
said before, we don’t view ourselves in competition with other
providers of free knowledge, nor do we encourage anybody to leave any
other site. The beautiful thing about free culture is that anyone who
wishes to contribute to the corpus of freely available information
about travel (or indeed any subject) can do so anywhere, and both
information and people can flow freely between projects.
All best,
Erik
[1] http://lists.wikimedia.org/pipermail/wikimedia-l/2012-September/121897.html
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It is a week later than I originally said I would get to it, but I've
finally managed to get the time together to construct a beta tarball
to, as Rob said over a week ago, "help with pre-release practice".
I've used the make-release script that Sam Reed pointed me to before,
so I think I've done this using the same tools as he would have. I
used the wmf1.2011 branch, so I think this is pretty sane.
And just to verify this, I did a brief sanity check by running the
installer.
Hopefully, we can use this to start getting a 1.20 tarball out at the
beginning of October.
Download:
http://mah.everybody.org/mediawiki-1.20.0beta0.tar.gz
Release Notes:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=R…
GPG signatures:
http://mah.everybody.org/mediawiki-1.20.0beta0.tar.gz.sig
Public key:
http://mah.everybody.org/contact-infohttp://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x7956EE477F901A30
(If there there is anyone with a PGP key in the Philadelphia/New York
City area who can sign my key, let me know. I have to get some more
signatures.)
- --
http://hexmode.com/
Human evil is not a problem. It is a mystery. It cannot be solved.
-- When Atheism Becomes a Religion, Chris Hedges
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iD8DBQFQVQtlc17xCi38v/URAnDvAJ9+yjY1AMntUzedWyzHyckSSc5C2gCggciH
KcKJuNP3yEHIAm8esqPnNbw=
=8g8S
-----END PGP SIGNATURE-----
Do we have any stats on IPv6 accesses and edits on Wikimedia sites?
I see this page on stats, which suggests it's literally so small we
can't even count it:
http://stats.wikimedia.org/wikimedia/squids/SquidReportCountryData.htm
Is that actually the case? 'Cos we do know IPv6 edits occur, therefore
IPv6 page views occur.
- d.
This change has been made now.
Rob
On Thu, Sep 6, 2012 at 9:15 AM, Rob Lanphier <robla(a)wikimedia.org> wrote:
> Forwarded as this is of potentially wider interest. This may be a
> breaking change for some older bots that haven't been maintained.
>
> ---------- Forwarded message ----------
> From: Sam Reed <reedy(a)wikimedia.org>
> Date: Wed, Sep 5, 2012 at 3:06 PM
> Subject: [Wikitech-l] HTML5, it's a coming (again)!
> To: wikitech-l(a)lists.wikimedia.org
>
>
> It's been a long time coming (for the nth time..), but we're scheduling a
> deployment of HTML5 across the Wikimedia cluster [1]. This is set for Monday
> 17th September at 18:00-20:00 UTC [2].
>
>
>
> The intention is to set $wgHtml5 [3] to true everywhere. It's been running
> on MediaWiki.org and our 2 test wikis for quite a while, and other sites
> like translatewiki.net with no issues.
>
>
>
> The intention is to leave it enabled unless it causes major problems. If
> you're running an application that screen scrapes, shame on you; you've had
> enough notice to get it fixed! ;)
>
>
>
> Now is the time to fix up your scripts and programs (where necessary), tell
> your friends!
>
>
>
>
>
> Sam
>
>
>
>
>
> [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=27478
>
> [2] http://wikitech.wikimedia.org/view/Software_deployments#Week_of_Sept_17
>
> [3] https://www.mediawiki.org/wiki/Manual:$wgHtml5
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi everyone,
This is something I've been meaning to bring up for some time, but have
just been delaying getting it done. For a bunch of reasons, we need to
look at disabling direct pushing on the master branch for all extensions in
Gerrit. This doesn't affect other branches, just master. There's a couple
of big reasons this is a problem right now, and why we need to change:
1) Eventually, we'll be running tests for all extensions (at the very least
linting if no phpunit tests have been written). Jenkins doesn't have the
change to -1 a commit if you skip review.
2) It doesn't give anyone a place to complain about the patch. Every
commit to master needs a place to say "Hey wait a minute" -- even if it's
already been merged.
3) Changes that are directly pushed aren't searchable from Gerrit. This is
more a feature request for Gerrit, but one that's easily worked around by
just pushing through Gerrit.
I realize that feature branches don't necessarily need the same level of
scrutiny, but the "primary" branch for a repository needs to be as public
as possible--direct pushing makes this difficult. I don't plan on changing
this requirement for any branch that's not "master" or "wmf/" (the latter
relating to deployment config). Before I make the change though, I
wanted to ask about it publicly to make sure there's no major blockers
to me doing so.
Thanks for any feedback you can give.
-Chad