Moving to mobile-l
On Wed, Mar 26, 2014 at 12:05 PM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote:
> Whenever someone decides to review the new licensing stuff in mobile, let me
> know. It requires updating both MobileFrontend and WikimediaMessages, and
> takes a fair bit of work to test all the combinations and interfaces.
> The 5 interfaces are:
> * Wikitext editor
> * VisualEditor
> * Talk page add new section
> * Talk page add new comment to section
> * Upload file
> The variables for the combinations are:
> * WikimediaMessages on or off
> * $wgRightsUrl set or not set
> * $wgRightsText set to various licenses (cc-by-sa has special importance for
> * $wgRightsPage set or not set
> * Various i18n messages overridden locally
> I can help whoever is reviewing to walk through these. I didn't write
> acceptance tests since the functionality is non-critical (it's basically
> been broken for years), and it would require a shitload of tests to test
> effectively. If someone thinks it should have acceptance tests though, let
> me know.
> Ryan Kaldari
I'm seeing lots of tests failing with "too many connection resets (due
to Net::ReadTimeout - Net::ReadTimeout) after 2 requests on
70020846470700, last used 60.008243583 seconds ago
Long term view: How do we stop these?
Short term view: It would be useful if no email notifications were
generated when this happens or these failures were filtered from test
We've setup email addresses for apps feedback from within the forthcoming
reboots of the Wikipedia for Android (android(a)wikimedia.org) and Wikipedia
for iOS apps (ios(a)wikimedia.org), which will allow anyone to send email
feedback by tapping Feedback in-app, but due to the sometimes personal
nature of feedback stuff is configured to only allow those with a strict
need to know to read the feedback.
We decided to split into two email addresses instead of one because of the
likelihood of users modifying the Subject line or Body in a way where it
wouldn't be evident which platform they're using. It also keeps the backing
mechanism, Google Groups, cleaner for the users who have read access to it.
An additional suggestion was to break things up into more email addresses
to accommodate for the other apps, possibly using aliases to divert the
messages to the existing two groups. For example:
apps-ios-wikipedia(a)wikimedia.org > ios(a)wikimedia.org
apps-ios-commons(a)wikimedia.org > ios(a)wikimedia.org
apps-android-wikipedia(a)wikimedia.org > android(a)wikimedia.org
apps-android-commons(a)wikimedia.org > android(a)wikimedia.org
Yuvi suggested we ought to bring this discussion onto mobile-l. Any
feedback on going from two to four email addresses (and possibly more
depending if more apps are created for these platforms)?
Relevant to the list, I think :)
---------- Forwarded message ----------
From: Vibha Bamba <vbamba(a)wikimedia.org>
Date: Tue, Mar 25, 2014 at 4:58 AM
Subject: Edit History of Article
To: Monte Hurd <mhurd(a)wikimedia.org>, Kenan Wang <kwang(a)wikimedia.org>
Cc: Yuvaraj Pandian <yuvipanda(a)wikimedia.org>
The most mockups from Mobile Web mockups for 'Edit History of an article'
now reside happily in this trello board.
I'm on board if you want to re-use the mobile web view in a browser.
Yuvi has already hacked a list of contributors.
I'm working on the long term badass design solutions for this =]
These mockups have confessed that they are happy to make a brief appearance
Senior Designer | WMF Design
*To expect the unexpected shows a thoroughly modern intellect - Oscar Wilde*
Just as with the FF vs. Chrome, a new one:
search.feature contains the line
And The URL of the page should contain "Main%20Page"
All of a sudden this fails on the Cloudbees host but passes on my local
We should probably decide on a rule for URL checking, the tests are all
over the place with that.
Raising the awareness of this to more people on mobile-l
---------- Forwarded message ----------
From: Yuri Astrakhan <yastrakhan(a)wikimedia.org>
Date: Tue, Mar 18, 2014 at 4:38 PM
Subject: [zero] reducing image quality
Spoke with Max, and wrote an RFC of what we intend to do. The last
portion might need a bit more thinking of who exactly will get the
original image quality.