-- 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.kattouw@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=yfJtjHTOHcN03FA2HiWPgakFA@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 12, 2012 at 12:14 PM, Matthew Flaschen mflaschen@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+wmf@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+wmf@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 valhallasw@arctus.nl To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] Running/testing Jenkins locally: presenting     mkjenkins Message-ID:     CADJO0eKgmt5jE4OJdWk=ubiCJUPjuAt=vdDzqg2tN-+Pn0vWVQ@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" daniel@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+wmf@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" daniel@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.vrandecic@wikimedia.de To: MediaWiki Tech list wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] Bugzilla attachment: too many redirects Message-ID:     CANnnRRsJ7GUq8CtE6PYLedJRF2ci6Z7osb2K6FUuLCY9xRfcrg@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" daniel@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 dgerard@gmail.com wrote: > On 12 December 2012 18:38, Michael Dale mdale@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 *******************************************