Wikitech-l November 2012

wikitech-l@lists.wikimedia.org

130 participants
136 discussions

problems merging changes from master -> remote branch
by Arthur Richards 03 Dec '12

03 Dec '12

I am trying to merge a bunch of changes that have occurred in the master branch of the MobileFrontend extension to a remote branch (esisupport), but git review errors out, failing on a change that had been abandoned in the remote branch. First I merged the changes from master to a local checkout of the remote. After fixing merge conflicts, I ran 'git review esisupport' and this is what happened: You have more than one commit that you are about to submit. The outstanding commits are: 503bd3d (HEAD, esisupport) getArticleUrl returns canonical url (bug 41286) 8c70e8b Fix adding unnecessary callbacks in mf-cleanuptemplates <snip> Is this really what you meant to do? Type 'yes' to confirm: yes remote: Resolving deltas: 100% (315/315) remote: Processing changes: refs: 1, done To ssh:// awjrichards@gerrit.wikimedia.org:29418/mediawiki/extensions/MobileFrontend.git ! [remote rejected] HEAD -> refs/publish/esisupport/bug/41286 (change 32896 closed) error: failed to push some refs to 'ssh:// awjrichards@gerrit.wikimedia.org:29418/mediawiki/extensions/MobileFrontend.git ' What is going on? Am I doing this wrong? Thanks for any help! -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

2 2

Standardizing highest priority in Bugzilla
by Andre Klapper 30 Nov '12

30 Nov '12

== Situation == In Wikimedia Bugzilla you can set a priority for a bug report. Some people and teams set highest priority often (meaning "These issues should get fixed first in the next weeks"). Some don't set it at all (and likely related: Some teams don't really use Bugzilla but other tools). Some are in-between. This use might work well for each team. * Currently there are 15 open tickets with highest priority: https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&resolution=---&… (You might only see 14 if you don't have access to security bugs) * 5 of them have highest priority for more than 30 days: https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&resolution=---&… * 2 of them for more than 90 days (Huggle vs IPv6; moving to EQIAD): https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&resolution=---&… The latter imply either missing maintainership (Huggle?) or tasks that take longer (EQIAD) and could be broken down into subtasks. == Problem == Currently "Highest Priority" has no single (cross-team) meaning. This makes it hard for people outside of a team (e.g. Engineering Management) to see at a glance what's most important and urgent for each team. == Proposal == Proposing the following definitions for Priority: * highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the "Assigned to" field. * high: Should be fixed within the next four weeks. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

15 29

Apply for the FOSS Outreach Program for Women internships
by Quim Gil 30 Nov '12

30 Nov '12

Hi, the FOSS Outreach Program for Women internships has started! The blog post: http://blog.wikimedia.org/2012/11/15/apply-for-the-foss-outreach-program-fo… The program: https://live.gnome.org/OutreachProgramForWomen The Wikimedia specific information: https://www.mediawiki.org/wiki/Outreach_Program_for_Women If you are following Wikimedia in Identica, Twitter, G+ or Facebook, you likes and shares are welcome. Please help out reaching out to women in tech out there! -- Quim

1 4

There are maps for wikivoyage?
by Raylton P. Sousa 29 Nov '12

29 Nov '12

I keep thinking that (particularly) the wikivoyage[1] could be much better if we had good maps similar to the dantonwiki[2] (that runs on localwiki[3]). Is there any similar map project in mediawiki that can be activated in small wikivoyage wikis? [1]http://www.wikivoyage.org/ [2]https://dentonwiki.org/map/The_Square [3]http://localwiki.org/

5 4

MediaWiki security release: 1.20.1, 1.19.3 and 1.18.6
by Chris Steipp 29 Nov '12

29 Nov '12

MediaWiki security release: 1.20.1, 1.19.3 and 1.18.6 I would like to announce the release of MediaWiki 1.20.1, 1.19.3 and 1.18.6. These releases fix 3 security related bugs that could affect users of MediaWiki. Download links are given at the end of this email . Please note that support for the MediaWiki 1.18 branch ends this month. * During an internal review, it was discovered that MediaWiki core is vulnerable to session fixation attacks. Successful exploitation could allow an attacker to compromise another user's account. This issues has been assigned CVE-2012-5391. A similar vulnerability was also identified in the CentralAuth Extension, and assigned CVE-2012-5395. <https://bugzilla.wikimedia.org/show_bug.cgi?id=40995> <https://bugzilla.wikimedia.org/show_bug.cgi?id=40962> * Wikipedia user PleaseStand discovered that a new API feature in MediaWiki 1.20 allowed for HTML code to be injected into the "editfont" option. Since this option only affects the current user, exploitation for XSS is difficult. However, users of MediaWiki 1.20 are encouraged to upgrade. <https://bugzilla.wikimedia.org/show_bug.cgi?id=42202> * Wikipedia user PleaseStand discovered that a PCRE backtrack limit could easily be exceeded, causing recent changes and history pages to fail to display. Since these pages are often used for fighting spam and vandalism, public wikis are encouraged to update. <https://bugzilla.wikimedia.org/show_bug.cgi?id=41400> Full release notes for 1.20.1: <https://www.mediawiki.org/wiki/Release_notes/1.20> Full release notes for 1.19.3: <https://www.mediawiki.org/wiki/Release_notes/1.19> Full release notes for 1.18.6: <https://www.mediawiki.org/wiki/Release_notes/1.18> For information about how to upgrade, see <https://www.mediawiki.org/wiki/Manual:Upgrading> ********************************************************************** 1.20.1 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.1.tar.gz Patch to previous version (1.20.0), without interface text: http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.1.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.20/mediawiki-i18n-1.20.1.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.1.tar.gz.sig http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.1.patch.gz.sig http://download.wikimedia.org/mediawiki/1.20/mediawiki-i18n-1.20.1.patch.gz… Public keys: https://secure.wikimedia.org/keys.html ********************************************************************** 1.19.3 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.3.tar.gz Patch to previous version (1.19.2), without interface text: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.3.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.3.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.3.tar.gz.sig http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.3.patch.gz.sig http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.3.patch.gz… Public keys: https://secure.wikimedia.org/keys.html ********************************************************************** 1.18.6 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.6.tar.gz Patch to previous version (1.18.5): http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.6.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.6.tar.gz.sig http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.6.patch.gz.sig Public keys: https://secure.wikimedia.org/keys.html ********************************************************************** Extension:CentralAuth ********************************************************************** Information and Download: http://www.mediawiki.org/wiki/Extension:CentralAuth

1 0

wikivoyage.com
by Neil Harris 29 Nov '12

29 Nov '12

I visited en.wikivoyage.com by mistake, and dicocvered that en.wikivoyage.com appears to serve up Wikivoyage-old's content, but from 188.40.41.16, which whois identifies as being in the netblock HETZNER-RZ10 operated by Hetzner Online AG. The wikivoyage.com domain itself has a last-modified date of 2012-10-14. Even more puzzlingly, the PTR record for 188.40.41.16 currently points to wikivoyage.org. Can anyone cast any light on this? Is this officially sanctioned by the wikivoyage/Wikimedia communities? Neil

11 16

the skin change in 1.21wmf5, display breakage, & fix retrospective
by Sumana Harihareswara 29 Nov '12

29 Nov '12

Basics: We rolled out 1.21wmf5 to the non-Wikipedia sites today, after a brief reversion and re-deployment to fix breakage in how we were displaying some styling. We are on track to deploy 1.21wmf5 to English Wikipedia on Monday, December 3 per https://www.mediawiki.org/wiki/MediaWiki_1.21/Roadmap . Below: why this happened and how it got fixed, and what we should change to prevent problems like this in the future. What happened: https://gerrit.wikimedia.org/r/#/c/30361/ changed the headings in the Vector skin. The new code didn't take the WMF config into account, as the author wasn't expecting styles and HTML to be cached in such different ways. The headings were changed from "h4"/"h5", but the CSS used those tags to identify them (instead of using CSS classes). Which means, as expected, that the page layout breaks for up to 30 days. Page cache is controlled by the wiki page content. Unless the page is modified, the cache is kept for up to 30 days for anonymous users. Resource modules, however, are served by ResourceLoader which has its own much more efficient and deployable cache mechanism. But this means that the resources for the skin are deployed globally and site-wide within 5 minutes.... whereas the HTML isn't for another 2 weeks. The issues that caused were visible in beta labs for the last three days, but none of us realized they were significant, we thought they were caused by a misconfigured memcache; see https://bugzilla.wikimedia.org/show_bug.cgi?id=42452 . We knew that this particular change and the related change https://gerrit.wikimedia.org/r/#/c/34702/ might be problematic and sent out a note about it on Monday -- http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2012-November/000… -- but it looks like we didn't test thoroughly enough on Monday and Tuesday to catch it before the Wednesday deploy. Only anonymous users would have been affected. We don't cache logged-in users in Squid. So logged-in users didn't notice problems on mediawiki.org and test2.wikipedia.org after the first deploy. Problems popped up after the Phase 2 deployment to non-Wikipedia sites, so we reverted the 1.21wmf5 deployment and then redeployed while fixing, purging, etc. Bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=42452 Gerrit changes: https://gerrit.wikimedia.org/r/#/c/35819 , https://gerrit.wikimedia.org/r/#/c/35815/ , https://gerrit.wikimedia.org/r/#/c/35817/ What we should fix for the future: This is why client resources must always be backwards compatible. "Don't change the HTML in incompatible ways" is probably a good general rule to live by--but having an easy way to say "start purging all pages on $theseWikis from Squid/Varnish" would also be nice. get more manual testing on test2.wikipedia.org and mediawiki.org immediately after Phase I deployment, including as anonymous reader and editor to ensure we catch Squid caching issues train more people to review code well, to reduce backlog and catch these kinds of problems? get more people to +2 in core and in important extensions beta labs needs to be trustworthy enough to make this sort of thing a blocker immediately Chris McMahon's take: (for what it's worth, this seems to me to be a sign that beta labs is becoming more and more trustworthy all the time. The more we actually use it, the more we'll understand what does and does not work there. We fixed the memcache problem, which fixed the ability to login, but didn't investigate the display problems because we're used to beta not being very reliable. In this case, beta was reliable, and we didn't understand that. Even with a bug report in bugzilla with 9 subscribers, no one recognized a real issue.) Chris McMahon said: I think this could be framed as an issue of signal, noise, and bandwidth. Beta labs being broken a lot, review backlog in gerrit, false failures in tests are all noise. Given the constraints of ongoing projects, it is difficult to pick out the signal from the noise. We can take steps to reduce the noise so that the signal stands out more by reducing technical debt: make the tests green, make the test environment robust, keep up with code review. (I assembled this just now from IRC & mailing list chatter from several people, and errors are mine -- sorry for missing attributions here. Drafting was on http://etherpad.wmflabs.org/pad/p/nov-28-2012-deploysnafu ) -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

3 2

Tech Chat: Mobile QA & newbie dev tutorial tumorrow
by Erik Moeller 29 Nov '12

29 Nov '12

Tomorrow, we have two topics on the agenda for the weekly tech chat / brown bag: * a mobile QA guest speaker: Pete Hodgson, with Khali Young from ThoughtWorks, will talk about automated testing (and cross-platform development strategies). See Pete's blog at: http://blog.thepete.net/ * Sumana is planning a walkthrough on "how to fix a bug" from start to finish, suitable for newbie developers. As always, will be live-streamed, recorded, transmogrified, etc. Sign up here, come in person or on #wikimedia-dev tomorrow: https://www.mediawiki.org/wiki/Meetings/2012-11-29 Cheers, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

1 1

Fwd: MediaWiki Language Extension Bundle launches
by Niklas Laxström 29 Nov '12

29 Nov '12

FYI. I will not be posting release announcements here, but feedback on the implementation is welcome. Code is at: https://gerrit.wikimedia.org/r/gitweb?p=translatewiki.git;a=tree;f=melange Maybe there is interest in making it more generic and use it to make other extension bundles too. In that case it we could create own repo for it. Some known TODOs on top of my head: * Signing the archive * Running of PHPUnit tests is currently broken * QUnit tests need to be run manually -Niklas ---------- Forwarded message ---------- The Wikimedia Language Engineering team is pleased to announce the first release of the MediaWiki Language Extension Bundle. The bundle is a collection of selected MediaWiki extensions needed by any wiki which desires to be multilingual. This first bundle release (2012.11) is compatible with MediaWiki 1.19, 1.20 and 1.21alpha. Get it from https://www.mediawiki.org/wiki/MLEB The Universal Language Selector is a must have, because it provides an essential functionality for any user regardless on the number of languages he/she speaks: language selection, font support for displaying scripts badly supported by operating systems and input methods for typing languages that don't use Latin (a-z) alphabet. Maintaining multilingual content in a wiki is a mess without the Translate extension, which is used by Wikimedia, KDE and translatewiki.net, where hundreds of pieces of documentation and interface translations are updated every day; with Localisation Update your users will always have the latest translations freshly out of the oven. The Clean Changes extension keeps your recent changes page uncluttered from translation activity and other distractions. Don't miss the chance to practice your rusty language skills and use the Babel extension to mark the languages you speak and to find other speakers of the same language in your wiki. And finally the cldr extension is a database of language and country translations. We are aiming to make new release every month, so that you can easily stay on the cutting edge with the constantly improving language support. The bundle comes with clear installation and upgrade installations. The bundle is tested against MediaWiki release versions, so you can avoid most of the temporary breaks that would happen if you were using the latest development versions instead. Because this is our first release, there can be some rough edges. Please provide us a lot of feedback so that we can improve for the next release. -Niklas -- Niklas Laxström

2 2

Fwd: IRC office hours about account creation and login redesign
by Steven Walling 28 Nov '12

28 Nov '12

FYI, for developers who might be interested. ---------- Forwarded message ---------- From: Steven Walling <swalling(a)wikimedia.org> Date: Wed, Nov 28, 2012 at 8:50 PM Subject: IRC office hours about account creation and login redesign To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Hi all, As you might have noticed, especially if you're an English Wikipedian, the Editor Engagement Experiments team has been working on redesigning the user experience of account creation, A/B testing new designs and functionality for the past couple months. We finished our final A/B test last week,[1] and we're now moving on to make the features which tested well permanent.[2] In order to make sure that the experience of signup and login are consistent, we also plan to make some changes to the design of login.[3] In order to answer any questions people might have and gather feedback, we're holding the first office hours about our redesign work. We also plan to enable the test version of the new account creation experience at 100% (rather than 50/50, as previously) so that people can give it a try. When: Saturday December 1, 2012. 19:00-20:00 UTC. Time conversion links etc. are on Meta.[4] Where: #wikimedia-office -- Steven Walling https://wikimediafoundation.org/ 1. https://meta.wikimedia.org/wiki/Research:Account_creation_UX 2. https://www.mediawiki.org/wiki/Account_creation_user_experience 3. https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Login 4. https://meta.wikimedia.org/wiki/IRC_office_hours -- Steven Walling https://wikimediafoundation.org/

3 2

Jump to page:

2025

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 November 2012