Hi everyone,
Everything I said below still stands, except now there are only two days,
so please make the most of them.
Don't make me break out the caps lock. I'll do it. :-)
Thanks
Rob
---------- Forwarded message ----------
From: Rob Lanphier <robla(a)wikimedia.org>
Date: Wed, Dec 11, 2013 at 12:41 PM
Subject: RFC deadline approaching for Arch Summit: December 20
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Hi everyone,
We're just over a week away from the Friday, December 20 deadline for RFCs
as items to consider at the Architecture Summit.[1] That's not a hard and
fast rule (we've never done this before), but we should definitely have a
reasonable amount of time between the point an RFC is proposed and being
discussed at the Architecture Summit. Ideally, we'll have taken care of
everything that's reasonable to take care of via mailing list/IRC/other
online meeting, and really be down the things that require face-to-face
time to accomplish.
It's my hope that we're not just nibbling at the edges, but that we're
actually going to talk about things that will substantially modernize our
architecture and reduce our technical debt. I believe there are RFCs in
the list and in the works that do that, but I also know there are areas
we've discussed informally in the past that we've never set to writing.
Many of the RFCs cover important areas of incremental improvement, but not
all of the changes we need to make have such small increments.
Anyway, RFC submission page is here:
https://www.mediawiki.org/wiki/Requests_for_comment
Rob
[1] https://www.mediawiki.org/wiki/Architecture_Summit_2014
As folks may be aware, over in the Wikimedia Mobile Apps team we're
starting a refresh of the Wikipedia mobile apps for Android and iOS, which
have not been updated in a while and are now wayyy behind the mobile web in
features and UI awesomeness.
The new apps are using native UI around the content web view, which lets us
integrate with the system better than the old PhoneGap-based HTML app, and
provide long-desired features like pinch-to-zoom in the article view.
Our first 2-week work sprint is finishing up, and builds of current state
are available:
* Android:
http://dumps.wikimedia.org/android/apps-android-wikipedia-dev-sprint1.apk
* iOS: on testflightapp.com (email notifications sent to our recently
trimmed beta list)
Both versions are pretty bare-bones, so don't be surprised by missing
icons, toolbar buttons that don't work, or incomplete design. :)
This first feature sprint concentrated on getting search & basic content
loading working. You can type into the search box, the search results
include thumbnails, and you can select a search result to load the article.
You can also click on internal links in both iOS and Android versions,
though they get a little flaky from there out. :) Back/forward is not yet
implemented on iOS; back works on Android but there's no forward.
Note also the pretty animation when following links on Android -- neat!
Next sprint's release should look more polished, as we'll have some more
navigation working, and the first sprint stuff prettied up to better match
design:
https://upload.wikimedia.org/wikipedia/commons/c/c8/Search-overlay-01.png
For in-progress design & UX ideas for the new app, see
https://www.mediawiki.org/wiki/Wikipedia_App_Design
Note that you may or may not need to manually uninstall the old app if it's
present first.
If you want to try the iOS version and aren't on the beta list you'll have
to build it yourself on a Mac with XCode 5, and then you can only install
it on your device if you are a registered iOS developer (thank Apple's
restrictions on third-party app installations!):
$ git clone https://gerrit.wikimedia.org/r/apps/ios/wikipediaapps-ios-wikipedia
(Unfortunately we cannot add new people to the iOS beta list until Apple
clears out old entries from our 100-max device database, either at the end
of the calendar year or in February when our membership rolls over. Yeah,
I'm serious...)
And of course you can build the Android version too, and run it with no
restrictions:
$ git clone https://gerrit.wikimedia.org/r/apps/android/wikipediaapps-android-wikipedia
Note that there's separate work going to revitalize the Wikipedia app for
Firefox OS, which will remain HTML5-based as that's how native Firefox apps
work! That's being spearheaded by the Wikimedia Mobile Partnerships &
Wikipedia Zero team.
-- brion
Hello,
Gerrit changes are processed by a daemon known as Zuul which triggers
Jenkins jobs and report back to Gerrit as the infamous jenkins-bot.
Since I upgraded Zuul in May 2013, the jobs were not processed as fast
as we would have wanted. There were issues on Jenkins side, faulty
configuration on the server but we eventually reached some acceptable state.
Still. During busy hours (Europe evening, SF morning) with the l10n bot
submitting half a thousand of changes, we would have to wait up to half
an hour to get a test report. I spent most of the night debugging and
reproducing that issue on my computer then went to bed.
A few minutes ago, I have deployed a change that would make Zuul process
changes way faster. The change is ridiculously small since it is just
about commenting two lines:
https://gerrit.wikimedia.org/r/102465
It basically prevents Zuul from updating builds descriptions pages in
Jenkins until all builds have been completed. Since updating a build
description takes roughly 500ms, that is saving a ton of waiting time.
Thanks a ton to at least Ori, Timo, Qchris, RobH, manybubles and
basically everyone around using the CI platform in one way or another.
I have monitored the upgrade for the last few minutes in production and
that works as expected. The rollback plan is:
Revert https://gerrit.wikimedia.org/r/102465
Merge revert
on gallium:
- cd /usr/local/src/zuul
- git pull
- as root:
* http_proxy=. python setup.py install
* /etc/init.d/zuul restart
I don't think that it is needed though. Will monitor again tonight
during the real peak hour.
For reference the bug is https://bugzilla.wikimedia.org/48025 which I
believe is now properly fixed.
Merry Christmas.
--
Antoine "hashar" Musso
Hello,
I would like to use the score extension to generate guitar chords
diagrams, but writing something like
<score>
\fret-diagram #"s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;"
</score>
I get this message error:
Processing `.../file.ly'
Parsing...
.../file.ly:12:0: error: unknown escaped string: `\fret'
\fret-diagram #"s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;"
.../file.ly:12:0: error: syntax error, unexpected STRING
\fret-diagram #"s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;"
.../file.ly:21:24: error: syntax error, unexpected '}'
}error: failed files: ".../file.ly"
exited with status: 1
The code works just fine when I compile it with my local lilypond. That
functionality would be really interesting, since with a little scribunto
module, it would allow to generate chords diagram on the fly, and even a
chord book.
Also I would like to make even more with colored diagrams showing a set
of interval on the neck. It would be fine if the mediawiki environnement
would allow this.
kind regards
Hello and welcome to the latest edition of the deployment highlights
email.
You can always check the Deployment calendar [0] for the canonical
reference of deployments planned during a given week.
For next week:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_December_16
!!!Special Holiday Note!!!
This next week is the last week of planned (non-emergency) deployments
before we take a week off for the holidays.
== Monday ==
* The new search backend (CirrusSearch[1]) will be enabled on all
wikisources and commons as a secondary search option that is
accessible via the appending "&srbackend=CirrusSearch" to a search
url.
* CirrusSearch will be added to the list of "Beta Features" that users
can opt-in to on all wikimedias, wikimanias, and wiktionaries.
* There will be a new version of PHP deployed to the Wikimedia servers
on Monday as well. This should not change any user-facing actions
(this update will help deal with a server problem where temporary
files are not deleted when appropriate).
== Tuesday ==
* All non-Wikipedia sites will be switched to MediaWiki 1.23wmf7 [2].
* The GLAM Wiki Toolset[3] will be enabled on Commons, allowing for GLAM
institutions (Galleries, Libraries, Archives and Museums) to more
easily upload bulk collections of images with associated metadata.
== Wednesday ==
* The new search backend (CirrusSearch) will be enabled on:
** all wikinewsies set as secondary search;
** itwiktionary, disabled wikis, cawiki, and enwikisource set as primary
search;
** all users on all wikisources will have the option of enabling it as
their own personal primary search via BetaFeatures[4].
* The new and improved Wikimania Scholarships application[5] will be
deployed to production. NOTE: this doesn't mean you need to start
applying for scholarships, this is simply the deployment of the code
for the new scholarship application management tool. See your friendly
Wikimania planners for more information about scholarships.
== Thursday ==
* All Wikipedias will be switched to MediaWiki 1.23wmf7 [2].
* All test wikis (test.wikipedia.org, test2, mediawiki.org, and
test.wikidata.or) will be switched to MediaWiki 1.23wmf8 [6].
Thanks, and as always, feel free to reply with any questions,
Greg
[0] https://wikitech.wikimedia.org/wiki/Deployments#Near_Term
[1] https://www.mediawiki.org/wiki/Search
[2] https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf7
[3] https://www.mediawiki.org/wiki/Extension:GWToolset
[4] https://www.mediawiki.org/wiki/Beta_Features
[5] https://www.mediawiki.org/wiki/Wikimania_Scholarship_app
[6] https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf8
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hello everyone,
It’s with great pleasure that I’m announcing that Kunal Mehta[1] has joined the Wikimedia Foundation as contractor in Features Engineering.
Before joining us (and currently), Kunal is a student in college, switching from computer science to business administration for reasons that I’m sure warrant more discussion.
Kunal is currently a Wikipedia admin got involved working on the projects 8 years ago. He also helps writing and maintaining bots (legoktm <3’s pywikibot) and working on the nether regions of the volunteer developer community as part of the Volunteer Response Team, which he currently continues to do[2]. I met him at Wikimania through a Wikidata scholarship because apparently we were too cheap to spring for his ticket.
Kunal will be working with the Core Features Team since MassMessage[3] and Echo[4] have overlapping concerns, and Flow[5] can use more development support now that it is out. When he isn’t doing that you’ll see him around adding this and that to core or the bots. :-)
Kunal lives and goes to school in San Jose. Most importantly, he’s unlocked level 2 in Naan Sense on FourSquare[6]. From his username on the projects, I’d also bet he must like Lego Mindstorms[7].
For the record, Kunal, I, for one, welcome our new robot overlords.
As you have guessed from my usual tardiness and my drive to finish my announcements before the calendar year, his first official day was actually October 28th (Only two months ago? Not bad, not bad at all).
Please join me in a belated welcome of Kunal Mehta to the Wikimedia Foundation.
Take care,
Terry
[1]: [[User:legoktm]]
[2]: https://github.com/legoktm
[3]: https://www.mediawiki.org/wiki/Extension:MassMessage
[4]: https://www.mediawiki.org/wiki/Echo_(Notifications)
[5]: https://www.mediawiki.org/wiki/Flow_Portal
[6]: https://foursquare.com/legoktm/badge/51296de6e4b096ae4b48fb8e?ref=tw
[7]: https://en.wikipedia.org/wiki/Lego_Mindstorms_NXT
terry chay 최태리
Director of Features Engineering
Wikimedia Foundation
“Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.”
p: +1 (415) 839-6885 x6832
m: +1 (408) 480-8902
e: tchay(a)wikimedia.org
i: http://terrychay.com/
w: http://meta.wikimedia.org/wiki/User:Tychay
aim: terrychay
when i open the chrome console,i always can get:
> event.returnValue is deprecated. Please use the standard event.preventDefault() instead.
is any plan to fix this?
Regrades
Sen
From SLboat(http://see.sl088.com)
The mobile skin has traditionally used the template variable
'language_urls' in SkinTemplate to access the list of alternative
languages of an article. We are now seeing a lot of friction and bugs
as we try to move our codebase closer to core.
Question 1:
What does 'language_urls' mean - is it acceptable for anything other
than a real language to be in that list?
Over the course of 3 weeks however we have had 3 bugs that have added
things that are not languages to this list. This has caused various
noticeable problems with how languages works on mobile.
Question 2:
Why do developers abuse it in this way - is there not a better more
semantic way to do this?
Currently we have an issue live on all wikipedias which makes a
language button show up on all pages - even those without articles.
x
https://en.m.wikipedia.org/w/index.php?title=Diggers_%26_Dealers&title=Digg…
When the language button at the bottom of the screen is clicked it
says "This page is available in 1 language: Edit links (Edit
interlanguage links)
As a result I've now proposed a change for our skin to override this
[1] so that we can control the list contents and override the effects
of the hook.
This however is rather frustrating - especially given none of our
template variables are documented and open to this kind of
interpretation
Question 3:
Should we document these template variables? If so where and how?
Thanks for your opinions on this matter.
[1] https://gerrit.wikimedia.org/r/99693
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
Hi everyone,
Myself Anu G Enchackal ,GNOME Outreach Program for Women Round 7
Intern,working on UploadWizard : OSM embedding mentored by Gergő Tisza.
This project is about enhancing the image upload process for Wikimedia
Commons.The main goal of the OpenStreetMap map embedding project would be
to provide map interface & the integration with external databases to the
UploadWizard.The secondary goal is to integrate with some databases of
locations and use that in various ways. One way would be checking if there
are locations with requested images nearby (that is, someone put out a note
that Commons needs good images about a certain place and doesn't currently
have any), and warn the uploader about them.
****Week 1 ( Dec 10 --- Dec 16 )****
This week was spent mostly by navigating through the existing structure and
working on a link introduction within UploadWizard.
The present plan is to introduce a link next to coordinate fields within
UploadWizard , which can initialize the map widget onclick. Patch sets [1]
which replaces the existing 'Show on Map' with a link having the same
functionality are already uploaded to gerrit.
Expecting valuable comments from everyone
Anu G Enchackal
OPW Round 7 Intern
[1] https://gerrit.wikimedia.org/r/#/c/101029/
