date:20150722

Re: [Wikitech-l] Min php version

2015-07-22 Thread Erik Bernhardson

On Tue, Jul 21, 2015 at 1:22 PM, Gergo Tisza gti...@wikimedia.org wrote:

 On Tue, Jul 21, 2015 at 11:27 AM, Tyler Romeo tylerro...@gmail.com
 wrote:

  One thing I forgot to mention: while you're considering Debian and Ubuntu
  support, make sure to also take into account MediaWiki support.
 
  Even if we upgrade our minimum PHP version now, older versions of
  MediaWiki with the 5.3 requirement will still be supported and receive
  security updates. So the only difference will be that people running
 Debian
  oldstable will be locked into our older version and not be able to
 upgrade
  to bleeding edge MediaWiki, which they probably won't do anyway
 considering
  they haven't even upgraded their Debian. :P


 Specifically, 1.23, which is the current LTS (long-term support) release,
 is supported until May 2017 (so that covers Debian/Ubuntu and almost covers
 RedHat, but that one provides PHP 5.5 anyway).

 The next LTS is due spring 2016 and will be supported until spring 2019 and
 I don't think we want to get stuck on PHP 5.3 with that one.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l


I don't have a whole lot to add to this argument, but the above statement
rings very true to me. I think it would be a big misstep to continue
supporting 5.3 until 2019.

Erik B.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Changes require Verified+2 to be merged by CI

2015-07-22 Thread Antoine Musso

Hello,

I have upgraded Zuul this morning which has a slight regression.  To be
considered for merging, Zuul require the change to have a Verified +2.

In most case that is not a problem since the tests ran and voted V+2
already.  But there is a few other cases where Verified is 0 or -1.


The workaround is thus to manually vote Verified +2 in addition to
Code-Review +2.  You might have to remove the prior CR+2 to have the
change properly recognized.


The task is:
https://phabricator.wikimedia.org/T106531

Will give it a shot tomorrow.

-- 
Antoine hashar Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Geolocation and WikiVoyage

2015-07-22 Thread Petr Kadlec

Hi,

On Wed, Jul 22, 2015 at 5:10 PM, Sylvain Arnouts sylvain.arno...@wanadoo.fr
 wrote:

 Actually, it's the same for other languages, but the API has a very
 specific way to manage languages in request.

 To have the datas in different languages, we have to call the langlinks
 props in the url, and then do llprop=url to have the url of the page for
 each languages. This is the final request I send to the API :
 $wikivoyageRequest = 
 https://en.wikivoyage.org/w/api.php?action=queryformat=json; //Base
 .prop=coordinates|info|langlinks//Props list
 .inprop=url //Properties dedicated
 to url
 .llprop=url//Properties dedicated
 to langlinks
 .generator=geosearchggscoord=$user_latitude|$user_longitudeggsradius=1ggslimit=50;
 //Properties dedicated to geosearch

 The answer contains every link for every language, so I guess it solves my
 problem.


Well, that depends on what exactly is your problem. The query you have
shown here is find all articles within the radius on the English
Wikivoyage, and give me the versions of those English articles in other
languages, if they exist. However, if you try e.g. 
https://en.wikivoyage.org/w/api.php?action=queryprop=coordinates|infoinprop=urlgenerator=geosearchggscoord=46.016667|-1.175ggsradius=1ggslimit=50ggsradius=1ggslimit=50,
you'll find nothing, even though there is an article about Île d'Aix (lying
on those coordinates) on the French and German Wikivoyages, which you
_will_ find using 
https://de.wikivoyage.org/w/api.php?action=queryprop=coordinates|infoinprop=urlgenerator=geosearchggscoord=46.016667|-1.175ggsradius=1ggslimit=50ggsradius=1ggslimit=50
(and you would find it also on French Wikivoyage, if it had the
{{#coordinates}} I wrote about in the previous message).

In other words, you are searching _only_ within English Wikivoyage articles
with the query you posted above. Whether that is enough for you, I cannot
decide.

HTH,
-- [[cs:User:Mormegil | Petr Kadlec]]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Geolocation and WikiVoyage

2015-07-22 Thread Sylvain Arnouts


Thanks for your help !

Actually, it's the same for other languages, but the API has a very 
specific way to manage languages in request.


To have the datas in different languages, we have to call the langlinks 
props in the url, and then do llprop=url to have the url of the page for 
each languages. This is the final request I send to the API :
$wikivoyageRequest = 
https://en.wikivoyage.org/w/api.php?action=queryformat=json; //Base

.prop=coordinates|info|langlinks//Props list
.inprop=url //Properties 
dedicated to url
.llprop=url//Properties 
dedicated to langlinks
.generator=geosearchggscoord=$user_latitude|$user_longitudeggsradius=1ggslimit=50; 
//Properties dedicated to geosearch


The answer contains every link for every language, so I guess it solves 
my problem.


Thanks a lot for helping me, I'll show you my project when it's over ! :)

Le 22/07/2015 15:44, Petr Kadlec a écrit :

On Wed, Jul 22, 2015 at 9:09 AM, Sylvain Arnouts sylvain.arno...@wanadoo.fr

wrote:
But I still have some issues. I'm trying to use it in different languages.
It works in english, but I'd like to have results from the french version
of Wikivoyage. I don't know why, it doesn't work by calling
https://fr.wikivoyage.org/w/api.php? ... same request. I've no answer,
even if the page actually exists.


For this feature to work, the page obviously needs to know its coordinates.
The English page does 
https://en.wikivoyage.org/w/api.php?action=queryprop=coordinatestitles=Lille
while the French page does not 
https://fr.wikivoyage.org/w/api.php?action=queryprop=coordinatestitles=Lille.
The coordinates are stored into the page properties using the
{{#coordinates:}} special function, see 
https://www.mediawiki.org/wiki/Extension:GeoData#Usage. On English
Wiktionary, this function is called using the {{Geo}} template (see 
https://en.wikivoyage.org/w/index.php?title=Template:Geoaction=edit). On
the French Wiktionary, the function should probably be called in {{Info
Ville}} or {{Geo}}, I guess.

HTH,
-- [[cs:User:Mormegil | Petr Kadlec]]
___
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

[Wikitech-l] Phabricator board: reading-admin

2015-07-22 Thread Adam Baso

Hi all - you've probably seen the reading-web, android, and ios related
boards in Phabricator, but I wanted to share another with you:

https://phabricator.wikimedia.org/tag/reading-admin/

This is a place the Reading management team adds and tracks more manager
oriented tasks.

As tasks get moved to Done, we will in the future probably actually want to
check into whether they should be moved farther left in the board to be
repeated / re-reviewed or figure out some appropriate lightweight workflow
for such things.

-Adam
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Adding extensions under packagist's mediawiki vendor

2015-07-22 Thread Chad

On Wed, Jul 22, 2015 at 7:13 AM Federico Leva (Nemo) nemow...@gmail.com
wrote:

 Gerrit is too unpredictable for users:
 https://phabricator.wikimedia.org/T86476#1462980 .
 It's probably easier and more functional to create some
 mediawiki-users vendor on packagist and let any MediaWiki sysadmin
 (not developer) join to add the packages they need for whatever reason.


Forcing people to use Gerrit is quite possibly a violation of the Geneva
Convention.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes require Verified+2 to be merged by CI

2015-07-22 Thread Krinkle

 On 22 Jul 2015, at 09:28, Antoine Musso hashar+...@free.fr wrote:
 
 Hello,
 
 I have upgraded Zuul this morning which has a slight regression.  To be
 considered for merging, Zuul require the change to have a Verified +2.
 
 In most case that is not a problem since the tests ran and voted V+2
 already.  But there is a few other cases where Verified is 0 or -1.
 

This primarily affects cases where:

* Someone CR+2's a change that is so new it doesn't have the V-vote from 
jenkins-bot yet.

* Someone CR+2's a change that was previously failing but is now fixed and 
jenkins is still running the build.

So this breaks cases where someone does a provisional CR+2 with the concurrent 
dependency that Jenkins will pass.

 
 The workaround is thus to manually vote Verified +2 in addition to
 Code-Review +2.  You might have to remove the prior CR+2 to have the
 change properly recognized.
 
 

Please don't (and in many repos, people can't). This bypasses Jenkins and 
causes other inconsistencies. Instead wait until Jenkins is done and then CR+2 
it.

-- Krinkle


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MW support for Composer equivalent for JavaScript packages

2015-07-22 Thread Daniel Werner

Hey,

I just wanted to check in about the status of enabling JavaScript package
management usage in MediaWiki. I am basically talking about an equivalent
for JS to what we have with Composer for PHP.

Real-world example:
  The data-values/value-view package[0] is defining
jquery.event.special.eachchange.js:
ValueView/lib/jquery.event/jquery.event.special.eachchange.js

  Now, recently I needed the same functionality in one of my extensions, so
I just copied it over. [1]

I know that this is the worst way one could do this, but as far as I can
see we don't have that much of a choice right now. Here are the alternative
options I can see:

Moving jquery.event.special.eachchange.js out of the
data-values/value-view package into its own WMDE/jquery-eachchange
package...

1. ... and using it in my extension via composer.
  + pro: two or more extensions or other packages requiring this package
will still result in having only one MW-wide installation..
  - con: requires MW specific code which is actually not related to the
MW-independent package to feed the resource loader.
  - con: using Composer to manage pure JavaScript packages! Uuuh, ugly!

2. ... and having a build step in other packages using the package, pulling
the WMDE/jquery-eachchange somewhere into the file structure of the
packages/extensions using it.
  + pro: don't need to abuse composer, we can use npm, Bower or any
other arbitrary JS package manager here.
  - con: got to tell resource loader somehow... (didn't think so much about
that yet)
  - con: if more than one extensions or other packages require this package
we still end up with the same code twice or more often in one MW
installation.

3. Combining 1 and 2: Start with 2, using a JS package manager. Then going
to 1, creating a composer package and pulling the WMDE/jquery-eachchange
package in via some build script.
  + pro: The two pros from 1 + 2
  + pro: ^^
  - con: still got to tell resource loader somehow...
  - con: Overhead; We now create two packages where the Composer one is
just a bridge to the MW-world, still polluting packagist.org. Still kind of
ugly and more effort for publishing a package and therefore potentially
scaring programmers away from doing so since they've got better things to
do than doing work that could be automated.

I have not seen Approach 2 and 3 yet. Though I could imagine that the
VisualEditor team has used something like that.
Approach 1 is the way the data-values/value-view package itself is being
handled. And that package should actually be a MW independent pure JS
package but right now it contains MW specific code and uses composer for
distribution!
There is still another option but that had to be properly implemented:

4. Choose one native JS package manager for now and go with it (add support
for others later perhaps). Integrate it properly with MW (resource loader
to begin with), document how to use it and finally distribute JS code
coming from the MW world but useful for other projects in a way where it
can actually be used in a non-MW context.

This has already been bugging me when working on Wikidata. Now I'd like to
reuse some of the code I have written there without spending hours and
hours with option 3 because there should be support for option 4 rather
sooner or later.
So I am wondering; Does anyone have any thoughts, any alternatives perhaps
or is there any roadmap on anything like the option 4 that I have shown?

Cheers,
Daniel

[0]: https://packagist.org/packages/data-values/value-view
[1]:
https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses/blob/master/resources/vendor/jquery.event.special.eachchange.js
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-22 Thread Brian Gerstle


 I have no problem with that, as long as everyone with +2 keeps his access


This should already be the case for the main iOS engineers, but I've made a
ticket https://phabricator.wikimedia.org/T106547 to make sure people
don't slip through the cracks.

Oh, and when
 it syncs with phabricator tickets


Phabricator ticket sync is something we're sad to lose, but it's part of
the trade-off we're making.  That said, it was only slightly beneficial as
we relied more on cards being in a Code Review column (w/ a WIP limit)
than looking at the gerrit updates on the cards themselves (which aren't
visible from the board view).  Not that GH will make this any easier, but
we're not losing too much here, IMHO.

On Wed, Jul 22, 2015 at 8:01 AM, Derk-Jan Hartman 
d.j.hartman+wmf...@gmail.com wrote:

 I have no problem with that, as long as everyone with +2 keeps his access
 and someone manages developer account additions and removals. Oh, and when
 it syncs with phabricator tickets

 DJ

 On Wed, Jul 22, 2015 at 1:39 PM, Petr Bena benap...@gmail.com wrote:

  Good job, you aren't the only one. Huggle team is using it for quite
  some time. To be honest I still feel that github is far superior to
  our gerrit installation and don't really understand why we don't use
  it for other projects too.
 
  The GitHub's pull requests are more compliant with original git
  philosophy of Linus, see this video:
  https://www.youtube.com/watch?v=4XpnKHJAok8 and would be sufficient
  replacement to our current git-review mechanism, which is very
  complex and unfriendly to new developers who probably find it very
  difficult to use.
 
  On Wed, Jul 22, 2015 at 12:40 PM, Brian Gerstle bgers...@wikimedia.org
  wrote:
   Hey everyone,
  
   I'm writing with plans for the Wikimedia iOS engineering team to move
 its
   workflow to GitHub with Travis CI, much like RESTbase.
  
   The Wikimedia iOS engineers have been maintaining their own CI and
 build
   server and using Gerrit for code review. The more time efficient and
   commonplace approach for open source iOS software development leans
  heavily
   on GitHub with Travis CI instead (e.g., WordPress[0][1] and
  Firefox[2][3]).
   By using GitHub with Travis CI, the team believes it will work faster,
   improve testing, grow developer confidence in making code changes, and,
   most importantly, deploy fewer bugs to production.
  
   For builds requiring sensitive information (e.g., prod certs), will
   continue to run on WMF's Mac Mini. As is done for Android, when betas
 are
   pushed, the team will notify mobile-l.
  
   Feel free to reply or email me directly with any questions or comments.
  
   Regards,
  
   Brian
  
   0: https://github.com/wordpress-mobile/WordPress-iOS
   1: https://travis-ci.org/wordpress-mobile/WordPress-iOS
   2: https://github.com/mozilla/firefox-ios
   3: https://travis-ci.org/mozilla/firefox-ios
  
   --
   EN Wikipedia user page:
 https://en.wikipedia.org/wiki/User:Brian.gerstle
   IRC: bgerstle
   ___
   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
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] FYI: HTMLForm is now available in OOUI format

2015-07-22 Thread Daniel Werner

Great work!
I have noticed that the ooui HTMLForm format is also not supporting a
form field's hide-if expressions yet.

Cheers,
Daniel

On 22 July 2015 at 16:06, Florian Schmidt 
florian.schmidt.wel...@t-online.de wrote:

 Yay :D

 Sent from my HTC

 - Reply message -
 From: Bartosz Dziewoński matma@gmail.com
 To: Wikimedia developers wikitech-l@lists.wikimedia.org
 Subject: [Wikitech-l] FYI: HTMLForm is now available in OOUI format
 Date: Wed, Jul 22, 2015 15:45

 It took a while, but most of the issues are ironed out now. OOUI still
 doesn't support subsections, as that would require some refactoring of
 gnarly old code. Everything else should work well enough.

 --
 Bartosz Dziewoński

 ___
 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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-22 Thread Ricordisamoa


 * CR fragmentation
 * CI fragmentation
 * more reliance on proprietary software


Il 22/07/2015 12:40, Brian Gerstle ha scritto:

Hey everyone,

I'm writing with plans for the Wikimedia iOS engineering team to move its
workflow to GitHub with Travis CI, much like RESTbase.

The Wikimedia iOS engineers have been maintaining their own CI and build
server and using Gerrit for code review. The more time efficient and
commonplace approach for open source iOS software development leans heavily
on GitHub with Travis CI instead (e.g., WordPress[0][1] and Firefox[2][3]).
By using GitHub with Travis CI, the team believes it will work faster,
improve testing, grow developer confidence in making code changes, and,
most importantly, deploy fewer bugs to production.

For builds requiring sensitive information (e.g., prod certs), will
continue to run on WMF's Mac Mini. As is done for Android, when betas are
pushed, the team will notify mobile-l.

Feel free to reply or email me directly with any questions or comments.

Regards,

Brian

0: https://github.com/wordpress-mobile/WordPress-iOS
1: https://travis-ci.org/wordpress-mobile/WordPress-iOS
2: https://github.com/mozilla/firefox-ios
3: https://travis-ci.org/mozilla/firefox-ios



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: Wikipedia iOS app moving to GH

2015-07-22 Thread Brian Gerstle

sorry, didn't hit reply-all. (these lists aren't a subset of each other,
are they?)

Also, we're losing IRC notifications, but that should be easy enough to add
back via fastlane.

-- Forwarded message --
From: Brian Gerstle bgers...@wikimedia.org
Date: Wed, Jul 22, 2015 at 12:59 PM
Subject: Re: [Wikitech-l] Wikipedia iOS app moving to GH
To: Wikimedia developers wikitech-l@lists.wikimedia.org

I have no problem with that, as long as everyone with +2 keeps his access

This should already be the case for the main iOS engineers, but I've made a
ticket https://phabricator.wikimedia.org/T106547 to make sure people
don't slip through the cracks.

Oh, and when
 it syncs with phabricator tickets

Phabricator ticket sync is something we're sad to lose, but it's part of
the trade-off we're making.  That said, it was only slightly beneficial as
we relied more on cards being in a Code Review column (w/ a WIP limit)
than looking at the gerrit updates on the cards themselves (which aren't
visible from the board view).  Not that GH will make this any easier, but
we're not losing too much here, IMHO.

On Wed, Jul 22, 2015 at 8:01 AM, Derk-Jan Hartman 
d.j.hartman+wmf...@gmail.com wrote:

 I have no problem with that, as long as everyone with +2 keeps his access
 and someone manages developer account additions and removals. Oh, and when
 it syncs with phabricator tickets

 DJ

 On Wed, Jul 22, 2015 at 1:39 PM, Petr Bena benap...@gmail.com wrote:

  Good job, you aren't the only one. Huggle team is using it for quite
  some time. To be honest I still feel that github is far superior to
  our gerrit installation and don't really understand why we don't use
  it for other projects too.

  The GitHub's pull requests are more compliant with original git
  philosophy of Linus, see this video:
  https://www.youtube.com/watch?v=4XpnKHJAok8 and would be sufficient
  replacement to our current git-review mechanism, which is very
  complex and unfriendly to new developers who probably find it very
  difficult to use.

  On Wed, Jul 22, 2015 at 12:40 PM, Brian Gerstle bgers...@wikimedia.org
  wrote:
   Hey everyone,

   I'm writing with plans for the Wikimedia iOS engineering team to move
 its
   workflow to GitHub with Travis CI, much like RESTbase.

   The Wikimedia iOS engineers have been maintaining their own CI and
 build
   server and using Gerrit for code review. The more time efficient and
   commonplace approach for open source iOS software development leans
  heavily
   on GitHub with Travis CI instead (e.g., WordPress[0][1] and
  Firefox[2][3]).
   By using GitHub with Travis CI, the team believes it will work faster,
   improve testing, grow developer confidence in making code changes, and,
   most importantly, deploy fewer bugs to production.

   For builds requiring sensitive information (e.g., prod certs), will
   continue to run on WMF's Mac Mini. As is done for Android, when betas
 are
   pushed, the team will notify mobile-l.

   Feel free to reply or email me directly with any questions or comments.

   Regards,

   Brian

   0: https://github.com/wordpress-mobile/WordPress-iOS
   1: https://travis-ci.org/wordpress-mobile/WordPress-iOS
   2: https://github.com/mozilla/firefox-ios
   3: https://travis-ci.org/mozilla/firefox-ios

   --
   EN Wikipedia user page:
 https://en.wikipedia.org/wiki/User:Brian.gerstle
   IRC: bgerstle
   ___
   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
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- 
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle

-- 
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Geolocation and WikiVoyage

2015-07-22 Thread Sylvain Arnouts


Hi.

You're right, I didn't think about it. So to have all result, I have to 
call all API on each Wikivoyage version ?


Thank you.

Le 22/07/2015 17:51, Petr Kadlec a écrit :

Hi,

On Wed, Jul 22, 2015 at 5:10 PM, Sylvain Arnouts sylvain.arno...@wanadoo.fr

wrote:
Actually, it's the same for other languages, but the API has a very
specific way to manage languages in request.

To have the datas in different languages, we have to call the langlinks
props in the url, and then do llprop=url to have the url of the page for
each languages. This is the final request I send to the API :
 $wikivoyageRequest = 
https://en.wikivoyage.org/w/api.php?action=queryformat=json; //Base
.prop=coordinates|info|langlinks//Props list
 .inprop=url //Properties dedicated
to url
 .llprop=url//Properties dedicated
to langlinks
.generator=geosearchggscoord=$user_latitude|$user_longitudeggsradius=1ggslimit=50;
//Properties dedicated to geosearch

The answer contains every link for every language, so I guess it solves my
problem.


Well, that depends on what exactly is your problem. The query you have
shown here is find all articles within the radius on the English
Wikivoyage, and give me the versions of those English articles in other
languages, if they exist. However, if you try e.g. 
https://en.wikivoyage.org/w/api.php?action=queryprop=coordinates|infoinprop=urlgenerator=geosearchggscoord=46.016667|-1.175ggsradius=1ggslimit=50ggsradius=1ggslimit=50,
you'll find nothing, even though there is an article about Île d'Aix (lying
on those coordinates) on the French and German Wikivoyages, which you
_will_ find using 
https://de.wikivoyage.org/w/api.php?action=queryprop=coordinates|infoinprop=urlgenerator=geosearchggscoord=46.016667|-1.175ggsradius=1ggslimit=50ggsradius=1ggslimit=50
(and you would find it also on French Wikivoyage, if it had the
{{#coordinates}} I wrote about in the previous message).

In other words, you are searching _only_ within English Wikivoyage articles
with the query you posted above. Whether that is enough for you, I cannot
decide.

HTH,
-- [[cs:User:Mormegil | Petr Kadlec]]
___
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] Min php version

2015-07-22 Thread Krinkle

On 20 Jul 2015, at 22:42, Legoktm legoktm.wikipe...@gmail.com wrote:

OTOH, if we never bump our version requirements, there's less incentive
for hosting providers to upgrade their PHP. [1] has some interesting
arguments regarding this.

[1] http://blog.ircmaxell.com/2014/12/on-php-version-requirements.html

Indeed. Providers that don't already provide newer PHP options, will certainly
start doing so when major software requires it.

On 21 Jul 2015, at 07:12, bawolff bawolff...@gmail.com wrote:

https://wikiapiary.com/w/index.php?title=Special:SearchByPropertylimit=500offset=0property=Has+PHP+Versionvalue=5.3.3
is also something to keep in mind

Yes, but also keep in mind that many of those wikis likely run in hosting
environments that already support newer PHP versions. But customers won't
change their settings until they have to. And providers can't change
customers proactively without risking site breakage or damaging customer
relations.

I had the same with my third-party wikis. Until recently they ran on PHP
5.3. Then at some point I realised my provider had a simple Select PHP
Version page in the control panel. I switched them all to PHP 5.6 that day
and also enabled opcache. Site performance improved greatly.

On 19 Jul 2015, at 07:15, Bryan Davis bd...@wikimedia.org wrote:

Some WMF production hosts are still on PHP 5.3.10 so as Tim pointed
out last spring [0] we shouldn't drop 5.3 support until after the
entirety of the WMF server fleet are all switched over to HHVM or at
least a newer version of PHP5. [..]

[0]: http://www.gossamer-threads.com/lists/wiki/wikitech/436441#436441

Yeah, in case of Wikimedia master is near-immediate production so
let's post-pone this until right after Wikimedia's migration is complete.

Third parties can stick to using the LTS or the current stable version
as needed for upto several years more without issue.

-- Krinkle

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Min php version

2015-07-22 Thread Eran Rosenthal

side note: How come php 5.3.3 support broken accidentally? Isn't Jenkins
script validates compatibility with the min php? :)

On Wed, Jul 22, 2015 at 9:36 PM, Krinkle krinklem...@gmail.com wrote:

On 20 Jul 2015, at 22:42, Legoktm legoktm.wikipe...@gmail.com wrote:

OTOH, if we never bump our version requirements, there's less incentive
for hosting providers to upgrade their PHP. [1] has some interesting
arguments regarding this.

[1] http://blog.ircmaxell.com/2014/12/on-php-version-requirements.html

Indeed. Providers that don't already provide newer PHP options, will
certainly
start doing so when major software requires it.

On 21 Jul 2015, at 07:12, bawolff bawolff...@gmail.com wrote:

https://wikiapiary.com/w/index.php?title=Special:SearchByPropertylimit=500offset=0property=Has+PHP+Versionvalue=5.3.3
is also something to keep in mind

On 19 Jul 2015, at 07:15, Bryan Davis bd...@wikimedia.org wrote:

[0]: http://www.gossamer-threads.com/lists/wiki/wikitech/436441#436441

Yeah, in case of Wikimedia master is near-immediate production so
let's post-pone this until right after Wikimedia's migration is complete.

Third parties can stick to using the LTS or the current stable version
as needed for upto several years more without issue.

-- Krinkle

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Removal of mobile.wikipedia.org and wap.wikipedia.org in support of browser HSTS preload

2015-07-22 Thread Adam Baso

Is this good to go?

On Thu, Jul 16, 2015 at 3:03 PM, Adam Baso ab...@wikimedia.org wrote:

 I posted the query results at
 https://phabricator.wikimedia.org/T104942#1458981. I _believe_ there
 wasn't significant skew on particular days that would taint the initially
 reported number, although there were small variations as expected.

 On Thu, Jul 16, 2015 at 9:33 AM, Adam Baso ab...@wikimedia.org wrote:

 No problem, I'll run some extra queries.

 On Thu, Jul 16, 2015 at 9:04 AM, John phoenixoverr...@gmail.com wrote:

 1 day isnt much to base a decision on, especially on a global level.
 Normally I would use a sample set of at least a week, to a month of
 values.
 Sorry if I seem like im being a pain, I have just seen a lot of bad
 choices
 made based off limited data sets. With a wider data set we might find
 that
 Tuesdays are the slowest day for traffic, or some other factor that skews
 the data. Ensuring data validation is important when making these types
 of
 calls based off the working dataset.

 On Thu, Jul 16, 2015 at 11:05 AM, Toby Negrin tneg...@wikimedia.org
 wrote:

  Hi John --
 
  What do you think would be a better sample? My feeling is that a 24
 hour
  period captures global usage and we're currently at about .01% of page
  views come to these domains is a pretty good indicator. Keep in mind
 we're
  doing this for a legitimate technical reason and not arbitrarily.
 Looking
  at the UAs is a good idea and we will do that.
 
  thanks,
 
  -Toby
 
  On Thu, Jul 16, 2015 at 6:55 AM, John phoenixoverr...@gmail.com
 wrote:
 
   Can we look at a wider sample? using a single day as judgement
 factor is
  a
   bad idea. However if the data supports your position I dont see any
  serious
   problems. You might want to take a look at either the UA's or
 refering
   sources to see if there is a primary source for the traffic and
 mitigate
   that.
  
   On Thu, Jul 16, 2015 at 9:03 AM, Adam Baso ab...@wikimedia.org
 wrote:
  
Looks like the user pageviews for wap.wikipedia.org and
mobile.wikipedia.org
subdomains are approximately 0.02% of the size of pageviews for
m.wikipedia.org subdomains based on a recent one day check.
   
hive select count(*) from
wmf.webrequest where
year = 2015 and month = 7 and day = 14
and access_method = 'mobile web'
and (uri_host like '%.wap.wikipedia.org' OR uri_host like '%.
mobile.wikipedia.org')
and is_pageview = true and agent_type = 'user';
   
35,543
   
hive select count(*) from
wmf.webrequest where
year = 2015 and month = 7 and day = 14
and access_method = 'mobile web'
and uri_host like '%.m.wikipedia.org'
and is_pageview = true and agent_type = 'user';
   
202,024,891
   
   
On Thu, Jul 16, 2015 at 5:41 AM, John phoenixoverr...@gmail.com
  wrote:
   
 ... Have we done any analysis on usage of those subdomains?

 On Thu, Jul 16, 2015 at 8:34 AM, Adam Baso ab...@wikimedia.org
   wrote:

  There's a ticket for removing mobile.wikipedia.org and
wap.wikipedia.org
  domains/subdomains, which are legacy domain names superceded by
  m.wikipedia.org and its subdomains.
 
  https://phabricator.wikimedia.org/T104942
 
  The rationale for the removal of these legacy domain names is
 to
  help
  support HSTS preloading in browsers with the existing TLS SAN
 cert.
 
  After review of the ticket, can anyone think of a compelling
 reason
   to
 keep
  those old domain names?
 
  I'm going to open a separate thread on mobile-l about this
 given
  this
is
  more mobile-targeted, yet some people only operate on one of
   wikitech-l
 or
  mobile-l.
 
  -Adam
  ___
  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
___
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
  
  ___
  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




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: Wikipedia iOS app moving to GH

2015-07-22 Thread Adam Baso

They're two separate lists. I believe most Reading engineers are on both
mobile-l and wikitech-l. Couldn't say so much for other people.

On Wed, Jul 22, 2015 at 10:16 AM, Brian Gerstle bgers...@wikimedia.org
wrote:

 sorry, didn't hit reply-all. (these lists aren't a subset of each other,
 are they?)

 Also, we're losing IRC notifications, but that should be easy enough to add
 back via fastlane.

 -- Forwarded message --
 From: Brian Gerstle bgers...@wikimedia.org
 Date: Wed, Jul 22, 2015 at 12:59 PM
 Subject: Re: [Wikitech-l] Wikipedia iOS app moving to GH
 To: Wikimedia developers wikitech-l@lists.wikimedia.org


 I have no problem with that, as long as everyone with +2 keeps his access


 This should already be the case for the main iOS engineers, but I've made a
 ticket https://phabricator.wikimedia.org/T106547 to make sure people
 don't slip through the cracks.

 Oh, and when
  it syncs with phabricator tickets
 

 Phabricator ticket sync is something we're sad to lose, but it's part of
 the trade-off we're making.  That said, it was only slightly beneficial as
 we relied more on cards being in a Code Review column (w/ a WIP limit)
 than looking at the gerrit updates on the cards themselves (which aren't
 visible from the board view).  Not that GH will make this any easier, but
 we're not losing too much here, IMHO.

 On Wed, Jul 22, 2015 at 8:01 AM, Derk-Jan Hartman 
 d.j.hartman+wmf...@gmail.com wrote:

  I have no problem with that, as long as everyone with +2 keeps his access
  and someone manages developer account additions and removals. Oh, and
 when
  it syncs with phabricator tickets
 
  DJ
 
  On Wed, Jul 22, 2015 at 1:39 PM, Petr Bena benap...@gmail.com wrote:
 
   Good job, you aren't the only one. Huggle team is using it for quite
   some time. To be honest I still feel that github is far superior to
   our gerrit installation and don't really understand why we don't use
   it for other projects too.
  
   The GitHub's pull requests are more compliant with original git
   philosophy of Linus, see this video:
   https://www.youtube.com/watch?v=4XpnKHJAok8 and would be sufficient
   replacement to our current git-review mechanism, which is very
   complex and unfriendly to new developers who probably find it very
   difficult to use.
  
   On Wed, Jul 22, 2015 at 12:40 PM, Brian Gerstle 
 bgers...@wikimedia.org
   wrote:
Hey everyone,
   
I'm writing with plans for the Wikimedia iOS engineering team to move
  its
workflow to GitHub with Travis CI, much like RESTbase.
   
The Wikimedia iOS engineers have been maintaining their own CI and
  build
server and using Gerrit for code review. The more time efficient and
commonplace approach for open source iOS software development leans
   heavily
on GitHub with Travis CI instead (e.g., WordPress[0][1] and
   Firefox[2][3]).
By using GitHub with Travis CI, the team believes it will work
 faster,
improve testing, grow developer confidence in making code changes,
 and,
most importantly, deploy fewer bugs to production.
   
For builds requiring sensitive information (e.g., prod certs), will
continue to run on WMF's Mac Mini. As is done for Android, when betas
  are
pushed, the team will notify mobile-l.
   
Feel free to reply or email me directly with any questions or
 comments.
   
Regards,
   
Brian
   
0: https://github.com/wordpress-mobile/WordPress-iOS
1: https://travis-ci.org/wordpress-mobile/WordPress-iOS
2: https://github.com/mozilla/firefox-ios
3: https://travis-ci.org/mozilla/firefox-ios
   
--
EN Wikipedia user page:
  https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
___
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
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 



 --
 EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
 IRC: bgerstle



 --
 EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
 IRC: bgerstle
 ___
 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

[Wikitech-l] 2015-07-22 Scrum of Scrums notes

2015-07-22 Thread Grace Gellerman

https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-07-22
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Min php version

2015-07-22 Thread Thomas Mulhall

Maybe another php bump to something like 5.3.6. I think one php 5.3 usage goes
down then we should switch to something like php 5.5 or 5.6 or even php 7 if
php 7 get enough popularity.

On Wednesday, 22 July 2015, 21:19, Eran Rosenthal eranro...@gmail.com
wrote: