[Wikitech-l] Fwd: [Wikimedia Announcements] Invitation to WMF January 2017 Metrics & Activities Meeting: Thursday, January 26, 19:00 UTC

[Pine W]

Forwarding from WikimediaAnncounce-l to Wikimedia-l because auto-foward is
still not working. Also forwarding to Wikitech-l and MediaWiki-l because
the "Reconstructing MediaWiki history" presentation sounds like it may be
of interest to some people on those lists.

Pine


-- Forwarded message --
From: Lena Traer 
Date: Thu, Jan 19, 2017 at 4:41 PM
Subject: [Wikimedia Announcements] Invitation to WMF January 2017 Metrics &
Activities Meeting: Thursday, January 26, 19:00 UTC
To: wikimediaannounc...@lists.wikimedia.org


Hello everyone,

The next Wikimedia Foundation metrics and activities meeting will take
place on Thursday, January 26, 2017 at 7:00 PM UTC (11 AM PST). The IRC
channel is #wikimedia-office on irc.freenode.net, and the meeting will be
broadcast as a live YouTube stream.

The theme of the January meeting is: "Building our future” – Exploring how
we can build for the future of the Wikimedia movement together.

Meeting agenda:

* Welcomes, theme introduction
* Movement update
* Reconstructing MediaWiki history
* Community capacity development
* Executive update
* Questions and discussion
* Wikilove

Please review
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_metrics_and_activities_
meetings
for further information about the meeting and how to participate.

We’ll post the video recording publicly after the meeting.

Thank you,
Lena

Lena Traer
Project Assistant // Communications // Advancement
Wikimedia Foundation
149 New Montgomery Street
San Francisco, CA 94105

___
Please note: all replies sent to this mailing list will be immediately
directed to Wikimedia-l, the public mailing list of the Wikimedia
community. For more information about Wikimedia-l:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
___
WikimediaAnnounce-l mailing list
wikimediaannounc...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
___
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

[Amir E. Aharoni]

That's OK—I mainly want to know that the error occurred at all.


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

2017-01-19 12:16 GMT-08:00 Bartosz Dziewoński :

> Oh, and also, a more general limitation: the error messages may be
> localised, depending on the browser. I hope you speak Korean.
>
>
> --
> Bartosz Dziewoński
>
> ___
> 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] catching errors in local JavaScript

[Bartosz Dziewoński]

Oh, and also, a more general limitation: the error messages may be 
localised, depending on the browser. I hope you speak Korean.


--
Bartosz Dziewoński

___
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

[Gergo Tisza]

On Thu, Jan 19, 2017 at 1:35 AM, Federico Leva (Nemo) 
wrote:

> AFAIK https://www.mediawiki.org/wiki/Extension:Sentry is the way to go,
> perhaps currently blocked on procurement (https://phabricator.wikimedia
> .org/T93138 ).
>

It's stalled due to lack of time, with a fair amount of puppet wrangling
still needed before it could go into production even as a limited
experiment.

Also, a lot of its value is conditional on source maps (T47514
) which AFAIK is also stalled due
to lack of time.

On Thu, Jan 19, 2017 at 10:58 AM, Bartosz Dziewoński 
 wrote:

> Using EventLogging mostly works, but it has some strict limitations on the
> size of data you can record there, so we can't save for example error
> backtraces. That's still much better than nothing at all, though.


It also wouldn't scale to logging every error on every page, although if
you are interested in gadget errors, you could just restrict it to
logged-in users.

It would probably be possible to get more intelligent heuristics by moving
some of the logic from the Sentry extension to use the EventLogging
pipeline (load raven-js on errors, get the stack trace, send the top few
rows of it + a hash to EL), to deduplicate browser/language error message
differences and detect errors which originate in gadgets. Not sure how far
you could get without source maps though.
___
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

[Bartosz Dziewoński]

UploadWizard has such a mechanism, recording all JavaScript exceptions 
that happen on https://commons.wikimedia.org/wiki/Special:UploadWizard
(using some of the machinery originally designed for Sentry, some custom 
glue code, and some EventLogging definitions).


Using EventLogging mostly works, but it has some strict limitations on 
the size of data you can record there, so we can't save for example 
error backtraces. That's still much better than nothing at all, though.


You'll also find that, unless a problem is affecting literally everyone 
on every page, it's really difficult to separate problems in code you 
can fix from problems in code you can't. Turns out that a large number 
of people use very broken browser extensions, or user scripts, or 
browser, or entire computers, that throw exceptions left and right 
whenever the user looks at it wrong. Since browsers' security features 
and ResourceLoader's mechanisms often hide the real source of the error, 
you have to investigate everything by hand. And that's my experience 
only looking at errors happening on one page, on one wiki. :)



--
Bartosz Dziewoński

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

[Wikitech-l] Minor change to SWAT windows

[Greg Grossmeier]

tl;dr: I have removed the Tuesday 19:00 UTC SWAT window from the
deployment calendar due to conflicts. Pick one of the other 11 SWAT
windows.

The (current) Tuesday 19:00 UTC SWAT window is directly before the 20:00
UTC MediaWiki train window.

The nature of SWAT windows meant that the state of the deployed
MW+Extension+Config code was changing while the creation of the new MW
train version (eg: 1.29-wmf.8) was happening. This causes delays and
confusion.

The simple solution is to not have a normal SWAT window at that time.
Other deploys (eg Services) are fine to happen at that time which is why
I didn't just extend the MW train window to include that earlier hour.

Luckily, you still have 11 SWAT windows to choose from. :)

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team ManagerA18D 1138 8E47 FAC8 1C7D |


signature.asc
Description: PGP signature
___
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: 2 instances are still being restored - taxonbot.dwl and
pole.wikidata-query, the rest on the previous list are done.

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

> 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 :)
>



-- 
--Madhu :)
___
Wikitech-l mailing list

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

[MZMcBride]

Brad Jorsch (Anomie) wrote:
>On Wed, Jan 18, 2017 at 10:44 PM, Daniel Kinzler <
>daniel.kinz...@wikimedia.de> wrote:
>> ** Related discussion about whether new features can require services
>> serparate from MediaWiki core.
>
>That seems like it would be a decent RFC at some point.

Agreed.

There are often questions of debug and maintenance support and service
level for production services, from the Wikimedia (Foundation) operations
team and others. Clarifying the current situation and how it can be
modified in the future would be useful and alleviate some of the tensions
we've had, in my opinion.

The trickiness here is that some of this falls outside of the Architecture
committee's purview, particularly as no member of the operations team is
on the committee currently (Mark, Faidon, Alexandros, Giuseppe, et al.).
In my mind, there's what MediaWiki core and its extensions can do and can
require, but the relationship between MediaWiki and Wikimedia cannot be
completely sidestepped. With MediaWiki as the platform, there are also
questions about what wikimedia.org, mediawiki.org, wikipedia.org, and the
various other Wikimedia projects are willing to host and support. RESTBase
seems like a decent example of this interplay.

Daniel Kinzler wrote:
> 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.

"You know what they call a leader with no followers? Just a guy taking a
walk."

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

It depends how strictly you view requests for comments. A decent-size
Gerrit changeset that gets accepted and merged in is, in some ways, an
RFC, usually with one or more associated Phabricator Maniphest tasks.
Sometimes with associated mailing list or on-wiki discussion.

MZMcBride



___
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

[Brad Jorsch (Anomie)]

On Wed, Jan 18, 2017 at 10:44 PM, Daniel Kinzler <
daniel.kinz...@wikimedia.de> wrote:

> ** Related discussion about whether new features can require services
> serparate
> from MediaWiki core.
>

That seems like it would be a decent RFC at some point.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
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

[Federico Leva (Nemo)]

AFAIK https://www.mediawiki.org/wiki/Extension:Sentry is the way to go, 
perhaps currently blocked on procurement 
(https://phabricator.wikimedia.org/T93138 ).


https://phabricator.wikimedia.org/T106915 or 
https://phabricator.wikimedia.org/T382 might be the main discussions on 
the matter.


Nemo

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