Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
Le 13/12/12 01:15, Sébastien Santoro a écrit : ASSIGNED seems perfect for me. It's ASSIGNED, this mean there are work going to be done, or done. Gerrit gives the detail. I must agree there. There is still one use case for which we do not really have a solution: find out bugs that do not have a patch in Gerrit. We have some keywords such as patch, patch-in-gerrit, patch-need-review, patch-reviewed thus I think the proposal is for us to switch from keywords to bug status. I never use the patch* keywords and would largely prefer using the bug status, that will assist me when triaging my bug lists. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
Le 13/12/12 02:27, Matthew Flaschen a écrit : People can look for the PATCH_IN_GERRIT status to find things to review. As you say, some changes are good, some are not. This is another way to attract reviewers to Gerrit changes. We can find patches to review in Gerrit. I think the proposal is more about finding out bugs in bugzilla that do or dont have a patch in Gerrit. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Running/testing Jenkins locally: presenting mkjenkins
Hello all, Turning my frustration into something more constructive has resulted in a script to download setup a local Jenkins install that mirrors the Wikimedia Jenkins install. This means it's now actually easy (or well, easier) to debug Jenkins issues to develop new jobs without access to WMF servers. mkjenkins [1] downloads Jenkins, the WMF Jenkins configuration (integration/jenkins.git, integration/jenkins-job-builder, integration/jenkins-job-builder-config) and installs the Jenkins job builder jobs. In addition, it patches around two configuration issues: - jobs assume Jenkins is in /var/lib/jenkins. This is symlinked to $HOME/.jenkins - the git config assumes there are Zuul repositories in /var/lib/zuul/git. These are re-written to the on-line gerrit repositories. Antoine suggested it might be interesting to make this into a Vagrant script, which would have the added advantage that it should be relatively easy to also include Zuul. However, my Vagrant-fu is weak and my hard drive full, so I'm not sure if I will have time to work on this anytime soon :-) Best. Merlijn [1] https://github.com/valhallasw/wikimedia-mkjenkins ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] mariadb 5.5 in production for english wikipedia
On Wed, 12 Dec 2012 06:45:24 -0800, Antoine Musso hashar+...@free.fr wrote: Le 12/12/12 01:10, Asher Feldman a écrit : This afternoon, I migrated one of the main production English Wikipedia slaves, db59, to MariaDB 5.5.28. Congratulations :-) Out of curiosity, have you looked at Drizzle too? IIRC Drizzle uses a completely different client and we'd need to write a new database class for it. ...something I've wished I could do for a long time. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile apps: time to go native?
On Tue, 11 Dec 2012 16:57:26 -0800, MZMcBride z...@mzmcbride.com wrote: David Gerard wrote: MZMcBride wrote: Perhaps mobile uploading could use better native support, but again, is the cost worth it? Does Commons need more low-quality photos? And even as phone cameras get better, do those photos need to be _instantly_ uploaded to the site? There's something to be said for waiting until you get home to upload photos, especially given how cumbersome the photo upload process is (copyright, permissions, categorization, etc.). And this all side-steps the question of whether there are better organizations equipped at handling photos (such as Flickr or whatever). This is a version of the general argument against participation. There are reasons it's not favoured. Oh come on now, that's not really fair. I'm not arguing against participation, I'm arguing against shitty photos. I was almost completely uninvolved, but I seem to remember much ado earlier this year about Wiki Loves Monuments and mobile support (it even had its own mobile app, I guess?). But looking at all of the WLM winners (https://commons.wikimedia.org/wiki/Wiki_Loves_Monuments_2012_winners), were any of them taken on mobile devices? A quick sampling seems to suggest that all of the good photos came from Nikon or Sony cameras. That isn't to say that mobile uploads (muploads) aren't ever going to be valuable to Wikimedia wikis, but it does raise the legitimate question of whether it's a good use of finite resources to support such projects. What is the value? MZMcBride Sorry but that smells like a red herring. First of all given a photography contest of course pro quality photos with pro cameras are going to dominate the list of winners. The winners of WLM are irrelevant to the topic of improving the quality and coverage of photos when ALL of the photos taken for WLM are available for use. A photo doesn't need to win WLM to be valuable to us. More importantly while quality is nice, that's not what's really important. More important than quality is coverage. Getting photos of those things that we don't have photos for. That is where mobile devices will always be superior than said Nikon or Sony cameras. Images of things taken spur of the moment no-one has taken an image of yet. Especially in remote areas, sudden events, etc... -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla attachment: too many redirects
I get a Too many redirects error when trying to open this attachement https://bug-attachment.wikimedia.org/attachment.cgi?id=11489 from this bug https://bugzilla.wikimedia.org/show_bug.cgi?id=42955 Anyone an idea? Cheers, Denny P.S.: I just saw that Daniel poste da bug on this https://bugzilla.wikimedia.org/show_bug.cgi?id=43061 -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Video on mobile: Firefox works, way is paved for more browser support
On Wed, 12 Dec 2012 11:35:40 -0800, David Gerard dger...@gmail.com wrote: On 12 December 2012 18:38, Michael Dale md...@wikimedia.org wrote: * No one is proposing turning off webm, an ideological commitment to support free access with free platforms in royalty free formats, does not necessarily require you exclude derivation to proprietary formats. This proposal is not about anything other than enhancing the shiny for owners of iOS devlces. While the devices are indisputable really lovely to use, this particular (shrinking) userbase does not constitute a group in any way lacking in access to anything we do, on any other device they own (and they do own other devices). The only reason you can't view anything other than H.264 on iOS devices is because Apple want to promote a given severely proprietary format on their locked-down devices. This is not a reason for Wikimedia to break principle. Mozilla is not an argument. Mozilla doing the wrong thing for directly commercial reasons is not any sort of argument for us to. It's only pressure from users that will get the companies to use unlocked formats. - d. Sorry, but this isn't just about iOS and wanting to lock into proprietary video formats. Hardware decoders for WebM are still rare. I hate H.264, but right now H.264 is the one format with hardware decoders in practically every device. And that's pretty important. Mobile devices are low power. Without native hardware decoding video playback is taxing on the CPU and has bad performance. And more importantly, it becomes a significant drain on the device's battery life. An utter sin for anyone targeting mobile. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile apps: time to go native?
On 13 December 2012 10:44, Daniel Friesen dan...@nadir-seen-fire.com wrote: More importantly while quality is nice, that's not what's really important. More important than quality is coverage. Getting photos of those things that we don't have photos for. That is where mobile devices will always be superior than said Nikon or Sony cameras. Images of things taken spur of the moment no-one has taken an image of yet. Especially in remote areas, sudden events, etc... Every article on a place needs a video, for example. (That's why we need to be able to ingest absolutely any rubbish a phone can produce and upload.) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] unit testing foreign wiki access
On 09.12.2012 00:50, Platonides wrote: Do you really need SQL access to wikidata? I would expect your code to go through a WikidataClient class, which could then connected to wikidata by sql, http, loading from a local file... Sure, but then I can't tests the code that does the direct cross-wiki database access :) -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikitech-l Digest, Vol 113, Issue 47
Confirm From: wikitech-l-requ...@lists.wikimedia.org wikitech-l-requ...@lists.wikimedia.org To: wikitech-l@lists.wikimedia.org Sent: Thursday, December 13, 2012 4:59 AM Subject: Wikitech-l Digest, Vol 113, Issue 47 Send Wikitech-l mailing list submissions to wikitech-l@lists.wikimedia.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/wikitech-l or, via email, send a message with subject or body 'help' to wikitech-l-requ...@lists.wikimedia.org You can reach the person managing the list at wikitech-l-ow...@lists.wikimedia.org When replying, please edit your Subject line so it is more specific than Re: Contents of Wikitech-l digest... Today's Topics: 1. Re: Bugzilla: Waiting for merge status when patch is in Gerrit? (S?bastien Santoro) 2. Re: Alpha version of the VisualEditor now available on the English Wikipedia (Roan Kattouw) 3. Re: Bugzilla: Waiting for merge status when patch is in Gerrit? (Antoine Musso) 4. Re: Bugzilla: Waiting for merge status when patch is in Gerrit? (Antoine Musso) 5. Running/testing Jenkins locally: presenting mkjenkins (Merlijn van Deen) 6. Re: mariadb 5.5 in production for english wikipedia (Daniel Friesen) 7. Re: Mobile apps: time to go native? (Daniel Friesen) 8. Bugzilla attachment: too many redirects (Denny Vrande?i?) 9. Re: Video on mobile: Firefox works, way is paved for more browser support (Daniel Friesen) -- Message: 1 Date: Thu, 13 Dec 2012 03:32:54 +0100 From: S?bastien Santoro dereck...@espace-win.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit? Message-ID: CAKg6iAFNZo8JXvNt97TJP=r64nwbaxod-q7kwxinubxgp80...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 13, 2012 at 2:27 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 12/12/2012 05:09 PM, Krinkle wrote: I agree with S?bastien. ASSIGNED is enough. I don't see the significance of whether there is a Gerrit change yet? If there is no Gerrit change, it doesn't mean nobody is working on it. And if there is a change, it may not be a good one and/or one written by someone else (e.g. someone else can give it a try, send the change-id to bugzilla, but the assignee hasn't reviewed it yet and/or abandoned it). People can look for the PATCH_IN_GERRIT status to find things to review. As you say, some changes are good, some are not. This is another way to attract reviewers to Gerrit changes. The Gerrit dashboard prints the first line of the change, which should begin by (bug 12345). So your view Bugs to review already exists in Gerrit dashboard. -- Best Regards, S?bastien Santoro aka Dereckson http://www.dereckson.be/ -- Message: 2 Date: Wed, 12 Dec 2012 19:20:16 -0800 From: Roan Kattouw roan.katt...@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia Message-ID: CALoQHwFy7XG_K5WDCmwjO0Jy=yfjtjhtohcn03fa2hiwpga...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 12, 2012 at 12:14 PM, Matthew Flaschen mflasc...@wikimedia.org wrote: I would definitely be willing to serve as a guinea pig, working to integrate ProveIt (http://en.wikipedia.org/wiki/User:ProveIt_GT). Awesome! Roan -- Message: 3 Date: Thu, 13 Dec 2012 09:05:55 +0100 From: Antoine Musso hashar+...@free.fr To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit? Message-ID: kac290$b28$1...@ger.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Le 13/12/12 01:15, S?bastien Santoro a ?crit : ASSIGNED seems perfect for me. It's ASSIGNED, this mean there are work going to be done, or done. Gerrit gives the detail. I must agree there. There is still one use case for which we do not really have a solution: find out bugs that do not have a patch in Gerrit. We have some keywords such as patch, patch-in-gerrit, patch-need-review, patch-reviewed thus I think the proposal is for us to switch from keywords to bug status. I never use the patch* keywords and would largely prefer using the bug status, that will assist me when triaging my bug lists. -- Antoine hashar Musso -- Message: 4 Date: Thu, 13 Dec 2012 09:06:50 +0100 From: Antoine Musso hashar+...@free.fr To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit? Message-ID: kac2ao$b28$2...@ger.gmane.org Content-Type: text/plain; charset=UTF-8 Le 13/12/12 02:27, Matthew Flaschen a ?crit : People can look for the
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On 2012-12-12 16:58, Chris McMahon wrote: Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki. Do you really mean http://test2.wikipedia.org? AFAIK the wikidata team uses this installation as a testing client for http://wikidata.org repository concerning the interwiki-links. Cheers Marco ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On Thu, Dec 13, 2012 at 8:59 AM, Marco Fleckinger marco.fleckin...@wikipedia.at wrote: On 2012-12-12 16:58, Chris McMahon wrote: Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki. Do you really mean http://test2.wikipedia.org? AFAIK the wikidata team uses this installation as a testing client for http://wikidata.org repository concerning the interwiki-links. Indeed. I think VE will be fine though. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
Hello, On 2012-12-12 20:04, James Alexander wrote: On Wed, Dec 12, 2012 at 8:57 AM, Andre Klapperaklap...@wikimedia.orgwrote: On Tue, 2012-12-11 at 19:30 -0800, James Forrester wrote: This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.[1] [1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback Playing the bad cop who's reading random feedback pages daily: As https://www.mediawiki.org/wiki/VisualEditor/Feedback also exists I wonder if the VisualEditor deployment on en.wp and its related feedback is so different from upstream that it needs a separate feedback page (instead of e.g. a soft redirect to the mw: one), or other reasons. Or does the en.wp one somehow make it easier for testers to report issues? When we deploy VE to other Wikipedias, will there also be separate VE feedback pages (maybe due to the different languages)? Note: I'm not criticizing it, I'm just trying to understand, and I'm picking VE as the most recent example. Thanks in advance for explaining, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ Risker said many of the reasons but the biggest reason is that a large portion of testers would not move wiki. Opening up a local spot for feedback drastically increases the amount of feedback you get which can be really helpful. Personally I think we should do it on as many wikis as we can for major projects like this but it's obviously difficult to do on many because of both the language barriers and watching too many feedback channels. Yet another thing that once a product like Echo works cross wiki it could be helpful for :) but that's a bit of a ways away. The Wikidata-Team lays focus on the testing on RTL-wikis. The first Wikipedia ever will be huwiki, because their community decided themselves to be the first. Itwiki wanted to be the second one, but the Wikidata-Team wanted to test RTL, therefore they asked the hewiki. Here I think i18n is very important as well, but I think it had already been tested many years ago. The PHP-regex-construct aka. wikiparser which is unidirectional has to be reimplemented by a real parser in JS. Implementing this is not very easy, but developers can may use some of the old ideas. Parsing the other way around has to be realized really from the scratch but is easier because everything is in a tree. not in a single text-string. Neither de- nor searalizing includes any surface, testing could be done automatically really easy comparing the results of conventional and the new parsing. The result of the serialization can be compared with the original markup. The components including surfaces will for sure need i18n. Using icons instead of texts in a menu can help getting around this issue very easily. Although using many icons we also need text, but IMHO this should be avoided, also in foresight to the need of translation. ;-) So this early version is for testing user's experience with this surface. I think this is really great and am impressed of the result it is a bit slow but, guys, it's still the alpha 1, what should I expect? It also does not work on all browsers, as mentioned. E.g. the latest Firefox (aka. Iceweasel) on Debian Wheezy (not yet released), is not supported. This is okay for me. I also think that people using outdated browsers should not have the same great experience. Everything necessary should work, but is the VE really essential? Cheers Marco ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Simplified Gerrit ACLs.
Hi everyone, As a result of some configuration we had to make for Jenkins (more on this to come), I've simplified the ACLs in all projects. Project Owners are now granted Verified and Code Review permissions at the All-Projects level. This was already the case in practice, but what I'm doing is going through all projects and removing Verified and CR permissions when the group is the same as the owner. I'll be finishing this off today, so you may see some ACLs continue to change for your repositories. Again: there should be no noticeable difference to most people, but if you encounter issues (like you can't review something you used to be able to), please let me know. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bikol Wikipedia logo issue
Hello, Can you help us fix the Wikipedia Logo on bcl.wikipedia.org ? The local community is asking for assistance. -- Roman Butch Bustria Jr. Vice President (2012-2013) Wikimedia Philippines Inc. -- The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments. Please consider the environment before printing this email. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikol Wikipedia logo issue
Hello, On 2012-12-13 16:35, Butch Bustria wrote: Can you help us fix the Wikipedia Logo on bcl.wikipedia.org ? The local community is asking for assistance. In the HTML-text background-size:contain; is missing for the a-tag containing the logo as background; You could also use a reduced resolution like eg. de.wikipedia.org. There a version in resolution 135x155 is used. You use 1650x1751. Cheers Marco ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikol Wikipedia logo issue
On Thu, Dec 13, 2012 at 11:35 AM, Butch Bustria bu...@wikimedia.org.ph wrote: Hello, Can you help us fix the Wikipedia Logo on bcl.wikipedia.org ? The local community is asking for assistance. Updating the file at [[bcl:File:Wiki.png]] is indeed the right way to change the logo. However the version recently uploaded has two problems: *It's too big, which means it will mostly be cut off. The image as uploaded must have the dimensions of 135x155. *There's no alpha channel. This is a minor issue, but will make the background not show through. How to add an alpha channel varies with software, and I'm sure that someone at commons would be willing to help with that aspect if needed. There's a second problem, in that the old logo is still showing up. This appears to be due to issues with squid cache not being purged (I've noticed there's been quite a few reports of this for re-uploads at commons. Additionally it seems like redirects really aren't getting their squid cache purged either. I don't know if anyone is currently investigating this or not...) Someone from ops might be able to manually purge the url //upload.wikimedia.org/wikipedia/bcl/b/bc/Wiki.png - or if all else fails $wgLogo could be changed to a different url to get around the caching issue. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla attachment: too many redirects
I also got this on attachments last night. (sorry to top post, on my mobile) On Dec 13, 2012 2:59 AM, Denny Vrandečić denny.vrande...@wikimedia.de wrote: I get a Too many redirects error when trying to open this attachement https://bug-attachment.wikimedia.org/attachment.cgi?id=11489 from this bug https://bugzilla.wikimedia.org/show_bug.cgi?id=42955 Anyone an idea? Cheers, Denny P.S.: I just saw that Daniel poste da bug on this https://bugzilla.wikimedia.org/show_bug.cgi?id=43061 -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla attachment: too many redirects
On Thu, 2012-12-13 at 09:52 -0800, Steven Walling wrote: I also got this on attachments last night. This was https://bugzilla.wikimedia.org/show_bug.cgi?id=43061 and I'm waiting for an answer by Reedy what the problem was exactly. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sauce Labs offers free accounts for open source projects
Announcing “Open Sauce,” free unlimited testing for Open Source projects: http://sauceio.com/index.php/2012/12/announcing-open-sauce-free-unlimited-testing-accounts-for-oss-projects/ This should make it easier for anyone to make use of https://github.com/wikimedia/qa-browsertests -- Ori Livneh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sauce Labs offers free accounts for open source projects
On Thu, Dec 13, 2012 at 7:21 PM, Ori Livneh o...@wikimedia.org wrote: This should make it easier for anyone to make use of https://github.com/wikimedia/qa-browsertests Chris will later today (at Weekly WMF Engineering Tech Talk) give a short demonstration of what we did so far. If you have any questions, feel free to ask here. Please let me know if this list is not appropriate place, we can move the discussion elsewhere. Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Proposal: MediaWiki Group Marketing
Hi, following the process for requesting the creation of a MediaWiki group, here is a proposal for MediaWiki Group Marketing http://www.mediawiki.org/wiki/Groups/Proposals/Marketing Your endorsements, improvements and feedback are welcome at the wiki page. Thank you! PS: see also http://www.mediawiki.org/wiki/Groups/Proposals -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Thu, 2012-12-13 at 02:09 +0100, Krinkle wrote: I agree with Sébastien. ASSIGNED is enough. I don't see the significance of whether there is a Gerrit change yet? See below. Plus as Bugzilla already has a patch-in-gerrit keyword (and other patch* ones) so somebody in the past had interest to identify bug reports that have a patch in Gerrit, for whatever reason. I'd like to know the reasons. Then we'd have to keep that in sync (back from this PENDING to ASSIGNED after the change is rejected?). Same currently with the patch-in-gerrit keyword, so neither better nor worse than before. Only more maintenance and bureaucracy for imho no obvious gain or purpose. A bug report that has a publically available initial patch, even if the patch still needs lots of rework, is closer to getting fixed than with no code at all. Plus old rotting patches might be another entry point for some people to pick up and contribute. The queryable state is ASSIGNED (and maybe, though I personally don't find it useful, the keyword patch-in-gerrit). And for any further details just open the bug and read it. ASSIGNED status is meant to express that somebody works on fixing a bug. Some assignees give up and forget to reset ASSIGNED. Nobody else can start working on it [2] and only the assignee her/himself could answer if s/he's still working on a bugfix. For patches at least *anybody* can easily query the status of a patch in Gerrit and see that it's rotting. The real status and progress is not only in somebody's head or on somebody's harddisk. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Wed, 2012-12-12 at 12:23 -0800, Rob Lanphier wrote: My 2cif we add a new status, it should equate to deployed on the cluster, along with judicious use of milestone so that people who are just interested in the tarball can infer from our numbering what the corresponding release will be. In the long run I see that rather done by integration between Gerrit and Bugzilla, e.g. adding an automatic Patch has been merged into codebase into branch $FOO which will end up as MediaWiki tarball 1.x.y. Availability of the fix on Wikimedia servers can take up to two weeks, see https://www.mediawiki.org/wiki/MediaWiki_1.21/Roadmap; comment in Bugzilla once a patch has been merged in Gerrit that refers to a bug ID. Something like https://bugzilla.wikimedia.org/show_bug.cgi?id=42150#c5 The more statuses (statii?) we add, the less likely they'll actually be a source of actual information. I'd like to have clarity and transparency which state a bug report is in. It's true that this requires acceptance. Currently not everybody uses the patch-in-gerrit keyword (for different reasons) and it's one step on the way to getting a bug fixed, so it should have never been a keyword anyway IMO. I sometimes run into bug reports that never got closed though the related Gerrit patch got merged a while ago. Personally I see some potential to make it easier for triagers to identify such forgotten tickets (and future might prove me wrong). That said, I know that many developers get confused about when they should mark things fixed, and hold off on doing so because things just get reopened with hey, it's still broken for me. We fail to explain deployments to users. I'd like to fix this too, but not in this step. To me: RESOLVED FIXED = patch got *merged* in Gerrit. I'd like the developers to be able to mark things off of their list when they're done with them That's exactly one reason why I bring this up. As quoted in my initial posting, see https://bugzilla.wikimedia.org/show_bug.cgi?id=42470#c4 - some developers want to exclude bug reports from queries when this reports have a patch for review in Gerrit. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On 12/13/2012 06:43 AM, Marco Fleckinger wrote: Implementing this is not very easy, but developers can may use some of the old ideas. Parsing the other way around has to be realized really from the scratch but is easier because everything is in a tree. not in a single text-string. Neither de- nor searalizing includes any surface, testing could be done automatically really easy comparing the results of conventional and the new parsing. The result of the serialization can be compared with the original markup. Hi Marco, we (the Parsoid team) have been doing many of the things you describe in the last year: * We wrote a new bidirectional parser / serializer - see http://www.mediawiki.org/wiki/Parsoid. This includes a grammar-based tokenizer, async/parallel token stream transformations and HTML5 DOM building. * We developed a HTML5 / RDFa document model spec at http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec. * Our parserTests runner tests wt2html (wikitext to html), wt2wt, html2html and html2wt modes with the same wikitext / HTML pairs as used in the PHP parser tests. We have roughly doubled the number of such pairs in the process. * Automated and distributed round-trip tests are currently run over a random selection of 100k English Wikipedia pages: http://parsoid.wmflabs.org:8001/. This test infrastructure can easily be pointed at a different set of pages or another wiki. Parsoid is by no means complete, but we are very happy with how far we already got since last October. Cheers, Gabriel -- Gabriel Wicke Senior Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
In my opinion Patch-in-gerrit is a distinct stage in the life cycle of a bug, and deserves its own status. A patch-in-gerrit does not mean the same thing as assigned. Assigned bugs are being worked on by someone. There work may or may not be publically visible yet. They are probably not at the stage where they want review of their work so far on the bug (obviously there are exceptions to that for complex bugs), etc. A patch-in-gerrit does mean that there is a fix for the bug available. It has not been reviewed yet. It needs people to test the patch/review/comment. It does not mean the bug is fixed (and definitely not deployed, but I agree that is a different discussion). If I downloaded a nightly version of MediaWiki the patch is not there. Some people may want to look for bugs with pending patches. At the very least, many people would want to know that there's a pending patch when bugzilla is displaying the list of bugs in the search window. In different life stages of a bug, different types of love need to be given to a bug. Thus the different stages should get different statuses. tl;dr /me really likes Andre's plan. p.s. This is not the first time this has come up - https://www.mediawiki.org/wiki/Thread:Talk:Git/Workflow/Bugzilla -- -Bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Video on mobile: Firefox works, way is paved for more browser support
On 12/13/2012 12:38 PM, Brion Vibber wrote: It's much, MUCH easier for us to flip the H.264 switch... there are ideological reasons we might not want to, but we're going to have to put the effort into making those player apps if we want all our data accessible to everyone. +1 its non trivial amount of effort to integrated native players across at least 3 major platforms, ( iOS, Android, Win8 ), And as pointed out in the thread, low power android / firefox OS devices include h.264 hardware decoders but will fail for medium resolution webm. I think Wikimedia mobile product needs to come up with some recommendations for the Board / community to evaluate. There are trade offs in effort and resource allocation. Is integrating software video decoders with native apps the best use of resources? or are there other higher priority efforts? Or more realistically, the ideological hard line, means kicking the proverbial video on Wikipedia bucket further down stream, which is also a trade off of sorts. --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Open Tech Chat stomorrow/s about NOW
Well, not really now, but starting in 15 minutes. Details at https://www.mediawiki.org/wiki/Meetings/2012-12-13 and below. What: Wikimedia Open Tech Chat Where: Google Hangout/#wikimedia-dev (keep an eye on IRC or [1] for the hangout URL) Moderator: Rob Lanphier (robla on IRC) Presenters: * Chris McMahon: An update on browser test automation * Amir Aharoni: Internationalisation dos and don'ts * Pau Giner: Multilingual user testing Cheers! On Wed, Dec 12, 2012 at 10:43 AM, Siebrand Mazeland (WMF) smazel...@wikimedia.org wrote: Hi there! Tomorrow at 20:30 UTC (12:30 PST, 21:30 CET, 02:00 IST) there will be another Wikimedia Open Tech Chat[1] on Google Hangout. This time there are three topics. I'd love to see you there. Please come! Topics: * An update by the Quality Assurance department on browser test automation * Internationalisation dos and don'ts: Why you should not merge your patch set, but request i18n/L10n review (Amir Aharoni) * Multilingual user testing for improving the Translate extension (Pau Giner) The Hangout URL will be published about 5 minutes in advance and QA can go through the #wikimedia-dev IRC channel on Freenode. If you're in San Francisco, consider joining in the flesh on the 6th floor of the Wikimedia Foundation SF office's Collab space. The session will last between 60 and 90 minutes. The session will be moderated by Rob Lanphier. [1] https://www.mediawiki.org/wiki/Meetings/2012-12-13 -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Simplified Gerrit ACLs.
I found that I no longer can +1 to operations (in this case operations/mediawiki-config, c38631). The only options are 0 and -1. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Simplified Gerrit ACLs.
I just noticed that I can no longer +1 on mediawiki/core, nor anywhere else. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Simplified Gerrit ACLs.
I'm looking at this now. -Chad On Thu, Dec 13, 2012 at 4:57 PM, Bartosz Dziewoński matma@gmail.com wrote: I just noticed that I can no longer +1 on mediawiki/core, nor anywhere else. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Open Tech Chat stomorrow/s about NOW
I tried to find the youtube archive link to this on https://www.mediawiki.org/wiki/Meetings/2012-12-13 but its set as TBD. Is the link up? --tomasz On Thu, Dec 13, 2012 at 12:11 PM, Siebrand Mazeland (WMF) smazel...@wikimedia.org wrote: Well, not really now, but starting in 15 minutes. Details at https://www.mediawiki.org/wiki/Meetings/2012-12-13 and below. What: Wikimedia Open Tech Chat Where: Google Hangout/#wikimedia-dev (keep an eye on IRC or [1] for the hangout URL) Moderator: Rob Lanphier (robla on IRC) Presenters: * Chris McMahon: An update on browser test automation * Amir Aharoni: Internationalisation dos and don'ts * Pau Giner: Multilingual user testing Cheers! On Wed, Dec 12, 2012 at 10:43 AM, Siebrand Mazeland (WMF) smazel...@wikimedia.org wrote: Hi there! Tomorrow at 20:30 UTC (12:30 PST, 21:30 CET, 02:00 IST) there will be another Wikimedia Open Tech Chat[1] on Google Hangout. This time there are three topics. I'd love to see you there. Please come! Topics: * An update by the Quality Assurance department on browser test automation * Internationalisation dos and don'ts: Why you should not merge your patch set, but request i18n/L10n review (Amir Aharoni) * Multilingual user testing for improving the Translate extension (Pau Giner) The Hangout URL will be published about 5 minutes in advance and QA can go through the #wikimedia-dev IRC channel on Freenode. If you're in San Francisco, consider joining in the flesh on the 6th floor of the Wikimedia Foundation SF office's Collab space. The session will last between 60 and 90 minutes. The session will be moderated by Rob Lanphier. [1] https://www.mediawiki.org/wiki/Meetings/2012-12-13 -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Simplified Gerrit ACLs.
This should be fixed for all users. -Chad On Thu, Dec 13, 2012 at 5:02 PM, Chad innocentkil...@gmail.com wrote: I'm looking at this now. -Chad On Thu, Dec 13, 2012 at 4:57 PM, Bartosz Dziewoński matma@gmail.com wrote: I just noticed that I can no longer +1 on mediawiki/core, nor anywhere else. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Open Tech Chat stomorrow/s about NOW
On Thu, Dec 13, 2012 at 11:27 PM, Tomasz Finc tf...@wikimedia.org wrote: Is the link up? http://youtu.be/RFC2A_zTQ3s Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Video on mobile: Firefox works, way is paved for more browser support
On Thu, Dec 13, 2012 at 10:38 AM, Brion Vibber bvib...@wikimedia.orgwrote: On Wed, Dec 12, 2012 at 2:50 PM, Rob Lanphier ro...@wikimedia.org wrote: I was able to play the WebM file of the locomotive on the front page of https://commons.wikimedia.org just now on my Nexus 7 using Chrome, so at least on very new stock Android devices, all is well. My much older Galaxy S didn't fare so well, though, so I would be willing to believe that Android devices with proper WebM support are still relatively rare. That said, the replacement rate for this hardware is frequent enough that it won't be long before my Nexus 7 is much older. I can play the current media on the front page of Commons in Chrome on my Nexus 7, but it won't play in position on either desktop http://en.wikipedia.org/wiki/Serge_Haroche or mobile http://en.m.wikipedia.org/wiki/Serge_Haroche ... Sigh. :) Still some work to be done on compatibility... I also notice that the source elements in the video seem to start with the original, and aren't labeled with types or codecs. This means that without the extra Kaltura player JS -- for instance as we see it on the mobile site right now -- the browser may not be able to determine which file is playable or best-playable. This may be contributing to the rrraaalllyyy slow performance I see on our FirefoxOS test device -- which understands Ogg Theora and WebM but has no hardware acceleration for them, and a relatively slow processor. If it's pulling a 1920x1080 original to play on a 320x480 screen, it's going to be slower than it needs to be. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] mariadb 5.5 in production for english wikipedia
On Wed, Dec 12, 2012 at 6:45 AM, Antoine Musso hashar+...@free.fr wrote: Le 12/12/12 01:10, Asher Feldman a écrit : This afternoon, I migrated one of the main production English Wikipedia slaves, db59, to MariaDB 5.5.28. Congratulations :-) Out of curiosity, have you looked at Drizzle too? I've spoken with Drizzle developers at OSCON in the past. I haven't seen anyone advocate it as a production quality database though, and it doesn't currently seem to have a lot of development momentum behind it, with Brian Aker no longer putting in a lot of time. Lots of interesting ideas and features, especially around replication, but they make it incompatible with MySQL in enough ways where a gradual migration wouldn't be practical even if it was otherwise desirable. -A ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Video on mobile: Firefox works, way is paved for more browser support
On Thu, Dec 13, 2012 at 2:56 PM, Brion Vibber bvib...@wikimedia.org wrote: I can play the current media on the front page of Commons in Chrome on my Nexus 7, but it won't play in position on either desktop http://en.wikipedia.org/wiki/Serge_Haroche or mobile http://en.m.wikipedia.org/wiki/Serge_Haroche ... On more careful testing, the *desktop* web site shows the video on the Nexus 7 (and 10) while the *mobile* site shows only a black rectangle when trying to play. I also notice that the source elements in the video seem to start with the original, and aren't labeled with types or codecs. This means that without the extra Kaltura player JS -- for instance as we see it on the mobile site right now -- the browser may not be able to determine which file is playable or best-playable. It looks like Chrome on Android 4+ (and MAYBE 2.3 but I can't verify it yet) plays WebM but not Ogg Theora. So on the desktop site, the JS finds the WebM sources and they play. On the mobile site (with no video JS available) the first source which is the Ogg Theora original gets selected by default and doesn't play. Adding 'type' attributes listing the file type and codecs used should allow Chrome to see the WebM versions and play them by itself, and get us working on newer Android devices in Chrome/Browser as well as Firefox... Filed as: https://bugzilla.wikimedia.org/show_bug.cgi?id=43101 Alternately or in addition, we could pull in some of the JS for the mobile site too, but we'll have to evaluate stuff. Whee! -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Video on mobile: Firefox works, way is paved for more browser support
On 12/13/2012 04:56 PM, Brion Vibber wrote: On Thu, Dec 13, 2012 at 10:38 AM, Brion Vibber bvib...@wikimedia.orgwrote: On Wed, Dec 12, 2012 at 2:50 PM, Rob Lanphier ro...@wikimedia.org wrote: I was able to play the WebM file of the locomotive on the front page of https://commons.wikimedia.org just now on my Nexus 7 using Chrome, so at least on very new stock Android devices, all is well. My much older Galaxy S didn't fare so well, though, so I would be willing to believe that Android devices with proper WebM support are still relatively rare. That said, the replacement rate for this hardware is frequent enough that it won't be long before my Nexus 7 is much older. I can play the current media on the front page of Commons in Chrome on my Nexus 7, but it won't play in position on either desktop http://en.wikipedia.org/wiki/Serge_Haroche or mobile http://en.m.wikipedia.org/wiki/Serge_Haroche ... Sigh. :) I think this relates to the page not being purged after the transcodes are updated. If you purge the page, will probably give the nexus a more playable flavour. http://en.wikipedia.org/wiki/Serge_Haroche should work on your nexus now ;) TMH should add page purge to the job queue, but not sure why that page had not been purged yet. Still some work to be done on compatibility... I also notice that the source elements in the video seem to start with the original, and aren't labeled with types or codecs. This means that without the extra Kaltura player JS -- for instance as we see it on the mobile site right now -- the browser may not be able to determine which file is playable or best-playable. For correctness we should include type. But I don't know if that will help, the situation you describe. https://gerrit.wikimedia.org/r/#/c/38665/ But certainly will help in the other ways you outline in the bug 43101 AFAIK there are no standard source tag attributes to represent device specific playback targets ( other than type ), so we set a few in data-* tags and read them within the kaltura html5 lib to do flavour selection. We of course use the Kaltura HTML5 lib on lots of mobile devices, so if you want to explore usage in the mobile app happy to support. For example including the payload into the application itself ( so its not a page view time ) peace, --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Video on mobile: Firefox works, way is paved for more browser support
On Thu, Dec 13, 2012 at 4:38 PM, Michael Dale md...@wikimedia.org wrote: I think this relates to the page not being purged after the transcodes are updated. If you purge the page, will probably give the nexus a more playable flavour. http://en.wikipedia.org/wiki/**Serge_Harochehttp://en.wikipedia.org/wiki/Serge_Harocheshould work on your nexus now ;) TMH should add page purge to the job queue, but not sure why that page had not been purged yet. Aha! That could explain it yes. I also notice that the source elements in the video seem to start with the original, and aren't labeled with types or codecs. This means that without the extra Kaltura player JS -- for instance as we see it on the mobile site right now -- the browser may not be able to determine which file is playable or best-playable. For correctness we should include type. But I don't know if that will help, the situation you describe. https://gerrit.wikimedia.org/**r/#/c/38665/https://gerrit.wikimedia.org/r/#/c/38665/ But certainly will help in the other ways you outline in the bug 43101 Awesome, thanks! I'll test it out and make sure it does what I expect... currently cloning MediaWiki again in my Linux VM so I can use libav on it without having to compile it under OSX (all the fun of old proprietary Unix under the hood!), so will probably test it a bit later. :) AFAIK there are no standard source tag attributes to represent device specific playback targets ( other than type ), so we set a few in data-* tags and read them within the kaltura html5 lib to do flavour selection. We of course use the Kaltura HTML5 lib on lots of mobile devices, so if you want to explore usage in the mobile app happy to support. For example including the payload into the application itself ( so its not a page view time ) I'll explore that as well. Spiffy! -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
