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 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 ------------------------------ Message: 5 Date: Thu, 13 Dec 2012 10:02:29 +0100 From: Merlijn van Deen <valhall...@arctus.nl> To: Wikimedia developers <wikitech-l@lists.wikimedia.org> Subject: [Wikitech-l] Running/testing Jenkins locally: presenting mkjenkins Message-ID: <CADJO0eKgmt5jE4OJdWk=ubiCJUPjuAt=vddzqg2tn-+pn0v...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 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 ------------------------------ Message: 6 Date: Thu, 13 Dec 2012 02:18:12 -0800 From: "Daniel Friesen" <dan...@nadir-seen-fire.com> To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] mariadb 5.5 in production for english wikipedia Message-ID: <op.wo82wm0ddykrql@daniels-macbook-air.local> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes 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/] ------------------------------ Message: 7 Date: Thu, 13 Dec 2012 02:44:48 -0800 From: "Daniel Friesen" <dan...@nadir-seen-fire.com> To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Mobile apps: time to go native? Message-ID: <op.wo834yf1dykrql@daniels-macbook-air.local> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes 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/] ------------------------------ Message: 8 Date: Thu, 13 Dec 2012 11:58:42 +0100 From: Denny Vrande?i? <denny.vrande...@wikimedia.de> To: MediaWiki Tech list <wikitech-l@lists.wikimedia.org> Subject: [Wikitech-l] Bugzilla attachment: too many redirects Message-ID: <cannnrrsj7guq8cte6pyledjrf2ci6z7osb2k6fuulcy9xrf...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 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. ------------------------------ Message: 9 Date: Thu, 13 Dec 2012 02:58:48 -0800 From: "Daniel Friesen" <dan...@nadir-seen-fire.com> To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Video on mobile: Firefox works, way is paved for more browser support Message-ID: <op.wo84saftdykrql@daniels-macbook-air.local> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes 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 End of Wikitech-l Digest, Vol 113, Issue 47 ******************************************* _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
