Re: [Wikitech-l] μRfC: Requiring 'curl' PHP extension for MediaWiki

2016-06-29 Thread Rob Lanphier
On Wed, Jun 15, 2016 at 1:51 PM, James Forrester
 wrote:
> Right now we have some features that require curl (it's probably the #2
> issue third parties have with installing VisualEditor, for instance, after
> mis-matched versions).

We discussed [the proposal to start requiring curl][2] at [this week's
IRC office hour][1], where we decided to deprecate running MediaWiki
without curl.  In particular, we agreed:

*  We still won't require curl, keeping existing non-curl codepath
*  We'll add a non-parallel MultiHttpClient fallback
*  Special:Version will let users know if the wiki is running without curl

Now we'd like to open this up for last call, and review any objections
discussed over the course of the week at [next week's ArchCom Planning
meeting][3].  Any objection to this plan?

Rob

[1]: https://phabricator.wikimedia.org/E224
[2]: https://phabricator.wikimedia.org/T137926
[3]: https://phabricator.wikimedia.org/E225

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] New: mw-tool-tourbot - Semi-automated legacy JS migration

2016-06-29 Thread Krinkle
TL;DR: A Node.js interactive command-line tool for fixing use of deprecated
javascript functions in on-wiki javascript.

https://github.com/Krinkle/mw-tool-tourbot

In 2011 I started a clean up of site scripts (the "Tour"). You can work on
the tour either per-issue (e.g. remove IE60Fixes from all wikis) or
per-wiki (e.g. pick a wiki and recurse through the checklist) [1]. I
usually mwgrep for a single issue pattern, and then slowly go per-wiki on
the results.

The current migration is for legacy wikibits [2]. I'm hoping to remove
deprecated wikibits methods in MediaWiki 1.28 [3].

The vast majority of patterns can be safely removed (no replacement) as
they've been silently disabled for 3 years (since 2013, MediaWiki 1.22)
[5]. Removal usually requires manual editing of a script.

Other patterns are simple find-and-replace subjects. To aid in migration of
those, mwgrep can be used to find relevant pages across Wikimedia wikis
[6]. Because mwgrep currently requires production access I've published a
few lists you can work from. (see [7] for making mwgrep public)

https://gist.github.com/Krinkle/a18e726fc3af30f30bf9b2ba919820b5#mwgrep-results

Feel free to request additional searches or updates, there.

I'm hoping this will help lower legacy wikibits usage. See Grafana for
progress so far (I first ran tourbot on June 12):
https://grafana.wikimedia.org/dashboard/db/mw-js-deprecate

-- Krinkle

[1]
https://meta.wikimedia.org/wiki/User:Krinkle/Le_Tour_de_Wikí/2011_Resource_Walker
[2] https://www.mediawiki.org/wiki/ResourceLoader/Legacy_JavaScript
[3] https://phabricator.wikimedia.org/T122755
[4]
https://www.mail-archive.com/wikitech-l%40lists.wikimedia.org/msg84465.html
[5] https://gist.github.com/Krinkle/11405589
[6] https://wikitech.wikimedia.org/wiki/mwgrep
[7] https://phabricator.wikimedia.org/T71489
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016-06-29 Scrum of Scrums meeting notes

2016-06-29 Thread Grace Gellerman
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-06-29


= 2016-06-29 =

== Product ==

=== Reading ===

 iOS 
* 5.0.5 - found a regression on Monday, fixing and testing in beta for the
rest of the week. Expecting to deploy next week
* 5.1 (no changes)
** In development - expected release early August
** Potential blocker for release is GeoData API improvements
https://phabricator.wikimedia.org/T137178 We are working with Discovery to
get this in for our release (blocker INTERACTIVE TEAM)


 Android 
* Feed work continues -- will ship to beta channel optimistically by end of
this week, otherwise sometime next week

 Mobile Content Service 
* Will need the services team to activate the feed endpoints in the public
REST API before shipping the feed (but work is still in progress)

 Reading Web 
* Image lazy loading on mobile web fawiki and ukwiki
* Image lazy loading plus reference lazy loading coming soon to mobile web
tlwiki (approx 30-June-2016 or 4-5 July 2016)
* Wikidata article descriptions added to top of page on mobile web cawiki,
coming to mobile web plwiki 30-June-2016
* Mobile main pages were errantly getting desktop formatting in some places
for a while, now fixed

 Reading Infrastructure 
* waiting for Language to say whether they will take T111486 (Update
Translate to use AuthManager)

=== Editing ===

 Parsing 
* Parsoid:
** Over last couple weeks, working on a bunch of link rendering /
serialization issues (mostly edge cases) in Parsoid
** About to resume work on native implementation of  extension --
Arlo has an initial patch in gerrit which needs a round of updates. Should
unblock multimedia & VE work on gallery support once this is done.
** At Wikimania hackathon, Scott worked on an update to support a more
detailed Templatedata format field for serializing transclusions -- this is
not finalized yet and the spec needs to stabilize before this can land.
* Core parser:
** Tim working on a side-by-side preview tool to let editors see how a page
would look with Tidy and with HTML5depurate -
https://gerrit.wikimedia.org/r/#/c/296182/  ... feedback welcome,
especially on the UI aspects or desirable features. Please take a look and
leave comments on the patch.

== Technology ==

=== Technical Operations ===
* '''Blocking'''
** None
* '''Blocked'''
** by noone
* Updates
** Slow week, wikimania
** Some work with interactive/discovery on maps
** some non user affecting changes in our firewalling setup
** Working with LE to review/upload on apt.wikimedia.org apertium related
packages

=== Security ===
* One usability bugs for Ex::OATHAuth in progress (T138423) (help
reproducing appreciated)
* Two-factor usability survey prep continues
* Reviews: 3d2png
* Three additional reviews will have feedback added this week: T130233,
T129175, T132934

=== RelEng ===
* Blocking
** None?
* Blocked
** Gallium phase out questions: https://phabricator.wikimedia.org/T133300
*** Pasted some IRC talk from chase
*** Other input welcome
** CI Documentation publication: https://phabricator.wikimedia.org/T137890
*** Mostly needs some network expertise
** Scandium disk space: https://phabricator.wikimedia.org/T138955
* Updates
** Train is back on track, wmf.8 to group1 today
** 1.27 release is out (yay!)
** Scap3 migrations continue (if you have questions, ask us! :))

=== Analytics ===
* Rebooting stat boxes and analytics cluster to upgrade kernel (security
patch)
* Working on testing a much faster way to load Cassandra directly from
Hadoop
* Cleaning up mediawiki page and user history is still ongoing
* Andrew, Madhu, and Nuria will be out until next week


== Discovery ==
* '''Blocking''': none
* '''Blocked''': none
* TextCat A/B test still running
* New research on typing in wrong character set:
https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Typing_on_the_Wrong_Keyboard%E2%80%94Russian_and_English
* Testing software upgrade for logstash.wikimedia.org at kibana4.wmflabs.org
- backward incompatible upgrade
* WDQS now deployed with scap3
* Everybody's welcome to rate query relevance in Discernatron:
https://discernatron.wmflabs.org/

=== Interactive Team ===
* Wikidata Query service support in geo shapes service is being deployed
* Heavy maps refactoring - might have broken cached pages and will need a
regen
* Need to start deploying shared GeoShapes & tabular data soonish
* RELENG: please make configuration for services available to devs, not
just ops
; '''blocking'''
* Potential blocker for release is GeoData API improvements
https://phabricator.wikimedia.org/T137178 We are working with Discovery to
get this in for our release (blocker INTERACTIVE TEAM)

== WIkidata ==
* Blockers: See T107595.
* Most of the team attended Wikimania.
** Relevant discussions about our plans for a Wikidata-powered Wiktionary:
https://phabricator.wikimedia.org/T986
** WMF support for multi content revisions was promised:
https://phabricator.wikimedia.org/T107595
__

Re: [Wikitech-l] git.wikimedia.org (Gitblit) going away on June 29th, redirected to Phabricator

2016-06-29 Thread bawolff
On Tue, Jun 21, 2016 at 8:26 PM, MZMcBride  wrote:
> Platonides wrote:
>>I hear this with dismay. When I wanted to view the repository online in
>>the past, I always ended up heading to git.wikimedia.org, since I was
>>unable to *find* the repository at phabricator.
>>At most, phabricator showed a somewhat related diffusion commit.
>
> Phabricator site search includes repositories. I agree that parts of
> Phabricator, including the repository index at
> , can be annoying to find
> currently.

Phabricator site search is pretty useless all and all. 75% of the time
I can't even find the bugs I'm looking for, and its more effective to
go the the project's workboard and hit ctrl+F in my browser.

As for git, I almost never want to actually look at it online. But
when I do, I'll probably just end up going to the github mirror...

--
bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Proposal to reopen the "Unacceptable behavior" section

2016-06-29 Thread Matthew Flaschen
Yaron Koren has proposed to reopen the "Unacceptable behavior" section 
(https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Suggested_change_to_.22discrimination.22_item).


His perspective and mine are given on the talk page.

In brief:
* He disagrees with how "marginalized and otherwise underrepresented 
groups" and "encouraged" are handled in the original text.
* I support the current text and process, and have explained why on the 
talk page.


Thanks,

Matt Flaschen

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] git.wikimedia.org (Gitblit) going away on June 29th, redirected to Phabricator

2016-06-29 Thread Daniel Zahn
This is done now. We stopped using gitblit for good!:)

git.wikimedia.org URLs now redirect to Diffusion.

redirect rules here:  https://gerrit.wikimedia.org/r/#/c/296138/

tested URLs here:  https://phabricator.wikimedia.org/P3318

https://phabricator.wikimedia.org/T137224  was resolved

https://phabricator.wikimedia.org/T111465 can be closed

antimony was removed from varnish config:
https://gerrit.wikimedia.org/r/#/c/293789/

one more precise host can be shut down ...

thanks to Paladox, Danny_B and JanZerebecki

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Logging client JS exceptions to the server

2016-06-29 Thread Joaquin Oltra Hernandez
Thanks!

On Mon, Jun 27, 2016 at 12:27 PM, bawolff  wrote:

> On Mon, Jun 27, 2016 at 6:22 AM, Joaquin Oltra Hernandez
>  wrote:
> > Hi,
> >
> > Are there any on-going efforts to log JavaScript errors to the server
> logs?
> >
> > Every once in a while we see very hard to reproduce errors in the console
> > that we're not sure how often are actually happening, and that makes us
> > think that there may be other errors happening that we're not coming
> across
> > (or other people savvy enough to open the console and post a bug).
> >
> > There are open source projects like sentry we could inspect and adapt a
> > client library for our purposes and log to EventLogging or somewhere
> else (
> > https://docs.getsentry.com/hosted/clients/javascript/).
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> See https://phabricator.wikimedia.org/T106915
>
> --
> bawolff
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l