Wikitech-l April 2012

wikitech-l@lists.wikimedia.org

152 participants
188 discussions

Skipping the review step for certain extensions
by Jeroen De Dauw 08 Apr '12

08 Apr '12

Hey, Most of my extensions have been migrated to the new git setup with gerrit. I'm not happy with the workflow for the extensions where I'm basically the only real contributor or those where no one is going to review my stuff anyway. Although I can approve my own changes and merge them in, this is rather silly. Is there a way to disable the review step for certain extensions (ie post comit review instead of gated trunk), and is it possible to automatically merge in commits of certain users? For example in case of Semantic MediaWiki, I'd like my commits and those of the other core SMW devs to be merged in without first needing a review, while commits of random other people should require review first. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

3 3

Upload of OpenDocument files safe?
by Jean-Frédéric 08 Apr '12

08 Apr '12

Hi dear tech folks, The MediaWiki 1.18 release notes stated the following: “(bug 24230 [1]) Uploads of ZIP types, such as MS Office or OpenOffice can now be safely enabled. A ZIP file reader was added which can scan a ZIP file for potentially dangerous Java applets. This allows applets to be blocked specifically, rather than all ZIP files being blocked.” On the Wikimedia Commons village pump [2], concerns were still raised about security (some referred to macros specifically). Brion stated in 2008 that the ZIP issue was the only problem we had with OpenDocument upload [3], and TheDJ confirmed so in said thread; but let’s make it super-extra clear as for the technical side: * Is it completely safe to enable upload of OpenDocument files on Wikimedia Commons? * If not, would you advise us to restrict this type of uploads to trusted users? [4] With this confirmation, we can quietly discuss on Commons whether we want this or not :-) Thanks for your help! [1] <https://bugzilla.wikimedia.org/show_bug.cgi?id=24230> [2] < https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2012/03#Ena… > [3] < http://lists.wikimedia.org/pipermail/wikitech-l/2008-November/040246.html> [4] in the spirit of < https://commons.wikimedia.org/wiki/Commons:Restricted_uploads> -- Jean-Frédéric

3 2

Localisation commits status update
by Niklas Laxström 08 Apr '12

08 Apr '12

Good $localtime from translatewiki.net. I have been working with Chad and Antoine to resume the daily translation updates from translatewiki.net after the partial git migration of MediaWiki. We now have scripts that enable twn staff to * create clones of mediawiki core (with four branches: master 1.19 1.18 1.17) * create clones or all mediawiki extensions (both from svn and git, git taking precedence over git) * update those to latest versions * export translations * commit exported translations TL;DR: repo [create|update|export|commit] [mediawiki|mediawiki-extensions|...] The commmits for git will use the l10n-bot commit account. Commits for svn will continue to happen with our personal accounts. As you know every extension is now a separate git repository, there will be LOTS of commits instead of just one in a day. There are few remaining issues: * automatic merging of translation commits [BLOCKER] * not spamming your inbox with translation update commits * pretty formatting of core message files [BLOCKER] Now the last issue is something I want your opinion on: Is it an issue if we drop pretty formatting of non-English message files? If it is an issue, I request your help to make the maintenance/language/rebuildLanguage.php script to support arbitrary location instead of just the current wiki installation. If it is not an issue, the first diffs will be big because of the change, but remaining ones will be small as usual. -Niklas -- Niklas Laxström

5 5

Re: [Wikitech-l] Git/gerrit and RELEASE-NOTES-1.20 merge conflicts
by Harry Burt 08 Apr '12

08 Apr '12

On 05/04/12 10:53, Daniel Friesen wrote: > I thought this might be problematic to have everyone install. But > thinking about it again. Gerrit is the one doing merges. If that can > handle the RELEASE-NOTES format that we uses. Then theoretically > installing it on the server gerrit uses and then configuring our release > notes to use it could theoretically make Gerrit suddenly able to handle > RELEASE-NOTES changes without conflicts. Could we also make sure that Jenkins is upgraded with this functionality? e.g. for when Jenkins tests patchset n, where n > 1. Harry (User:Jarry1250)

1 0

Re: [Wikitech-l] GSoC -- TranslateSvg: Bringing the translation revolution to Wikimedia Commons
by Harry Burt 08 Apr '12

08 Apr '12

Hey all, thanks for your replies. Unfortunately I wasn't able to read them until today, so the "official" GSoC proposal has now been sent off. That said, I'm no less enthusiastic about reaching out to knowledgeable people involved with translation, and, if necessary, adapting the way GSoC works out (if my proposal is accepted) or the future roadmap for TranslateSvg generally (if it is not). So yes, comments still very much welcome :) I also have a few thoughts on what has been said already, and I'm hoping this can open up a dialogue (either on this list or bilaterally). Firstly, image "translation" isn't just (string) translation, which (as I understand it), is what the Translate extension focuses on. For example, it will involve users adjusting co-ordinates to ensure the image displays properly. It will involve changing formatting, including font size, and possibly bolding as well. It may even end up involving the selection of typefaces too. It will definitely involve an image preview. Is the architecture of the extension sufficiently high-level to accommodate these on a per-language basis, I wonder? If it is, then building on top of it sounds like a real possibility. Secondly, to respond to the question over Translatewiki.net, it is worth noting that the extraction and input of translatable strings into SVGs is non-trivial. If you imagine these as being hosted on Wikimedia Commons, a workflow taking in TranslateWiki.net would have, I think, to involve an intermediary storage area which TranslateWiki.net saves into, then a Wikipedia bot processing those, generating the new files and then uploading then daily/weekly onto Commons. That storage area would have to be populated by a second process. It's certainly doable, but it's tricky. Let's remember that there are 534,644 SVG files on Commons, suggesting that as many as 100,000 could end up being run through this process. Now, obviously, if we end up with 100,000s of new file versions uploaded, we are simply victims of our own success: but unlike interface translation it's not clear that even 1% of those updates will ever do any good at all - there's no known use case already in place. One solution could be to only pass SVGs being displayed in the "wrong" language on a wiki onto Translatewiki.net but, I'm keen that image translation be possible with immediacy. Although the lag-based process is neat, I would like casual users to be able to translate on-the-spot and with immediate effect, e.g. when they go to reuse a not-yet-translated SVG on their home wiki, without necessitating registration on Translatewiki.net and/or some kind of processing lag. There's probably a strong case for having *both* a local translation page - for casual users - *and* a Translatewiki.net process to allow for power translation. However, I would argue that the former is more important than the latter. To answer Gerard's query, I never intended the prototype to be properly reviewed, but it did generate an amount of attention and certainly fulfilled its role as a proof of concept. Regards, Harry (User:Jarry1250)

1 0

GSoC: Caterpillar the Category Tool
by Kalan 08 Apr '12

08 Apr '12

Hello, I present a proposal for a system that is going to solve the category intersection problem (and, in fact, allow all set-theory operations for categories). The name I suggest for it is “Caterpillar”. Such a system would consist of a C or C++ backend daemon that stores all the category graph in RAM and MediaWiki extension frontend. Here is the full text of the proposal: https://www.mediawiki.org/wiki/User:Kalan/gsoc I am seeking for an interested mentor. — Kalan

5 5

You are invited to join the wikiHow source code cleanup project
by Jack Phoenix 07 Apr '12

07 Apr '12

To those who don't know me yet, hi! I'm Jack Phoenix, and I've been a MediaWiki developer since May 2008. One of the major third-party users of the MediaWiki software is wikiHow ( http://www.wikihow.com/), a free how-to manual. In my opinion, wikiHow rocks! (No, I don't work for wikiHow and I never have.) However, wikiHow has one rather big problem. You can see it on their Special:Version. Yep... the site's running MediaWiki 1.12 (!), which is four years old. In software development, four years is an eternity. However, wikiHow's technical team is rather small and their codebase is full of custom extensions, patches and hacks -- as a result, they don't really have time for gigantic projects, such as upgrading the MediaWiki engine, let alone managing an open source project. Fortunately wikiHow publishes their source code at http://src.wikihow.comand a new dump will be generated each Monday. Inspired by this, a fellow developer and a friend of mine, Lewis Cawte (User:Lcawte) created a Google Code repository for the project. You can see the project page at http://code.google.com/p/wikihow/ Basically, the goal of this cleanup project is to update, fix, tweak and patch wikiHow extensions and related things created by wikiHow and make them work on the most recent stable release of MediaWiki (which is currently 1.18.1). In addition to that, the project provides a web-based viewer to see diffs between these weekly code releases. Upon a code release, the older source code dump is deleted from src.wikihow.com and there's no way to see what changed between two releases, if you don't have both source code dumps and GNU diff or some other diffing utility available. We hope that in time, when the project is complete, wikiHow.com can switch to this codebase and abandon the one based on MediaWiki 1.12. Right now we're managing the official code releases like this: *each Monday, when a release has been done, a new folder in tags directory is created (http://code.google.com/p/wikihow/source/detail?r=30), *the diff generated by "diff -ur older_release newest_release" is applied against the newly created tag ( http://code.google.com/p/wikihow/source/detail?r=31), *and eventually these changes are applied against trunk as needed ( http://code.google.com/p/wikihow/source/detail?r=39); right now this is very easy since most extensions haven't been cleaned up, but in time this will take more developer time, as the changes need to reviewed more carefully We're inviting anyone interested in MediaWiki development, wikiHow or both to join the project! There's /a lot/ of things to do and right now there are only two people working on it (me and Lewis); it's going to take a while for us to fix everything and still something might slip by us, so we're hoping to have more eyeballs on the code. The code repository is a SVN repo at http://wikihow.googlecode.com/svn/trunk/ and we're very liberal with commit access, just ask one of us for commit rights and you'll get 'em right away! (For those wondering why SVN and why Google Code, the answer is pretty simple: both of us are more familiar with SVN rather than any distributed version control system, and given that the Wikimedia Foundation is phasing out SVN in favour of git, we didn't want to use it to host this project.) If you have any questions, please don't hesitate to ask! On behalf of the wikiHow codebase cleanup project, Jack Phoenix & Lewis Cawte

8 8

Changes status in Gerrit
by Antoine Musso 07 Apr '12

07 Apr '12

Dear Gerrit users, Gerrit let us flag changes with two fields: - Code Review - Verified Anyone is allowed to +1/-1 the Code Review field but only a few people are allowed to mark a change as Verified. I have bring back Jenkins in action and it is now running tests for us, whenever a test suite is successful it marks it as Verified. What that means, is that a change could look fine (Verified + CR) and thus be merged by accident if someone with the correct right click the 'Submit Patch Set 1' button :-D With bots squatting the Verified field and anyone able to use the Code Review field, Gerrit has an hidden option to add an Approved status. That could be used by the people allowed to merge. On mediawiki/* we could end up with the following rights: * Verified : mostly flagged by bots, eventually by human doing manual tests for example when the change has not an automatic test case. * Code Review : anyone can +1/-1 * Approved : used as a safeguard to prevents people with merge rights to apply a change by mistake. The feature is used by OpenStack: https://review.openstack.org/ Some examples: https://review.openstack.org/#change,6164 https://review.openstack.org/#change,6196 -- Antoine "hashar" Musso

6 15

Growing our testing, bug reporting, & triaging community
by Sumana Harihareswara 07 Apr '12

07 Apr '12

Summary: Chris McMahon is following up on improving Labs as a testing environment, improving continuous integration, and learning from how mobile gets and uses bug reports. Alolita and I are gathering data about how our engineering teams currently take in bug reports from lots of communication media. A few of us just had a chat about some upcoming efforts to engage our community in systematic testing (QA) efforts -- see https://www.mediawiki.org/wiki/User_talk:Cmcmahon#Community_Testing.2FQA and http://www.mediawiki.org/wiki/Mobile_QA/Spec for the conversation-starter. I figured some folks on this list would be interested in some plans, ideas, and questions coming out of that. A non-comprehensive summary: * Chris thinks his biggest priority, to improve MediaWiki's testability overall, is to ensure Labs is a stable, robust, and consistent environment so it's reasonable to point a firehose of testing at the beta deployment cluster <http://labs.wikimedia.beta.wmflabs.org/> . Unless we ensure a consistent and clean environment, most of the bug reports will be the result of environment problems instead of the MediaWiki bugs we want to find. So that's what he's focusing most of his time on. (This limits the time he has available for manual testing of individual features, but he also makes time to work on editor engagement, Timed Media Handler testing, and a limited number of other key projects.) Of course automated testing is also key, so Chris is working with Antoine on deploying from Jenkins to the beta cluster -- see https://www.mediawiki.org/wiki/QA/testing and https://www.mediawiki.org/wiki/Thread:Talk:Continuous_integration/also_depl… . * Our mobile team has a pretty stable, if time-intensive, system set up to get tests of its apps. They release a new version of their app every 2 weeks. Several days beforehand, they release a beta. They email mobile-l, tweet, etc. to raise awareness, but the best way to actually get testers is to personalize the boilerplate email and send it personally to each of about 20 people who've shown interest in testing. It takes a few minutes to send those emails, and then 12-15 hours to respond to the feedback and dig into problems. Feedback and conversation usually comes from about 5 people out of that 20, and happens in IRC (so, it's not as easy to delegate, do asynchronously, point other people to, etc.). The mobile team also tries to cover some other feedback channels: https://www.mediawiki.org/wiki/User:Yuvipanda/Mobile_feedback_avenues Yuvi works on this 100% every release cycle, so it doesn't scale -- they couldn't really handle more testers if they came. Chris likes that the mobile team is clear and specific in directing its testers on what to test, and has reasonable constraints on time, number of testers, and test environment. For the next mobile release cycle (starting on April 6th) Chris will shadow Yuvi to see what he does and to start helping out. * The internationalisation/localisation team gets feedback (including bug reports and feature requests) through various channels (IRC, Village Pumps, Bugzilla, private email, Twitter, mailing lists, etc.), and it's time-intensive to gather, aggregate, triage, curate, and respond to it. Alolita is following up with the i18n team to get more details on that process -- how do they source feedback? Where do they get it, how do they aggregate it, and how much time does it take? I'll be following up with product managers to get similar step-by-step guides from other projects. That way we can figure out how much time it's taking, how to split up that workload among product managers and QA, and whether we can get some quick wins in systematizing this process and doing it smarter. (Separately from the feedback *aggregation* effort, various folks are investigating feedback *mechanisms* integrated into user-facing things. See https://www.mediawiki.org/wiki/Extension:MoodBar/Feedback for some thoughts on this.) * We really need help curating Bugzilla. Mark's Bug Squads can't come soon enough! :-) And we aim to grow testing leaders in the community. So if you're interested in stepping up and going from nitpicker to LEADER of nitpickers, we have some tasks ready for you. :D * Mozilla has a regular testing event https://quality.mozilla.org/category/events/month and lists bugs in an etherpad as they're reported: https://etherpad.mozilla.org/testday-20120329 . Time-limited test efforts like that are nice; if you can't constrain the number of channels people use to report things, you can at least constrain *time* and thus the amount of flow that comes through, so you can actually follow up more effectively! Chris doesn't think we quite have the social and technical infrastructure in place to properly support a testing event like this yet, but that's a goal. Thanks to Tomasz, Yuvi, Alolita, and Chris for contributing to this discussion. Additional reading: https://fedoraproject.org/wiki/User:Adamwill/It_boots_ship_it -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 1

Want to teach an online course in MediaWiki administration?
by Sumana Harihareswara 07 Apr '12

07 Apr '12

http://codelesson.com/courses/view/mediawiki-administration-and-development They'll help you develop the syllabus and curriculum, and you'd get paid. More info: http://codelesson.com/teach -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
19
Older →

Jump to page:

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