Re: [Wikitech-l] [Wikimedia Labs][Announce] NFS (only labs projects) maintenance on 2017-01-18

[Madhumitha Viswanathan]

Hi all,

Update - most of the home directories have been restored at this point -
we're down to the last few, that seem to have had a lot of data hence
taking quite some time.

These are the pending instances(currently being restored):

data.eqiad.wmflabs
ldfclient.eqiad.wmflabs
mathosphere.eqiad.wmflabs
mwoffliner4.eqiad.wmflabs
nomad.eqiad.wmflabs
reading.eqiad.wmflabs
recommendations.eqiad.wmflabs
captcha-apiproxy-03.eqiad.wmflabs
dashboardchat.eqiad.wmflabs
maps-cruncher.eqiad.wmflabs
pdf.eqiad.wmflabs
mwoffliner[2-3].eqiad.wmflabs
phlogiston-2.eqiad.wmflabs
pole.eqiad.wmflabs

Other than this, it should all look good. Do let us know if something seems
amiss here or on #wikimedia-labs. Thanks for being patient!


On Wed, Jan 18, 2017 at 3:45 PM, Madhumitha Viswanathan <
mviswanat...@wikimedia.org> wrote:

> Update: NFS for labs projects is back to read write now.
>
> There was an incident in the process of the migration that caused /home in
> a significant number of labs instances (where /home was not on NFS) to be
> replaced by an erroneous symlink. We are currently working on restoring all
> the home directories - it looks like it may take at-least a couple hours.
> I'll keep the list updated on progress.
>
>
> On Wed, Jan 18, 2017 at 11:34 AM, Madhumitha Viswanathan <
> mviswanat...@wikimedia.org> wrote:
>
>> Update: this is still in progress. There's some ongoing issues with home
>> directories on non-nfs /home across Labs (not tools or maps) - we are
>> working on it, and will update soon. Do feel free to reach out
>> #wikimedia-labs if you have any questions or concerns.
>>
>> On Wed, Jan 18, 2017 at 8:38 AM, Madhumitha Viswanathan <
>> mviswanat...@wikimedia.org> wrote:
>>
>>> Reminder: This is starting soon, in ~22 minutes.
>>>
>>> On Tue, Jan 17, 2017 at 12:07 PM, Madhumitha Viswanathan <
>>> mviswanat...@wikimedia.org> wrote:
>>>
 Reminder: This is happening tomorrow, starting 09:00 PST(16:00 UTC).

 On Wed, Jan 4, 2017 at 1:43 PM, Madhumitha Viswanathan <
 mviswanat...@wikimedia.org> wrote:

> Hello,
>
> Continuing the storage redundancy and reliability efforts for Labs (
> https://phabricator.wikimedia.org/T126083), the final migration to
> the new NFS storage cluster for Labs projects with NFS enabled is 
> upcoming.
> The migration is planned to happen 2017-01-18 starting 09:00
> PST(16:00 UTC). This *does not* affect tools, maps or any other projects
> that don't have /home or /data/project mounted. The migration window is
> expected to be fairly short (<3 hours) - but could last up to 6 hours.
>
> During the migration, no new data will be written to NFS (/home or
> /data/project), but existing data will be accessible in Read-only mode for
> the most part. Post migration, any services or jobs that were running on
> top of NFS (/home or /data/project) will require manual restarts. Jobs
> running on top of /scratch or /public/dumps will be unaffected. I will 
> keep
> the lists and #wikimedia-labs updated on progress during and after the
> migration.
>
> The list of labs projects that will be affected in this migration are:
>
>
>- catgraph
>
>
>- account-creation-assistance
>
>
>- contributors
>
>
>- wikidata-topicmaps
>
>
>- sugarcrm
>
>
>- wikidumpparse
>
>
>- video
>
>
>- openstack
>
>
>- testlabs
>
>
>- wikidata-dev
>
>
>- quarry
>
>
>- huggle
>
>
>- editor-engagement
>
>
>- utrs
>
>
>- wmt
>
>
>- cvn
>
>
>- fastcci
>
>
>- toolsbeta
>
>
>- project-proxy
>
>
>- dumps
>
>
>- bots
>
>
>- snuggle
>
>
>- math
>
>
>- wikisource-tools
>
>
> The tracking task on phabricator is here -
> https://phabricator.wikimedia.org/T154336. Let us know if you have
> any questions or concerns on the list or on #wikimedia-labs.
>
> --
> Madhu Viswanathan
> Operations Engineer, Wikimedia Labs
>



 --
 --Madhu :)

>>>
>>>
>>>
>>> --
>>> --Madhu :)
>>>
>>
>>
>>
>> --
>> --Madhu :)
>>
>
>
>
> --
> --Madhu :)
>



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

Re: [Wikitech-l] ArchCom Status & Meeting Minutes, WD3

[Daniel Kinzler]

Am 18.01.2017 um 21:45 schrieb MZMcBride:
> Daniel Kinzler wrote:
>> * ArchCom is considering changes to the RFC process. Discussion is
>> ongoing.
> 
> Where is discussion ongoing?

Internally. We have to decide on a MO. I'm sharing this summary here to keep you
posted, and give an opportunity for input. But in the end, the committee has to
decide how it wants to operate.

> I don't know what primary tool means.

In the past, the IRC dicussion was the only way to get an RFC discussed or
approved.

> There are benefits to both
> asynchronous and synchronous discussions. The IRC meetings in particular
> have the benefit of being scheduled and regularly recurring, which can be
> a good nudge for people to finish drafting a task or wiki page, to make a
> decision to accept or decline, to comment on a proposal, etc.

Yes, we do see advantages, too. But it's not the best tool for all discussions,
and shouldn't be the only venue of discussion.

-- 
Daniel Kinzler
Principal Platform Engineer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikitech-l] ArchCom Status & Meeting Minutes, WD3

[MZMcBride]

Daniel Kinzler wrote:
>* ArchCom is considering changes to the RFC process. Discussion is
>ongoing.

Where is discussion ongoing?

>Key points:
>** More focus on discussion in Phabricator
>** More leight weight process for “small” RFCs
>** ArchCom to focus more on review, less ond process
>** IRC meeting should not be the primary tool for discussing and
>approving RFCs

I don't know what primary tool means. There are benefits to both
asynchronous and synchronous discussions. The IRC meetings in particular
have the benefit of being scheduled and regularly recurring, which can be
a good nudge for people to finish drafting a task or wiki page, to make a
decision to accept or decline, to comment on a proposal, etc.

MZMcBride



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

[Wikitech-l] Last Call: [RFC] image and oldimage tables

[Krinkle]

Hi,

The Architecture Committee plans to make a decision in two weeks on the RFC
about the schema change for image and oldimage tables. [1] [2]

Please review the updated RFC page [2] and send any final comments here on
Wikitech-l or Phabricator [1] by 2017-02-01. If no new and significant
concerns are raised within this time the committee will most likely approve
the RFC on Wednesday, February 1st.

-- Timo

[1] https://phabricator.wikimedia.org/T589
[2] https://www.mediawiki.org/wiki/Requests_for_comment/
image_and_oldimage_tables
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom Status & Meeting Minutes, WD3

[Daniel Kinzler]

Hi all!

Here are the minutes from this week's ArchCom meeting. You can also find the
minutes at .

See also the ArchCom status page at
 and the RFC board
.

Here are the minutes, for your convenience:

* 2 RFCs approved after final call: Deprecation Policy
([[Phab:T146965|T146965]]) and Content Model Storage ([[Phab:T105652|T105652]]).
* Multi-Content-Revisions (MCR, [[Phab:T107595|T107595]]) discussed at
DeveloperSummit. Sorted out details of the DB schema with Jaime.
* Ongoing discussion regarding distribution methods for MediaWiki and suppor for
3rd party installs.
** Related discussion about whether new features can require services serparate
from MediaWiki core.
* Thumbnail API is mostly stalled for now [[Phab:T66214|T66214]].
* Oldimage RFC ([[Phab:T589|T589]]) to go on final call this week.
** Decided to keep media type and mime type fields for now. Thy are small, and
now exposed via Cirrus Search; if we removed them from the table, they would
need to love somewhere else. Also they are enums, and thus small.
** Tentative plan to fold image revision management into MCR at some point, but
not until MCR is mature. Also, this schema change will make a later migration to
MCR much easier.
* ArchCom is considering changes to the RFC process. Discussion is ongoing. Key
points:
** More focus on discussion in Phabricator
** More leight weight process for “small” RFCs
** ArchCom to focus more on review, less ond process
** IRC meeting should not be the primary tool for discussing and approving RFCs
* Next week’s IRC discussion: [[Phab:T154738|T154738]] (Accessing page
properties from wiki pages). Related:
** T71441: Feature request: add detection for disambiguation pages to Scribunto
** T131911: Allow retrieving/getting page image file name from wikitext using
Scribunto/Lua or parser function or something
** T154346: Provide "wikitext" means of accessing arbitrary wiki page's default
category sort key

-- 
Daniel Kinzler
Principal Platform Engineer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikitech-l] [Wikimedia Labs][Announce] NFS (only labs projects) maintenance on 2017-01-18

[Madhumitha Viswanathan]

Update: NFS for labs projects is back to read write now.

There was an incident in the process of the migration that caused /home in
a significant number of labs instances (where /home was not on NFS) to be
replaced by an erroneous symlink. We are currently working on restoring all
the home directories - it looks like it may take at-least a couple hours.
I'll keep the list updated on progress.


On Wed, Jan 18, 2017 at 11:34 AM, Madhumitha Viswanathan <
mviswanat...@wikimedia.org> wrote:

> Update: this is still in progress. There's some ongoing issues with home
> directories on non-nfs /home across Labs (not tools or maps) - we are
> working on it, and will update soon. Do feel free to reach out
> #wikimedia-labs if you have any questions or concerns.
>
> On Wed, Jan 18, 2017 at 8:38 AM, Madhumitha Viswanathan <
> mviswanat...@wikimedia.org> wrote:
>
>> Reminder: This is starting soon, in ~22 minutes.
>>
>> On Tue, Jan 17, 2017 at 12:07 PM, Madhumitha Viswanathan <
>> mviswanat...@wikimedia.org> wrote:
>>
>>> Reminder: This is happening tomorrow, starting 09:00 PST(16:00 UTC).
>>>
>>> On Wed, Jan 4, 2017 at 1:43 PM, Madhumitha Viswanathan <
>>> mviswanat...@wikimedia.org> wrote:
>>>
 Hello,

 Continuing the storage redundancy and reliability efforts for Labs (
 https://phabricator.wikimedia.org/T126083), the final migration to the
 new NFS storage cluster for Labs projects with NFS enabled is upcoming. The
 migration is planned to happen 2017-01-18 starting 09:00 PST(16:00
 UTC). This *does not* affect tools, maps or any other projects that don't
 have /home or /data/project mounted. The migration window is expected to be
 fairly short (<3 hours) - but could last up to 6 hours.

 During the migration, no new data will be written to NFS (/home or
 /data/project), but existing data will be accessible in Read-only mode for
 the most part. Post migration, any services or jobs that were running on
 top of NFS (/home or /data/project) will require manual restarts. Jobs
 running on top of /scratch or /public/dumps will be unaffected. I will keep
 the lists and #wikimedia-labs updated on progress during and after the
 migration.

 The list of labs projects that will be affected in this migration are:


- catgraph


- account-creation-assistance


- contributors


- wikidata-topicmaps


- sugarcrm


- wikidumpparse


- video


- openstack


- testlabs


- wikidata-dev


- quarry


- huggle


- editor-engagement


- utrs


- wmt


- cvn


- fastcci


- toolsbeta


- project-proxy


- dumps


- bots


- snuggle


- math


- wikisource-tools


 The tracking task on phabricator is here - https://phabricator.wikimedi
 a.org/T154336. Let us know if you have any questions or concerns on
 the list or on #wikimedia-labs.

 --
 Madhu Viswanathan
 Operations Engineer, Wikimedia Labs

>>>
>>>
>>>
>>> --
>>> --Madhu :)
>>>
>>
>>
>>
>> --
>> --Madhu :)
>>
>
>
>
> --
> --Madhu :)
>



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

Re: [Wikitech-l] catching errors in local JavaScript

[Eran Rosenthal]

I wrote 2 years ago a phantom-js based script to catch all JS errors in all
wikis:
https://github.com/eranroz/wiki-js-error-log

See also:
https://phabricator.wikimedia.org/T71519




On Wed, Jan 18, 2017 at 6:37 PM, Jeremy Baron  wrote:

> On Jan 18, 2017 11:26, "Amir E. Aharoni" 
> wrote:
>
> Remind me please, were there ever any efforts to get client-side JavaScript
> errors monitored centrally?
>
>
> I think you're looking for
> https://phabricator.wikimedia.org/project/profile/976/ aka
> https://phabricator.wikimedia.org/tag/sentry/
>
> -Jeremy
> ___
> 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

Re: [Wikitech-l] [Wikimedia Labs][Announce] NFS (only labs projects) maintenance on 2017-01-18

[Madhumitha Viswanathan]

Update: this is still in progress. There's some ongoing issues with home
directories on non-nfs /home across Labs (not tools or maps) - we are
working on it, and will update soon. Do feel free to reach out
#wikimedia-labs if you have any questions or concerns.

On Wed, Jan 18, 2017 at 8:38 AM, Madhumitha Viswanathan <
mviswanat...@wikimedia.org> wrote:

> Reminder: This is starting soon, in ~22 minutes.
>
> On Tue, Jan 17, 2017 at 12:07 PM, Madhumitha Viswanathan <
> mviswanat...@wikimedia.org> wrote:
>
>> Reminder: This is happening tomorrow, starting 09:00 PST(16:00 UTC).
>>
>> On Wed, Jan 4, 2017 at 1:43 PM, Madhumitha Viswanathan <
>> mviswanat...@wikimedia.org> wrote:
>>
>>> Hello,
>>>
>>> Continuing the storage redundancy and reliability efforts for Labs (
>>> https://phabricator.wikimedia.org/T126083), the final migration to the
>>> new NFS storage cluster for Labs projects with NFS enabled is upcoming. The
>>> migration is planned to happen 2017-01-18 starting 09:00 PST(16:00
>>> UTC). This *does not* affect tools, maps or any other projects that don't
>>> have /home or /data/project mounted. The migration window is expected to be
>>> fairly short (<3 hours) - but could last up to 6 hours.
>>>
>>> During the migration, no new data will be written to NFS (/home or
>>> /data/project), but existing data will be accessible in Read-only mode for
>>> the most part. Post migration, any services or jobs that were running on
>>> top of NFS (/home or /data/project) will require manual restarts. Jobs
>>> running on top of /scratch or /public/dumps will be unaffected. I will keep
>>> the lists and #wikimedia-labs updated on progress during and after the
>>> migration.
>>>
>>> The list of labs projects that will be affected in this migration are:
>>>
>>>
>>>- catgraph
>>>
>>>
>>>- account-creation-assistance
>>>
>>>
>>>- contributors
>>>
>>>
>>>- wikidata-topicmaps
>>>
>>>
>>>- sugarcrm
>>>
>>>
>>>- wikidumpparse
>>>
>>>
>>>- video
>>>
>>>
>>>- openstack
>>>
>>>
>>>- testlabs
>>>
>>>
>>>- wikidata-dev
>>>
>>>
>>>- quarry
>>>
>>>
>>>- huggle
>>>
>>>
>>>- editor-engagement
>>>
>>>
>>>- utrs
>>>
>>>
>>>- wmt
>>>
>>>
>>>- cvn
>>>
>>>
>>>- fastcci
>>>
>>>
>>>- toolsbeta
>>>
>>>
>>>- project-proxy
>>>
>>>
>>>- dumps
>>>
>>>
>>>- bots
>>>
>>>
>>>- snuggle
>>>
>>>
>>>- math
>>>
>>>
>>>- wikisource-tools
>>>
>>>
>>> The tracking task on phabricator is here - https://phabricator.wikimedi
>>> a.org/T154336. Let us know if you have any questions or concerns on the
>>> list or on #wikimedia-labs.
>>>
>>> --
>>> Madhu Viswanathan
>>> Operations Engineer, Wikimedia Labs
>>>
>>
>>
>>
>> --
>> --Madhu :)
>>
>
>
>
> --
> --Madhu :)
>



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

[Wikitech-l] 2017-01-18 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-01-18

= 2017-01-18 =

== Product ==

=== Reading ===

 Mobile Content Service (MCS) 
* Board: https://phabricator.wikimedia.org/project/board/1323/query/open/
* Working on:
** Clicking on references is broken (Broken in the Android app; a Parsoid
change caused this) https://phabricator.wikimedia.org/T155070
** Improving regression testing

Android
* Last week:
** Dev summit and all hands
** Start on improving offline support quarterly goal
** New account creation broken in API 25 T155535
** Investigate reverted edit notifications failure
* Next week (https://phabricator.wikimedia.org/project/view/2352/ ):
** Work towards release of Wikidata description editing
** Continue on improved offline experience

 iOS native app 
* Last Week
** Dev summit, All hands, released 5.3.4 -
https://phabricator.wikimedia.org/project/view/2396/
** Continued work on 5.4 -
https://phabricator.wikimedia.org/project/view/2326/
* This week
** Continue work on 5.4 - Places, Login enhancements
https://phabricator.wikimedia.org/project/view/2326/

 Web 
* Last week:
** Dev summit and all hands
** Current sprint:
https://phabricator.wikimedia.org/tag/reading-web-sprint-89-%F0%9F%8E%82/
* Next sprint: https://phabricator.wikimedia.org/project/view/2426/
** Deploy Wikidata description and Related Articles on enwiki mobile

=== Editing ===
 Collaboration 
* Blocked -
* Blocking -
* Updates
** Main patch for RecentChanges page UI finished and merged (Adding new
interface for review filters to RecentChanges).
** Add userExpLevel filter in the RCFilters UI
** Continuing related work to this, including backend.
** Some meetings at Dev Summit about ReviewStream (part of Edit Review
Improvements) and WikiLabels admin interface
** Flow consistency fixes

== Technology ==
=== Analytics ===
Updates:
* Continuing with the work to replace front end and backend of
http://stats.wikimedia.org : Wikistats 2.0, a mjor development is that
we will be able to import the edit history from labs rather than prod dbs,
huge advantage as this data is redacted and already public.*

* Working on launching RCStream replacement, review stream plus several
other real time streams. Will start working with collaboration
on augmented ORES recent changes stream.

* Started work on processing user_agent field on eventlogging tables, it
will be a json string like {"OS_Family": "Windows",
"Browser_family":"Chrome"}

* Found issue with Heap on cluster, set up alarms, will be solved with
update to cloudera's newest

* Still waiting for hardware for pageview API, getting closer

=== Release Engineering ===
* '''Bocked'''
** None
* '''Blocking'''
** None?
* '''Updates'''
** Deployment is back to normal, train is on schedule:
https://tools.wmflabs.org/versions/
** Scap 3.5 release eminent, changelog will be sent, check on beta please

=== Services ===
* Blockers: none
* Updates:
** Node 6 upgrade is coming: https://phabricator.wikimedia.org/T149331
*** RESTBase updated, great improvement in memory consumption
*** Parsoid today
*** SCB tomorrow
*** MCS, CXServer, EventStreams - if you have something to deploy - do
it TODAY!

=== Discovery ===
* No blockers
* Continuing work on crosswiki searches
* Special:Search refactoring merged in
* Started work on improving wikidata search
* Started preparing for upgrade to ElasticSearch 5
* Added app links to portal homepage

== German Technical Wishlist ==
* Collecting what we learned at the Dev Summit
* Decided to not render URLs in the Electron PDF export any more
https://phabricator.wikimedia.org/T152393
* Can we help investigating why Kartographer does not work with flagged
revs, to support German Wikipedia? https://phabricator.wikimedia.org/T151665

== Wikidata ==
* Slow week, key people are still in the US
* Currently focusing on backend services for federation ("Wikidata on
Commons") https://phabricator.wikimedia.org/T76007

== Fundraising Tech ==
* CentralNotice banner impressions in pivot:
https://pivot.wikimedia.org/#banner-impressions-hourly
* More work to prevent unintended duplicate donations
* More CiviCRM customization moved to a real Civi extension
* Easing import of employer matching gifts
* Examining contractor fileshare change
* Casey training on ops-y stuff with Jeff and preparing to announce a job
opening
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Google Code-in 2016 is over. Congratulations everybody!

[Andre Klapper]

Google Code-in 2016 ended today.

Our students resolved a total of 424 Wikimedia tasks. Thanks to our 46
mentors for being available, also on weekends & holidays. Thanks to
everybody on IRC for your friendliness, patience, and help provided.

Some latest students' achievements:
* jQuery.suggestions used to add reason suggestions to block/delete/protect 
forms
* Created a {{PAGELANGUAGE}} magic word
* The Newsletter extension received more fixes and improvements
* Integrated SwaggerUI with the service template
* Special:PageLanguage allows a user to enter a reason/comment
* More MediaWiki code removed that was marked for removal in a past release
* More updated screencast videos on the Phabricator help pages
* More split videos of Wikimedia's CREDIT showcases
* 
https://meta.wikimedia.org/wiki/Research_on_open_source_team_communication_tools

The Grand Prize winners & finalists will be announced on January 30th.

Do you have any ideas or feedback what to improve for next time? 
Add it to https://phabricator.wikimedia.org/T154620 !

Again congratulations everybody, and thanks for your hard work!

See you around on IRC, mailing lists, Gerrit, and Phabricator!

Cheers,
andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/

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

Re: [Wikitech-l] catching errors in local JavaScript

[James Hare]

I would find such a tool to be extremely useful as well. I am working on an
extension that uses a considerable amount of JavaScript and while we’re
trying to find as many breakdowns as we can, it’s entirely possible we’ll
miss something and the person who discovers the bug won’t be familiar with
debugging tools like the in-browser JavaScript console.


On January 18, 2017 at 8:26:32 AM, Amir E. Aharoni (
amir.ahar...@mail.huji.ac.il) wrote:

Hallo Wikitech community,

Remind me please, were there ever any efforts to get client-side JavaScript
errors monitored centrally?

What happens currently is that JS code can frequently fail, taking down the
rest of JS on the page with it. It happens both with JS code properly
deployed from Gerrit and loaded by RL, but even more so with local gadgets,
Common.js, and user scripts.

The most frequent effects of this into which I ran are Visual Editor not
working at all and WikiEditor's toolbar not appearing in the source editing
window. There are many more.

On projects with a lot of editors and administrators, like the English and
the German Wikipedia, this will probably be quickly noticed and
fixed—sometimes fixed locally, and sometimes fixed in Gerrit and deployed
in SWAT. But in smaller projects it can fail for months without being
noticed. And when I say "smaller", I don't mean the tiny projects with
almost no editors—such a thing happened recently in the Japanese Wikipedia,
a top-10 project, and I helped administrators there to fix the buggy code,
which appeared in the second most-popular gadget.

I did this dozens of times, and Krinkle probably does this even more than
me. Often admins from different projects help each other, and it is great
that we have this mutual help in the community, but aren't there better
ways to catch such errors?

I remember there were discussions about this, but I don't remember what was
the outcome.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
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

Re: [Wikitech-l] [Wikimedia Labs][Announce] NFS (only labs projects) maintenance on 2017-01-18

[Madhumitha Viswanathan]

Reminder: This is starting soon, in ~22 minutes.

On Tue, Jan 17, 2017 at 12:07 PM, Madhumitha Viswanathan <
mviswanat...@wikimedia.org> wrote:

> Reminder: This is happening tomorrow, starting 09:00 PST(16:00 UTC).
>
> On Wed, Jan 4, 2017 at 1:43 PM, Madhumitha Viswanathan <
> mviswanat...@wikimedia.org> wrote:
>
>> Hello,
>>
>> Continuing the storage redundancy and reliability efforts for Labs (
>> https://phabricator.wikimedia.org/T126083), the final migration to the
>> new NFS storage cluster for Labs projects with NFS enabled is upcoming. The
>> migration is planned to happen 2017-01-18 starting 09:00 PST(16:00 UTC).
>> This *does not* affect tools, maps or any other projects that don't have
>> /home or /data/project mounted. The migration window is expected to be
>> fairly short (<3 hours) - but could last up to 6 hours.
>>
>> During the migration, no new data will be written to NFS (/home or
>> /data/project), but existing data will be accessible in Read-only mode for
>> the most part. Post migration, any services or jobs that were running on
>> top of NFS (/home or /data/project) will require manual restarts. Jobs
>> running on top of /scratch or /public/dumps will be unaffected. I will keep
>> the lists and #wikimedia-labs updated on progress during and after the
>> migration.
>>
>> The list of labs projects that will be affected in this migration are:
>>
>>
>>- catgraph
>>
>>
>>- account-creation-assistance
>>
>>
>>- contributors
>>
>>
>>- wikidata-topicmaps
>>
>>
>>- sugarcrm
>>
>>
>>- wikidumpparse
>>
>>
>>- video
>>
>>
>>- openstack
>>
>>
>>- testlabs
>>
>>
>>- wikidata-dev
>>
>>
>>- quarry
>>
>>
>>- huggle
>>
>>
>>- editor-engagement
>>
>>
>>- utrs
>>
>>
>>- wmt
>>
>>
>>- cvn
>>
>>
>>- fastcci
>>
>>
>>- toolsbeta
>>
>>
>>- project-proxy
>>
>>
>>- dumps
>>
>>
>>- bots
>>
>>
>>- snuggle
>>
>>
>>- math
>>
>>
>>- wikisource-tools
>>
>>
>> The tracking task on phabricator is here - https://phabricator.wikimedi
>> a.org/T154336. Let us know if you have any questions or concerns on the
>> list or on #wikimedia-labs.
>>
>> --
>> Madhu Viswanathan
>> Operations Engineer, Wikimedia Labs
>>
>
>
>
> --
> --Madhu :)
>



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

Re: [Wikitech-l] catching errors in local JavaScript

[Jeremy Baron]

On Jan 18, 2017 11:26, "Amir E. Aharoni" 
wrote:

Remind me please, were there ever any efforts to get client-side JavaScript
errors monitored centrally?


I think you're looking for
https://phabricator.wikimedia.org/project/profile/976/ aka
https://phabricator.wikimedia.org/tag/sentry/

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

[Wikitech-l] catching errors in local JavaScript

[Amir E. Aharoni]

Hallo Wikitech community,

Remind me please, were there ever any efforts to get client-side JavaScript
errors monitored centrally?

What happens currently is that JS code can frequently fail, taking down the
rest of JS on the page with it. It happens both with JS code properly
deployed from Gerrit and loaded by RL, but even more so with local gadgets,
Common.js, and user scripts.

The most frequent effects of this into which I ran are Visual Editor not
working at all and WikiEditor's toolbar not appearing in the source editing
window. There are many more.

On projects with a lot of editors and administrators, like the English and
the German Wikipedia, this will probably be quickly noticed and
fixed—sometimes fixed locally, and sometimes fixed in Gerrit and deployed
in SWAT. But in smaller projects it can fail for months without being
noticed. And when I say "smaller", I don't mean the tiny projects with
almost no editors—such a thing happened recently in the Japanese Wikipedia,
a top-10 project, and I helped administrators there to fix the buggy code,
which appeared in the second most-popular gadget.

I did this dozens of times, and Krinkle probably does this even more than
me. Often admins from different projects help each other, and it is great
that we have this mutual help in the community, but aren't there better
ways to catch such errors?

I remember there were discussions about this, but I don't remember what was
the outcome.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New 1.27/1.28 login mechanism

[Florian Schmidt]

Hi!

Logging in an user without using the UserLogin form or any other interaction of 
the user sounds like a SessionProvider for me, instead of an authentication 
provider. Take a look at:
https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager

However, I haven't implemented it so far, but you could take a look at some 
examples, e.g. the OAuth extension:
https://github.com/wikimedia/mediawiki-extensions-OAuth/blob/master/api/MWOAuthSessionProvider.php
(however, as the description says: There're some unusual steps in the execution 
code, so you shouldn't simply copy it)

Another example could be the CentralAuth extension:
https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/b2d52e1a1a0fb317ba4f8799beb0641cf8b6568b/includes/session/CentralAuthTokenSessionProvider.php

I hope that helps!

In MediaWiki 1.29 (I think it was 1.29 and not 1.28) we implemented a way to 
bypass the login page, but that requires that you disable all authentication 
providers, instead of one, which need to provide a button only, for a redirect 
to an external page).

Best,
Florian

-Original-Nachricht-
Betreff: [Wikitech-l] New 1.27/1.28 login mechanism
Datum: 2017-01-18T00:20:07+0100
Von: "Aran" 
An: "Wikimedia developers" 

Hello,

I have a login system that extends the
AbstractPrimaryAuthenticationProvider and uses an AuthenticationRequest
that returns an empty fields array so that the login form is bypassed
completely and login is determined by some other environmental
parameters. But in 1.27 this does not bypass the login form.

What is the proper way I should be making the login page determine login
without a login form?

Thanks,
Aran


___
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