[Wikitech-l] XML dumps

The XML database dumps are missing all through May, apparently because of a memory leak that is being worked on, as described here, https://phabricator.wikimedia.org/T98585 However, that information doesn't reach the person who wants to download a fresh dump and looks here, http://dumps.wikimedia

Re: [Wikitech-l] API returns empty strings for boolean fields?

Guess I shouldn't be so quick to complain ;) Thanks Anomie and others for finally fixing that 7-year-old bug! On Thu, May 28, 2015 at 4:17 PM, Legoktm wrote: > On 05/28/2015 02:58 PM, Brian Gerstle wrote: > > Is this the desired behavior? > > Yes-ish. It's a leftover from when XML was the primar

Re: [Wikitech-l] API returns empty strings for boolean fields?

On 05/28/2015 02:58 PM, Brian Gerstle wrote: > Is this the desired behavior? Yes-ish. It's a leftover from when XML was the primary API format. If you pass formatversion=2 in the request, you'll get proper booleans (as well as other improvements). I re-closed

Re: [Wikitech-l] API returns empty strings for boolean fields?

Feel free to reopen the declined bug: https://phabricator.wikimedia.org/T15299 I've always supported making our API more intuitive, but every bug I file about it gets declined :( On Thu, May 28, 2015 at 2:58 PM, Brian Gerstle wrote: > For example: > > "mainpage" field is omitted when querying B

Re: [Wikitech-l] API returns empty strings for boolean fields?

That's pretty normal (but admittedly confusing). For example, if you do a query for a page property, it will return empty string for true and nothing for false (which both evaluate to false in PHP): https://en.wikipedia.org/w/api.php?action=query&titles=Bug&prop=pageprops&ppprop=disambiguation http

[Wikitech-l] API returns empty strings for boolean fields?

For example: "mainpage" field is omitted when querying Barack Obama : > { > "mobileview": { > "pageprops": [], > "sections": [] > } > } Bu

[Wikitech-l] Mailing list maintenance window - 2015-06-02 17:00 UTC to 19:00 UTC

Mailing list maintenance window - 2015-06-02 17:00 UTC to 19:00 UTC I'll be taking the mailing list server offline for a (hopefully) short window. At the time of this announcement, this will be simply to process a single request. There is a good chance another request or two will be appended to

Re: [Wikitech-l] Simplifying the WMF deployment cadence

Le 28/05/2015 20:39, John Mark Vandenberg a écrit : > This also doesnt give clients sufficient time to workaround > MediaWiki's wonderful intentional API breakages. e.g. raw continue, > which completely broke pywikibot and needed a large chunk of code > rewritten urgently, both for pywikibot core

Re: [Wikitech-l] Simplifying the WMF deployment cadence

> On Fri, May 29, 2015 at 2:07 AM, Greg Grossmeier wrote: > > > >> It was reported by pywikibot devs almost as soon as we detected that > >> the test wikis were failing in our travis-ci tests. It was 12 hours > >> before a MediaWiki API fix was submitted to Gerrit, and it took four > >> additio

Re: [Wikitech-l] Simplifying the WMF deployment cadence

On Fri, May 29, 2015 at 2:07 AM, Greg Grossmeier wrote: > >> It was reported by pywikibot devs almost as soon as we detected that >> the test wikis were failing in our travis-ci tests. It was 12 hours >> before a MediaWiki API fix was submitted to Gerrit, and it took four >> additional *days* to

Re: [Wikitech-l] [Engineering] Simplifying the WMF deployment cadence

> See also: > https://phabricator.wikimedia.org/maniphest/?statuses=open%28%29&projects=PHID-PROJ-4uc7r7pdosfsk55qg7f6#R > (aka: open tasks filed in the #Wikimedia-log-errors project on > phabricator) A maybe better way to view that query: https://phabricator.wikimedia.org/maniphest/query/8G19mXx

Re: [Wikitech-l] [Engineering] Simplifying the WMF deployment cadence

> This also means we need to be even more diligent about policing the error > logs and eliminating noise which obscures real problems by burying them > among the other log messages. +1000 See also: https://phabricator.wikimedia.org/maniphest/?statuses=open%28%29&projects=PHID-PROJ-4uc7r7pdosfsk

Re: [Wikitech-l] Simplifying the WMF deployment cadence

On May 28, 2015 8:40 PM, "John Mark Vandenberg" wrote: > > On Fri, May 29, 2015 at 12:17 AM, Legoktm wrote: > > On 05/27/2015 01:19 PM, Greg Grossmeier wrote: > >> Hi all, > >> > >> New cadence: > >> Tuesday: New branch cut, deployed to test wikis > >> Wednesday: deployed to non-wikipedias > >> T

Re: [Wikitech-l] Simplifying the WMF deployment cadence

> It was reported by pywikibot devs almost as soon as we detected that > the test wikis were failing in our travis-ci tests. It was 12 hours > before a MediaWiki API fix was submitted to Gerrit, and it took four > additional *days* to get merged. The Phabricator task was marked > Unbreak Now! al

Re: [Wikitech-l] Simplifying the WMF deployment cadence

On Fri, May 29, 2015 at 12:17 AM, Legoktm wrote: > On 05/27/2015 01:19 PM, Greg Grossmeier wrote: >> Hi all, >> >> New cadence: >> Tuesday: New branch cut, deployed to test wikis >> Wednesday: deployed to non-wikipedias >> Thursday: deployed to Wikipedias > > This means that if we/users spot a bug

Re: [Wikitech-l] [Engineering] Simplifying the WMF deployment cadence

On May 28, 2015 4:21 PM, "Jon Robson" wrote: > > I suspect the idea is to lean more on our quality assurance infrastructure > e.g. browser tests which I fully welcome. > > The more developed they become the less chance of regressions making it to > code let alone our projects. > > When I joined 3

Re: [Wikitech-l] Simplifying the WMF deployment cadence

> This means that if we/users spot a bug once the train hits Wikipedias, > or the bug is in an extension like PageTriage which is only used on the > English Wikipedia, we have to: rush to make the 4pm SWAT window, deploy > on Friday, or wait until Monday; which from what I remember were similar >

Re: [Wikitech-l] Simplifying the WMF deployment cadence

On 05/27/2015 01:19 PM, Greg Grossmeier wrote: > Hi all, > > New cadence: > Tuesday: New branch cut, deployed to test wikis > Wednesday: deployed to non-wikipedias > Thursday: deployed to Wikipedias This means that if we/users spot a bug once the train hits Wikipedias, or the bug is in an extensi

Re: [Wikitech-l] [Engineering] Simplifying the WMF deployment cadence

> This is strictly a question from an uninvolved observer. Does this > schedule provide for sufficient time and real-time/hands-on testing before > changes hit the big projects? Yes. We still have Beta Cluster (production-like environment) which runs all code merged into master within 10 minutes

Re: [Wikitech-l] [Engineering] Simplifying the WMF deployment cadence

> Awesome! This will make many teams very happy since they'll be moving > faster. :) > What's the criteria by which you will evaluate the success of this? 1) the above (happier teams) 2) It's going to be hard to measure "success" but it'll be much easier to identify failure. I'll be talking wit

Re: [Wikitech-l] [Engineering] Simplifying the WMF deployment cadence

I suspect the idea is to lean more on our quality assurance infrastructure e.g. browser tests which I fully welcome. The more developed they become the less chance of regressions making it to code let alone our projects. When I joined 3 years ago we had no quality assurance infrastructure and now

Re: [Wikitech-l] [Engineering] Simplifying the WMF deployment cadence

This is strictly a question from an uninvolved observer. Does this schedule provide for sufficient time and real-time/hands-on testing before changes hit the big projects? An IRC discussion I was following last evening suggested to me that the first deploy (to test wikis and mw.org) probably did

Re: [Wikitech-l] [Engineering] Simplifying the WMF deployment cadence

Awesome! This will make many teams very happy since they'll be moving faster. What's the criteria by which you will evaluate the success of this? Thanks, Dan On 27 May 2015 10:19 pm, "Greg Grossmeier" wrote: > Hi all, > > Starting the week of June 8th we'll be transitioning our MediaWiki + > Ex