[02:27:39] jdlrobson: I was just about to thank you for fixing the tap delay on iOS, but I couldn’t find the commit in the logs. And then I remembered that I just installed a beta of iOS 9.3. It looks like Apple finally took the delay out. Here’s an incredibly long URL for the release notes: [02:27:41] https://developer.apple.com/library/prerelease/mac/releasenotes/General/WhatsNewInSafari/Articles/Safari_9_1.html#//apple_ref/doc/uid/TP40014305-CH10-SW8 [02:27:49] jdlrobson: So, problem solved! [02:30:23] hello [02:31:19] hello [02:42:21] hello [12:38:02] cycling over to a coffee shop [15:50:19] dbrant: o/ hm, is it finally time to remove FixedViewPager? i'm not finding any errors from it [15:51:47] niedzielski: why yes! it appears so [15:57:25] dbrant: cool, i'll put in a patch in a bit [17:41:17] jdlrobson: hey... what version of lead images is this. and when did this go on beta? :( [17:41:32] nzr: it's always been there, it [17:41:47] it's kaity_ 's project, it just now loads page images [17:41:54] (it used to only do so on location pages) [17:42:09] jdlrobson: no.. the height and other stuff is different [17:42:32] check edward norton page. it has a portrait image with right side blank [17:42:55] i know the lead image project :| I'm talking about the alignments and spaces [17:43:05] nzr: that's because it's using a page image that is not landscape. That bugs always been present. [17:43:09] it's just now more visible to you [17:43:54] okay let me create a task to fix this [17:44:06] interestingly if you resize browser to about 400px it corrects itself hah [17:44:19] it looks like this ^ https://usercontent.irccloud-cdn.com/file/fjjC5081/Simulator%20Screen%20Shot%20Mar%2018%2C%202016%2C%2010.43.58%20AM.png [17:45:04] nzr: the aspect ratio of those images do not lend themselves nicely to banners [17:45:29] dbrant: is the plan to write new Dialogs as DialogFragments and we just handle Dialogs in ExclusiveBottomSheetPresenter for legacy code? [17:45:41] er no capital D on that first "dialogs" [17:45:44] so be sure to consider that when you write the bug [17:46:03] nzr: we could possible not show banners with certain aspect ratios to avoid this [17:46:06] niedzielski: i think so, if only for the convenience of saving state automatically. [17:46:33] jdlrobson: yea i mean lead images as a project has a blocker "figure out portrait images" [17:46:46] heh, that sounds about right :) [18:00:04] marxarelli: any chance you could merge https://gerrit.wikimedia.org/r/277821 ? I'm hoping it wil fix the daily failing browser test builds [18:00:14] if not and that doesn't work i'm keen to work out what's going [18:03:27] nzr: can you answer https://phabricator.wikimedia.org/T129274#2130434 so i can merge your new overlay? [18:11:47] is it ok to RESTBase API for developing an android as the API is still under development? [18:13:52] mtalal: some folks are in a meeting but will help when they get out. ^ mdholloway bearND gwicke [19:07:27] mtalal: hi there. you're welcome to consume the RESTBase API in your app, but you should be aware that, as stated on https://en.wiktionary.org/api/rest_v1/?doc#! , most of the endpoints are unstable experimental and could change at any time. [19:07:44] mtalal: that said, some endpoints are more likely to change than others. which endpoint(s) are you interested in? [19:12:05] actually i am researching on the android to be build for creating and editing wikipedia pages without the user worrying about the mediawiki markup language. [19:13:47] endpoint mostly i am looking are https://rest.wikimedia.org/en.wikipedia.org/v1/?doc#!/Page_content/post_page_html_title [19:14:07] https://rest.wikimedia.org/en.wikipedia.org/v1/?doc#!/Page_content/post_page_wikitext_title [19:20:10] mtalal: interesting project! are you aware of the VisualEditor (https://www.mediawiki.org/wiki/VisualEditor) project? it has the same goals (but is not available on android, at least for now.) [19:21:34] actually the project is of buildmlearn organization selected in Google summer of code 2016 and i am interested in applying to that particular project. [19:23:58] and i am not aware of the visual editor project. [19:25:16] mtalal: we don't directly use those endpoints you mentioned in the apps right now. i think they're reasonably stable but there are probably other people you should talk to. gwicke, would you recommend mtalal relying on the two endpoints he mentioned above with respect to a possible GSoC project? [19:29:40] Wikipedia mobile editor https://github.com/BuildmLearn/BuildmLearn-Toolkit/wiki/Google-Summer-of-Code-2016-Ideas#5-educational-mobile-applications [19:31:45] mtalal: thanks for the link! [19:32:08] mtalal: in my opinion this is not actually an easy project... [19:35:58] mtalal: in any case, going back to your original question, i think you are safe using those endpoints for now. I would recommend subscribing to the mediawiki-api and mediawiki-api-announce mailing lists so that you will be informed of any upcoming changes. [19:36:17] mtalal: https://lists.wikimedia.org/mailman/listinfo/mediawiki-api [19:36:31] mtalal: https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce [19:37:00] mtalal: there are no planned changes that i know of right now. [19:37:01] yeah right! i am been spending the last two days researching to find a way through this problem but i haven't got any break-through. :/ [19:38:45] Thank you anyways. [19:45:27] mtalal: you're welcome, good luck! [19:48:10] do you have any idea how could i go on from here to solve this particular problem. [19:48:16] any suggestions? [19:49:36] jdlrobson: re https://phabricator.wikimedia.org/T125329 this looks like good material for the api/services meeting monday. i can see if timo can make it [19:50:00] mtalal: honestly i think this is too difficult for a summer project. we have numerous, experienced engineers working on the problem of allowing editing without wikitext. [19:52:27] mtalal: i'm not sure why whomever wrote the description thought it would be easy. [19:56:24] i have written to the mentor about the this. let see what comes up. [19:57:05] mtalal: to give you a sense, this is (a bit outdated but best i can find) description of what we're doing in the desktop VisualEditor: https://www.mediawiki.org/wiki/VisualEditor/June_2012_release_FAQs#How_does_the_Visual_Editor_work.3F [19:57:43] You are part of the dev team of visual editor? [19:58:53] mtalal: nope. those folks are in #mediawiki-visualeditor [19:59:48] mtalal: or #wikimedia-editing (i don't generally join those channels so i'm not sure which is more active) [20:01:57] but with existing APIs an android app could be developed over the summers for searching, editing and creating pages in wikipedia. with editing done through mediawiki markup? [20:03:18] mtalal: i think an editing app that uses wikitext (mediawiki markup) would be a much more reasonable project. [20:06:59] if you come up with any solution do let know. thanks. [20:07:10] mtalal: or, i can imagine an app that provides fields for things like title, section headings, and body sections for simple pages and then translates the user input to wikitext. that might be what the project authors had in mind. [20:08:22] mtalal: i'm not sure that approach would work for editing existing pages, though. [20:08:40] this would for creating new pages on wikipedia. but what about editing existing pages? [20:10:19] mtalal: right, that's where the complexity comes in. [20:15:04] mdholloway: i will get in contact with the mentor ASAP and discuss the possible outcomes. [20:55:21] jdlrobson: sure thing! [20:55:49] sorry for the late reply. i sequestered myself to work on our bleeding edge JS testing framework [20:56:22] https://www.npmjs.com/package/malu [22:08:12] thanks marxarelli looks like i found a real bug in the process - https://gerrit.wikimedia.org/r/278401 cc bmansurov [22:09:03] jdlrobson: that's great! [22:09:05] but sadly didnt seem to completly make the time out issue go away :/ https://integration.wikimedia.org/ci/view/BrowserTests/view/MobileFrontend/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/453/#showFailuresLink [22:10:57] marxarelli: any way we can filter out these ReadTimeout issues? [22:11:02] i have no idea what causes them [22:11:38] jdlrobson: you mean Wait::TimeoutError? [22:12:00] oh nm, i see the Net::ReadTimeout [22:13:03] jdlrobson: they're caused by a broken or unresponsive webdriver connection [22:13:21] due to saucelabs slowness most likely [22:18:43] bearND: i just uploaded an update to the redlink hiding patch. my hunch is that the problem area earlier was this: [22:18:47] bearND: https://github.com/wikimedia/mediawiki-services-mobileapps/blob/ecd0e518947e5f8b834ed1f113e4455c42d22681/lib/transformations/hideDeadLinks.js#L19-L22 [22:19:10] bearND: (link is to the repo at the time of that commit) [22:20:01] bearND: getting and looping over every in the page to see if its title matches a deadlink seems like a poor design [22:20:29] bearND: so that's the bit that's different in the new patch. [22:20:48] mdholloway: yeah, we should be iterating over deadLinks instead [22:21:33] bearND: yep, changed in the new version to loop over the deadlinks and query for 'a[title=]' [22:21:53] mdholloway: nice [22:37:31] marxarelli: the Net::ReadTimeout has plagued us ever since the dawn of mobilefrontend browser tests [22:37:36] i'd love to find a way to disregard them [22:37:43] it just leads us to ignore the tests [22:38:38] jdlrobson: not a great idea to filter results but we should address the issue, yes [22:39:01] if the root cause is saucelabs, the right fix would be to factor out saucelabs [22:39:07] marxarelli: the bugs seem to be related to login [22:39:29] how do you figure? [22:40:16] http://saucelabs.com/jobs/fde41044a1bc43b2a95efa9773b8d557 [22:40:22] it seems like a problem with the webdriver connection to me, but i suppose that broken connection could just be a symptom [22:40:25] login works, but clicking the watchlist freezes afterwards [22:40:31] a similar test without a login step works just fine [22:40:56] right, but the error isn't consistent is it? [22:41:29] it's always the same scenarios it fails on [22:41:31] and the same steps [22:41:34] and always chrome [22:41:41] (firefox doesnt seem to have this issue) [22:41:43] huh, interesting [22:41:51] well, that might be worth investigating then [22:41:51] https://integration.wikimedia.org/ci/view/BrowserTests/view/MobileFrontend/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/989/#showFailuresLink [22:41:56] ignore the switching to desktop test [22:42:02] but all the more reason not to ignore the tests :) [22:42:04] that's a different issue and we can fix that [22:42:11] marxarelli: well the feature works fine [22:42:15] i can't replicate locally [22:42:19] even on beta cluster [22:42:28] except for in this instance where it doesn't [22:42:41] but it's making a request to the Watchlist page [22:42:44] it just never loads [22:42:54] right, but why is that? [22:42:57] so i think it's the webdriver breaking for some reason after logging in [22:42:59] we don't really know [22:43:33] marxarelli: the same tests pass fine in @integration mode [22:43:54] then perhaps it's the particular browser version? [22:44:12] i guess so but i have no idea how to debug that sort of thing when sauce labs is involved [22:44:18] or platform [22:44:42] last passing was 21st February [22:44:52] give it to a test analyst to try and repro [22:44:52] is there anyway to diff any changes in the environment since then? [22:44:59] do you have one of those? :) [22:45:28] * marxarelli remembers seeing those positions on the org chart ... [22:47:24] jdlrobson: yeah, anyway. bottom line: seems like a pain in the ass to reproduce and solve but it's still a problem that needs to escalation and solving [22:47:47] yeh i'm never sure how to escalate these problems apart from bug you [22:48:02] i see zflipin poke at them but i never seem to be working on his timezone [22:48:44] i think if it's a limitation/bug in the framework, it's releng [22:49:08] but if it's a legit (albeit annoyingly difficult to repro) bug, it's still your team [22:49:38] in other words, we're not a qa department but we are here to support you in tooling and infrastructure [22:52:58] jdlrobson: not trying to be difficult or pass the buck. we're just limited on bandwidth and can't really get involved in the actual debugging beyond our own tooling. you all need someone like Rummana or Elena on your team it sounds like [22:53:51] Totally... I guess I'm just feeling a bit helpless without that and i guess i just dont understand what I can do. None of my team understands this infrastructure and we are low on bandwidth too. Obviously skilling someone up would be the way to solve that but not sure how practical that is. [22:55:18] for instance it seems the tests for https://integration.wikimedia.org/ci/view/BrowserTests/view/MobileFrontend/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/ run on the mobile rather than on the desktop domain. That's something I want to fix which should be trivial but I'm not sure where to start. [22:55:28] that's understandable. we are working on a JS end-to-end testing framework that will hopefully be more palatable to other WMF engineers. hopefully that'll help with shared ownership/understanding [22:55:57] in the meantime, what about just removing that scenario? [22:56:03] or using the @skip tag? [22:56:28] i know it's tough to lose coverage but the tradeoff might be worth it if it lessens noise [23:01:29] jdlrobson: ah, that _is_ our domain. :) you'll want to look at integration/config/jjb/browsertests.yaml [23:02:09] change the `mediawiki_url` parameter [23:07:03] jdlrobson: don't mind my editing of phab projects :) [23:08:10] marxarelli: greg-g https://gerrit.wikimedia.org/r/#/c/278416/ should hopefully work in mean time. I'll schedule some time to do the switchover since it problably requires a little more work [23:09:29] jdlrobson: cool. i think that's a good solution [23:10:47] oh good we have a new flakey browser test hehe [23:20:54] mhurd: https://github.com/wikimedia/analytics-refinery/blob/master/oozie/mobile_apps/uniques/daily/generate_uniques_daily.hql