Re: [WikimediaMobile] [Apps] Android Wikipedia beta app release (2.0.104-beta-2015-06-25)

[Federico Leva (Nemo)]

Stephen Niedzielski, 26/06/2015 04:20:

   * Fix certain ISBN number links


I see it was more than that, all special pages! 
https://phabricator.wikimedia.org/rAPAW647a53d3ea896c3c66805fd65726852d126f48f5


Was this reported against the mobileview API as well? Having a complete 
map of gaps and differences from the desktop version is important so 
that everyone is on the same page.


Nemo

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] [Apps] Android Wikipedia beta app release (2.0.104-beta-2015-06-25)

[Stephen Niedzielski]

  The Android team[0] is proud to announce a new Wikipedia Android app beta
release, v2.0.104-beta-2015-06-25[1]. In summary, this revision contains
the following enhancements:

  * New: Tabbed browsing! Press-and-hold links to open in a new tab.
  * New: Big images in articles!
  * New: Enable experimental read more enhancements for some users
  * Improve list design throughout the app
  * Add responsive UI to edit pencil
  * Fix certain ISBN number links
  * Reduce app memory requirements
  * Add image licensing to Share A Fact & link to app privacy policy
  * Remove initial login onboarding pop up
  * Dozens of fixes & improvements as listed[2]:
https://phabricator.wikimedia.org/T103788

  Make it better! Read our getting started guide[3]. We can't wait for your
contributions!

  [0] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team#Android_App
  [1] Rolling out at
https://play.google.com/store/apps/details?id=org.wikipedia.beta
  [2] A complete list of changes is available at
http://git.wikimedia.org/compare/apps%2Fandroid%2Fwikipedia/beta%2F2.0.103-beta-2015-06-11..beta%2F2.0.104-beta-2015-06-25
  [3]
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Wikipedia_Android_app_hacking
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] The path to video: media playback for the iOS app

[Brion Vibber]

I've been looking at MobileVLCKit for some time actually, including
submitting build script patches to make it easier to build as a framework
and getting help from the VLC devs to make a stripped-down build option
without the default proprietary codecs.

There are a few key things that have led me to prefer going a separate way:

* Build reproducibility is bad. I very frequently encounter breakage after
a fresh checkout, as the complex build system doesn't ensure that
consistent versions of all the dependencies are used -- for instance there
are a lot of patches which frequently fail to apply. If the code can't be
safely rebuilt and dropped in, upgrading and debugging are potential
nightmares.

* No Xcode-friendly packaging. The recursive autoconf-based build system
doesn't match up well with CocoaPods for packaging and building in Xcode
with desired options. I could make a podspec that uses a prebuilt binary
with specific options[1], but:

* MobileVLCKit is large, and includes lots of things we don't need. A
default framework build is literally hundreds of megabytes; the actual
linked executable size is smaller but it still adds like 40 megabytes to
the app bundle. Even with the no-scary-codecs option there's a lot of stuff
in there and you get a huge library. We could work further to strip it
down, but there may be diminishing returns.


OGVKit wraps mostly the same open-source codec libraries that MobileVLCKit
does, but the framework and playback logic is lighter-weight and the
packaging is friendlier to debugging and versioning.

Ultimately the API surface between the Wikipedia app and the player widget
will be quite small; it should be easy to swap player libraries should the
need arise. (Or replace it altogether with standard classes if we ever
allow MP4 output on the servers...!)


[1] Note I am using such a binary package for libvpx, the WebM VP8/VP9
video codec. I'm prebuilding that using libvpx's build scripts, which *are*
nice and clean and consistent, and the resulting multi-arch framework
binary is only a few megabytes.

-- brion


On Thu, Jun 25, 2015 at 3:46 PM, Corey Floyd  wrote:

> Brion - have a question about existing OGG players: Currently there is an
> iOS framework called VLCKit (https://wiki.videolan.org/VLCKit/) by the
> VideoLan crew that appears to handle OGG/WebM and seems to be under
> active development. It is also being used in several shipping apps
> (including the VLC iOS app)
>
> I see you forked it at sometime in the past… was there a reason why you
> didn't pursue modifying it or using it as is within the iOS app to play
> media files?
>
> On Thu, Jun 25, 2015 at 1:05 PM, Monte Hurd  wrote:
>
>> Brion this is so exciting! :)
>>
>> On Wed, Jun 24, 2015 at 3:53 PM, Brion Vibber 
>> wrote:
>>
>>> We've been stalled for years on adding media playback to the Wikipedia
>>> iOS app due to the impasse between Wikimedia's insistence on free formats
>>> and Apple's insistence on only supporting patented formats.
>>>
>>> I'm trying to route around that impasse by getting Ogg and WebM playback
>>> up and running on iOS through a native widget library, which I've been
>>> cleaning up to ready it for CocoaPods packaging.
>>>
>>> Here's the high-level library:
>>> https://github.com/brion/OGVKit
>>>
>>> and provisional CocoaPods specifications for the low-level open-source
>>> libraries it needs:
>>> https://github.com/brion/OGVKit-Specs
>>>
>>> Once I finish some further fixes and do an API cleanup (version 0.5 on
>>> my provisional milestones )
>>> I plan to publish my podspecs and write a patch to the Wikipedia app that
>>> uses OGVKit to handle media playback.
>>>
>>>
>>> Rough patch plan:
>>> * add OGVKit as dependency
>>> * enhance the photo carousel view to instantiate a player view for
>>> audio/video files, just like on Android
>>> * add content CSS to clean up those video thumbnail 'Play media' links
>>> * add a JS click handler for 'Play media' links to launch the carousel
>>> * add a JS click handler for  and  elements in content
>>> * add a bunch of libraries to the list on the about page
>>>
>>> Ideally this should be a "surgical" patch and relatively minimal, though
>>> an update of the Pods dir will pull in a lot of files. :)
>>>
>>> -- brion
>>>
>>> ___
>>> Mobile-l mailing list
>>> Mobile-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>>
>>
>
>
> --
> Corey Floyd
> Software Engineer
> Mobile Apps / iOS
> Wikimedia Foundation
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] The path to video: media playback for the iOS app

[Corey Floyd]

Brion - have a question about existing OGG players: Currently there is an
iOS framework called VLCKit (https://wiki.videolan.org/VLCKit/) by the
VideoLan crew that appears to handle OGG/WebM and seems to be under active
development. It is also being used in several shipping apps (including the
VLC iOS app)

I see you forked it at sometime in the past… was there a reason why you
didn't pursue modifying it or using it as is within the iOS app to play
media files?

On Thu, Jun 25, 2015 at 1:05 PM, Monte Hurd  wrote:

> Brion this is so exciting! :)
>
> On Wed, Jun 24, 2015 at 3:53 PM, Brion Vibber 
> wrote:
>
>> We've been stalled for years on adding media playback to the Wikipedia
>> iOS app due to the impasse between Wikimedia's insistence on free formats
>> and Apple's insistence on only supporting patented formats.
>>
>> I'm trying to route around that impasse by getting Ogg and WebM playback
>> up and running on iOS through a native widget library, which I've been
>> cleaning up to ready it for CocoaPods packaging.
>>
>> Here's the high-level library:
>> https://github.com/brion/OGVKit
>>
>> and provisional CocoaPods specifications for the low-level open-source
>> libraries it needs:
>> https://github.com/brion/OGVKit-Specs
>>
>> Once I finish some further fixes and do an API cleanup (version 0.5 on my
>> provisional milestones ) I
>> plan to publish my podspecs and write a patch to the Wikipedia app that
>> uses OGVKit to handle media playback.
>>
>>
>> Rough patch plan:
>> * add OGVKit as dependency
>> * enhance the photo carousel view to instantiate a player view for
>> audio/video files, just like on Android
>> * add content CSS to clean up those video thumbnail 'Play media' links
>> * add a JS click handler for 'Play media' links to launch the carousel
>> * add a JS click handler for  and  elements in content
>> * add a bunch of libraries to the list on the about page
>>
>> Ideally this should be a "surgical" patch and relatively minimal, though
>> an update of the Pods dir will pull in a lot of files. :)
>>
>> -- brion
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>


-- 
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading-wmf] Improving Privacy Policy on Mobile

[Adam Baso]

Moving to mobile-l. Discuss.

-Adam

On Wed, Jun 24, 2015 at 10:05 PM, Jon Robson  wrote:

> cc. reading-list. You'll get more feedback there :)
> Short reply: There are lots of bugs and larger problems here that need
> to be solved.
>
>
> On Wed, Jun 24, 2015 at 5:42 PM, Jacob Rogers 
> wrote:
> > Hi Jon,
> >
> > James A suggested you might be the right person to talk with about
> improving
> > the readability of the WMF privacy policy on mobile devices. Currently,
> it's
> > pretty difficult to look at. It starts with the massive language list,
> the
> > disclaimer renders 1-2 words a line, and the blue boxes also render in
> hard
> > to read lines as well as pushing the main section to scroll off the
> screen.
> >
> > If you are the right person, what I'm hoping we can do is make the
> language
> > list into an expandable menu, get rid of the blue boxes on the sides if
> > necessary, and possibly make the examples into an expandable view rather
> > than have everything shown by default.
> >
> > If you're not the right person to this, could you forward me on to
> someone
> > that might be able to help?
> >
> > Many thanks,
> > Jacob
> > --
> >
> > Jacob Rogers
> > Legal Counsel
> > Wikimedia Foundation
> >
> > NOTICE: This message might have confidential or legally privileged
> > information in it. If you have received this message by accident, please
> > delete it and let us know about the mistake. As an attorney for the
> > Wikimedia Foundation, for legal/ethical reasons I cannot give legal
> advice
> > to, or serve as a lawyer for, community members, volunteers, or staff
> > members in their personal capacity. For more on what this means, please
> see
> > our legal disclaimer.
> >
>
> ___
> reading-wmf mailing list
> reading-...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Ops] How Flickr improved image scaler performance

[Adam Baso]

Cross posting. Really neat stuff!

-Adam

-- Forwarded message --
From: Timo Tijhof 
Date: Thu, Jun 25, 2015 at 10:05 AM
Subject: [Ops] How Flickr improved image scaler performance
To: ops Wikimedia List 


Flickr shared their story about speeding up resizing of images to near
real-time.

http://code.flickr.net/2015/06/25/real-time-resizing-of-flickr-images-using-gpus/

TL;DR:

* Switch to GraphicsMagick  a mature fork of ImageMagick (started in 2002)
that is more efficient, smaller code base, more secure, runs faster. (Also
used by Etsy).

* Switch again, to Ymagine. Another 2X improvement over GraphicsMagick.

* Switch again, to a GPU-based tool. Another 4X improvement. This GPU tool
doesn't appear to be open-sourced, however.

* Only reliably store thumbnails of 2048px (if the original is larger).
Generate the rest on-the-fly (from the 2048 one), with HTTP caching only.

http://www.graphicsmagick.org/
http://www.graphicsmagick.org/benchmarks.html
https://github.com/yahoo/ygloo-ymagine

— Timo


___
Ops mailing list
o...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ops
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] The path to video: media playback for the iOS app

[Monte Hurd]

Brion this is so exciting! :)

On Wed, Jun 24, 2015 at 3:53 PM, Brion Vibber  wrote:

> We've been stalled for years on adding media playback to the Wikipedia iOS
> app due to the impasse between Wikimedia's insistence on free formats and
> Apple's insistence on only supporting patented formats.
>
> I'm trying to route around that impasse by getting Ogg and WebM playback
> up and running on iOS through a native widget library, which I've been
> cleaning up to ready it for CocoaPods packaging.
>
> Here's the high-level library:
> https://github.com/brion/OGVKit
>
> and provisional CocoaPods specifications for the low-level open-source
> libraries it needs:
> https://github.com/brion/OGVKit-Specs
>
> Once I finish some further fixes and do an API cleanup (version 0.5 on my
> provisional milestones ) I
> plan to publish my podspecs and write a patch to the Wikipedia app that
> uses OGVKit to handle media playback.
>
>
> Rough patch plan:
> * add OGVKit as dependency
> * enhance the photo carousel view to instantiate a player view for
> audio/video files, just like on Android
> * add content CSS to clean up those video thumbnail 'Play media' links
> * add a JS click handler for 'Play media' links to launch the carousel
> * add a JS click handler for  and  elements in content
> * add a bunch of libraries to the list on the about page
>
> Ideally this should be a "surgical" patch and relatively minimal, though
> an update of the Pods dir will pull in a lot of files. :)
>
> -- brion
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading-wmf] Notes from performance meeting: PERFecting the reading experience

[Adam Baso]

Moving this discussion to mobile-l. Ori, are you on mobile-l?

Let's also be mindful to model (client side or router rate limiting is
easiest) realistic connection scenarios (i.e., 2G and 3G and clogged wifi
connections). Shaving off 3-4 seconds on fast connections makes a world of
difference, and so does shaving off 10-15 seconds on slow ones, for getting
the user to be able to interact with the page.

-Adam


On Thu, Jun 25, 2015 at 5:10 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> Hi,
>
> Ori Livneh, Sam Smith, Adam Basso and Joaquin Hernandez met to further
> talk about the performance work that's being scheduled for the following
> quarter.
>
> I've parsed my notes and written down what I've learned, and wanted to
> share them to create a shared understanding of how this planning is going.
> Not sure if this should go to other more public mailing lists at this
> stage, feel free to share wherever you think it should go.
>
>
>- Don't brainstorm and blindly implement ideas. Usually any ideas we
>can come up with will imply complex changes (like only loading the lead
>section) but won't have the expected return.
>- Measure and report, identify key metrics.
>- Performance work is hard to measure (predict outcomes) beforehand,
>you usually never know how it's going to unfold.
>- Suggested workflow is: 1. Measure and analyze. 2. Formulate
>hypothesis based on concrete data. 3. Implement hypothesis and goto 1.
>   - Seems like for being effective on accomplishing performance
>   goals, a continued effort through quarter will be needed (considering ^
>   previous point) instead of a laser focused half quarter effort.
>- Broad first-sight insights:
>- Server side time (only accountable if cache miss or logged in) is
>   negligible compared to other factors.
>   - Browser side performance is mobile's site biggest bottleneck.
>   Roughly half time (~2s) parsing script and (~3s) rendering.
>  - Looks like there's wins to be gained from optimizing on
>  browser performance.
>  - We need to research and communicate before hypothesizing.
>   - Tools:
>   - Besides Grafana dashboards using the graphite data we'll
>   coordinate with the Performance team to track other types of metrics 
> coming
>   from other tools like,
>   - Speedcurve.com for browser/front-end based performance reports.
>   - Maybe sitespeed.io for tracking regressions.
>- How to do it:
>   - Measure, establish baseline data.
>   - Plan hypothesis.
>   - Implement, local measuring. If good deploy.
>   - Measure with change deployed. Evaluate impact. Write down results.
>   - Go to 1 or 2.
>
> Going forward we'll be communicating and syncing regularly with the
> performance team on our data, hypothesis, plans and results to stay in sync
> and help each other. (Is there a performance mailing list? Should we use
> wikitech-l?).
>
> Regarding numbered metrics and considering what we learned from these
> meetings it is going to be hard to set numbers for the goals to reach,
> we'll do our best and communicate back.
>
> Cheers
>
> ps: If I've mistaken or missed anything on my notes please call me out on
> it and correct me!
>
>
> ___
> reading-wmf mailing list
> reading-...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Update] Browser tests per patch

[Joaquin Oltra Hernandez]

Awesome stuff.

On Wed, Jun 24, 2015 at 8:25 PM, Jon Robson  wrote:

> I haven't been able to use verified yet - I think this is a permission
> that Barry doesn't have.
> I'm experimenting with him doing no score reviews right now rather
> than +1s for good patches. The -1s are worth being as visible as
> possible.
>
> I'm hoping to send an update on the status quo but I've updated him so
> that he can be run in a script:
>
> https://github.com/jdlrobson/Barry-the-Browser-Test-Bot/blob/master/barrybot.py
> If you want him to re-review code simply remove him from the list of
> reviewers - the bot currently works out what it needs to review based
> on which patches he is currently not a reviewer for.
>
>
> On Wed, Jun 24, 2015 at 5:36 AM, florian.schmidt.wel...@t-online.de
>  wrote:
> >> How does it affect jenkins if something/somebody sets verified to -1 for
> >> example? Would it block it from merging?
> >
> >
> >
> > Any -1/-2 in the verified column blocks submitting a change (even, if
> other
> > reviewers add a +1 in verified), so if Barry wouldn't be happy, you can't
> > merge. A workaround is to remove BarryBot as a reviewer (which would
> remove
> > the vote, too, and allows jenkins to submit the change).
> >
> >
> >
> > Freundliche Grüße
> > Florian Schmidt
> >
> >
> >
> >
> >
> >
> >
> > -Original-Nachricht-
> >
> > Betreff: Re: [WikimediaMobile] [Update] Browser tests per patch
> >
> > Datum: Wed, 24 Jun 2015 14:07:23 +0200
> >
> > Von: Joaquin Oltra Hernandez 
> >
> > An: "florian.schmidt.wel...@t-online.de"
> > 
> >
> >
> >
> >
> >
> >
> >
> > Baha I agree with you, but instead of staying silent just commenting a
> > "BarryBot is happy! Browser tests passed" without setting any +1 would be
> > good to know they run.
> >
> > I also agree with Florian, if we could set Verified +1 or -1 that could
> be
> > interesting. How does it affect jenkins if something/somebody sets
> verified
> > to -1 for example? Would it block it from merging?
> >
> > On Wed, Jun 24, 2015 at 1:53 PM, florian.schmidt.wel...@t-online.de
> >  wrote:
> >>
> >> Or, maybe, it should be possible for the bot to set the verified flag,
> >> instead of the code review (it's not a code review, so a minus one is
> >> misleading, too).
> >>
> >>
> >>
> >> Freundliche Grüße
> >> Florian Schmidt
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> -Original-Nachricht-
> >>
> >> Betreff: Re: [WikimediaMobile] [Update] Browser tests per patch
> >>
> >> Datum: Wed, 24 Jun 2015 13:47:39 +0200
> >>
> >> Von: Bahodir Mansurov 
> >>
> >> An: Jon Robson 
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> May I suggest that Barry should not +1 patches. It gives a false
> >> impression that the code is alright even though the code may not be
> covered
> >> at all. Can we have it just -1 when there is a problem, and stay silent
> >> otherwise?
> >>
> >>
> >> On Jun 18, 2015, at 8:55 PM, Jon Robson  wrote:
> >>
> >> So far I'm seeing some extremely positive results. The tests are
> >> running super fast (in phantomjs the smoke tests are taking less than
> >> 3 minutes...).
> >>
> >> I've been manually running him whilst I do code review in parallel and
> >> he's already generated some interesting conversation on this patchset:
> >> https://gerrit.wikimedia.org/r/#/c/219249/
> >>
> >> If you want to pair and get this to be less hacky I'm more than happy!
> >>
> >>
> >> On Thu, Jun 18, 2015 at 5:41 PM, Dan Duvall 
> wrote:
> >>
> >> Nice work, Jon.
> >>
> >> I've opened a task for defining a JJB builder/template and getting
> >> something
> >> like this into CI sooner rather than later.[1] I think your setup proves
> >> that a set of well-groomed MW-Selenium integration tests can be stable
> >> enough for this purpose, and we can start with an even smaller subset of
> >> core tests for a pre-merge build. Of course this isn't something that we
> >> planned to do 'now' now—sometimes 'then' suddenly becomes 'now' so
> >> 'soon'—but we can start with an experiment on Gather or MobileFrontend
> >> tests, since their health has greatly improved, and see how it goes.
> >>
> >> [1] https://phabricator.wikimedia.org/T103039
> >>
> >> On Thu, Jun 18, 2015 at 11:03 AM, Jon Robson 
> wrote:
> >>
> >>
> >> So the script that actually runs the browser test is not in a generic
> >> useful form but it is:
> >> https://gist.github.com/jdlrobson/32b607f8009e897ee80c
> >>
> >> It uses the GerritCommandLine tool to do grabbing and reviewing
> >> https://github.com/jdlrobson/GerritCommandLine
> >>
> >> Ideally if we can use labs-tools-gerrit-to-redis for identifying
> >> patches and then pulling them down we wouldn't need the
> >> GerritCommandLine tool since the code to submit a review is pretty
> >> trivial and captured in this function:
> >>
> https://github.com/jdlrobson/GerritCommandLine/blob/master/gerrit.py#L277
> >>
> >> I've also put this in the task
> >> https://phabricator.wikimedia.org/T101069#1379462
> >>
> >> We'll probably want an instance per extension, to simplif