Thanks Stephen! On Tue, Jun 28, 2016 at 1:01 PM, Stephen Niedzielski < sniedziel...@wikimedia.org> wrote:
> *Action items:* > > - Audit any assumptions apps make about contents of HTML returned by > API and make tickets for tests [*Jon Robson*] > - Make sure all edge cases are covered e.g. What if srcset is not > present? What if there are no img and the figure tag is being used? > - Rely less on HTML wherever possible - explore if it would make > more sense to pull out metadata in API responses > - Capture in a task for Reading Web team to write a > MobileFrontend test to protect app requirements > - Write new tests for MobileFrontend (wherever they make most > sense) to make sure they cover what is needed by iOS and Android > and they > need to be triggered by MobileFrontend commits > - Could add some MCS tests for HTML content > > > - Look into hooking up Jenkins Android / iOS to the mobile front end > tests so that MobileFrontend merges are blocked when they break things in > apps [*Corey Floyd + Michael Holloway*] > - Explore if TemplateData could be used by Apps for replacing > editor created template constructs e.g. infobox > > > - Look at testing apps against beta cluster [*Monte Hurd*] > > > - Android / iOS should try to get CSS / JavaScript into MobileFrontend > more rather than changing it on the client [T137992 > <https://phabricator.wikimedia.org/T137992>] > > > > *Copy and paste of Etherpad > <https://etherpad.wikimedia.org/p/Client-server> for posterity:* > > Agenda > 9:00-9.15: What happened. Let's get a shared understanding of the problem > hit. Demo would be useful here if this can be arranged. > 9:15-9.40: How could this have been avoided? What APIs would have made it > better? > 9:40-10:00: Actions/story writing. > > From Google invite: > > > - "I think this is something we should probably discus more next week > - probably as a separate meeting. It would be good to talk about the > strategies we use in the apps to get the content and what we can do to > improve them. This is also very relevant for the content service." > > > - > > > - I've marked some as mandatory and some as optional, but I don't > think it would hurt to join and even just listen passively even if you're > optional, especially if you have an interest. > > > - > > > - The removal of srcset led to some breakage in the iOS app's > galleries. > > > - > > Notes: > > App clients have two different calls: > Meta data: search, something powering the feed > Content: HTML <-- This is where the issue is. > > HTML content: > > - HTML is valid but... We extract somethings (with selector > queries) to do things natively. This is kind of hacky generally because > content is tough and variable. For example, table of contents (the sections > themselves are parsed out server side...? it's pulled down and seperated). > Any changes to the structure of this HTML can break things. > > > - Content Service does this kind of thing too but at least the output > is from Parsoid. > > > - Web does very little with HTML content. The stuff we do is very > minimal. Somethings get stripped out but generally considered small. > > > - More tests would be nice for content specifically. For instance, if > you clients are expected a src set, then write a test for that. > > > - iOS added a test for srcset. Content Service has lots of content > tests. > > > - It's tricky for native apps since the tests are written in a > different environment than the other app tests? Just need to make sure the > HTML isn't messed up. > > > - MobileFrontend has some Jenkins automated tests. Probably could use > some fleshing out to make sure they cover whatever the apps need. This > won't be super simple. > > > - Can we move some of the Android screenshot tests to Mobile Frontend > somehow? > > > - testwiki gets code drops on tuesdays > > > - beta cluster (en[.m].wikipedia.beta.wmflabs.org) gets whatever's > merged to master like within 30 minutes of merge > > > - > > Action items: > Audit any assumptions apps makes about contents of HTML returned by API > and > make tickets for tests [JR] > > - Make sure all edge cases are covered e.g. What if srcset is not > present? What if there are no img and the figure tag is being used? > > > - Rely less on HTML wherever possible - explore if it would make more > sense to pull out metadata in API responses > > > - Capture in a task for Reading Web team to write a MobileFrontend > test to protect app requirements > > > - Write new tests for MobileFrontend (wherever they make most > sense) to make sure they cover what is needed by iOS and Android and they > need to be triggered by MobileFrontend commits > > > - Content Service is used by Android and already has a lot of > tests, remaining tests are integration level screenshot tests > > > - Could add some MCS test for HTML content > > > - Look into hooking up Jenkins Android / iOS to the mobile front end > tests so that MobileFrontend merges are blocked when they break things > in apps [CF + MHolloway] > > Explore if TemplateData could be used by Apps for replacing editor created > template constructs e.g. infobox > Look at testing apps against beta [MHurd] > Android / iOS should try to get CSS / JavaScript into MobileFrontend more > rather than changing it on the client [ > https://phabricator.wikimedia.org/T137992] > > -- Corey Floyd Software Engineer Reading / iOS Wikimedia Foundation
_______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
