Confirm
________________________________
From: "wikitech-l-request(a)lists.wikimedia.org"
<wikitech-l-request(a)lists.wikimedia.org>
To: wikitech-l(a)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(a)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-request(a)lists.wikimedia.org
You can reach the person managing the list at
wikitech-l-owner(a)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 <dereckson(a)espace-win.org>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] Bugzilla: "Waiting for merge" status when
patch is in Gerrit?
Message-ID:
<CAKg6iAFNZo8JXvNt97TJP=r64NWbAxoD-q7KWxinuBxGp80eHA(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Dec 13, 2012 at 2:27 AM, Matthew Flaschen
<mflaschen(a)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.kattouw(a)gmail.com>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] Alpha version of the VisualEditor now
available on the English Wikipedia
Message-ID:
<CALoQHwFy7XG_K5WDCmwjO0Jy=yfJtjHTOHcN03FA2HiWPgakFA(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Dec 12, 2012 at 12:14 PM, Matthew Flaschen
<mflaschen(a)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(a)free.fr>
To: wikitech-l(a)lists.wikimedia.org
Subject: Re: [Wikitech-l] Bugzilla: "Waiting for merge" status when
patch is in Gerrit?
Message-ID: <kac290$b28$1(a)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(a)free.fr>
To: wikitech-l(a)lists.wikimedia.org
Subject: Re: [Wikitech-l] Bugzilla: "Waiting for merge" status when
patch is in Gerrit?
Message-ID: <kac2ao$b28$2(a)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(a)arctus.nl>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: [Wikitech-l] Running/testing Jenkins locally: presenting
mkjenkins
Message-ID:
<CADJO0eKgmt5jE4OJdWk=ubiCJUPjuAt=vdDzqg2tN-+Pn0vWVQ(a)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(a)nadir-seen-fire.com>
To: wikitech-l(a)lists.wikimedia.org
Subject: Re: [Wikitech-l] mariadb 5.5 in production for english
wikipedia
Message-ID: <op.wo82wm0ddykrql(a)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(a)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(a)nadir-seen-fire.com>
To: wikitech-l(a)lists.wikimedia.org
Subject: Re: [Wikitech-l] Mobile apps: time to go native?
Message-ID: <op.wo834yf1dykrql(a)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(a)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(a)wikimedia.de>
To: MediaWiki Tech list <wikitech-l(a)lists.wikimedia.org>
Subject: [Wikitech-l] Bugzilla attachment: too many redirects
Message-ID:
<CANnnRRsJ7GUq8CtE6PYLedJRF2ci6Z7osb2K6FUuLCY9xRfcrg(a)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(a)nadir-seen-fire.com>
To: wikitech-l(a)lists.wikimedia.org
Subject: Re: [Wikitech-l] Video on mobile: Firefox works, way is paved
for more browser support
Message-ID: <op.wo84saftdykrql(a)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(a)gmail.com> wrote:
On 12 December 2012 18:38, Michael Dale
<mdale(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 113, Issue 47
*******************************************