Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
Hi,
YuviPanda, prtksxna, and myself (with help from Tim and Aaron) have been
working the UrlShortener extension, which is designed to implement the
URL shortener RfC[1] (specifically Tim's implementation suggestion).
I've filed T108557[2] to deploy the extension to Wikimedia wikis. We'd
like to use the "w.wiki" short domain, which the WMF is already in
control of.
A test wiki has been set up mimicking what Wikimedia's configuration
would be like: http://urlshortener.wmflabs.org/, and has an accompanying
"short" domain at us.wmflabs.org (e.g. http://us.wmflabs.org/3). Please
play with it and report any bugs you might find :)
[1] https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener
[2] https://phabricator.wikimedia.org/T108557
Thanks,
-- Legoktm
Hi,
I only now noticed that Phabricator has blogs:
https://phabricator.wikimedia.org/phame/blog/
I couldn't find a way to subscribe to them in RSS. Is it possible?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
"I came across a patch from a user who was keen to move himself from
"Patch contributors" to "Developers" in the MediaWiki CREDITS file
[1]. It had been sitting there for over a year. He doesn't seem to
have been active since. I don't know what to do with it. It made me
think.
Do we have it documented anywhere how we use this credits file and why
we feel the need to distinguish between Developers and Patch
Contributors? It seems like a recipe for disaster in my opinion as it
can only lead to hurt feelings due to contributors feeling unfairly
treated. https://www.mediawiki.org/wiki/Special:Version/Credits leads
with 'We would like to recognize the following persons for their
contribution to MediaWiki." - if someone is not in that list are they
not as important?
If we keep these files we should probably explain the rules to what
adding names looks like within these files and what the process to
adding your name is (can I add myself? Is there a process like getting
+2?)
To take another extreme, we might consider abandoning such a file in
favour of something automatically generated. Things like
https://github.com/wikimedia/mediawiki/graphs/contributors do a far
better job at allowing people to see who contributed to a tool and
making people feel like their work is rewarded.
On a slightly related note, can we abandon the practice of putting
names inside files themselves? I see this practice in JavaScript and
PHP files throughout core (grep for @author). As Team Geek [2] (great
read btw) says "unlike other collaborative pieces of creative work...
software keeps changing even after it's "done". So while listing
contributors credits at the end of a movie is a safe and static thing,
attempting to add and remove names from a source file is a
never-ending exercise in insanity". For similar reasons this practice
gives an impression of ownership of a file/code review
responsibilities (which are not always true) and risks hurt feelings.
[1] https://github.com/wikimedia/mediawiki/blob/master/CREDITS
[2] http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=9781449302…
Hi all,
Etherpad [0], our real-time colaborative editing tool suffered an
outage due to what we only know for now was database corruption. This
was detected shortly after it happened 14:27 UTC and we (ops in charge
of the service and the database) worked to reestablish the service.
As the service continued crashing despite our efforts, we decided to
recover a database backup from 2016-06-22 01:00:01 UTC. The service is
now back up and working since 16:11 UTC, but that means that you may
have lost a day and a half of edits in the current available etherpad
[0].
I understand that that may cause a lot of inconveniences, specially
for the people at Wikimania. *We are now trying to recover more than
that*, but as the corruption could come back, or not all could be
recovered, and people need the service the plan is the following:
- Keep the current pads as is, not delete or add anything from now.
You can continue using etherpad now as usual.
- If possible, recover the last days of edits on a separate location.
See [1] for progress if you are affected.
Sorry for the inconveniences. Please, more than ever, follow the
recommendation we added at the beginning of every empty pad:
> "Keep in mind as well that there is no guarantee that a pad's contents will always be available. A pad may be corrupted, deleted or similar. Please keep a copy of important data somewhere else as well"
The reason for this is that wiki content has proper HA and redundancy,
etherpad does not.
Again, my most sincere apologies,
[0] <https://etherpad.wikimedia.org/>
[1] <https://phabricator.wikimedia.org/T138516>
--
Jaime Crespo
<http://wikimedia.org>
Hi,
the first image scaler based on Debian jessie is now enabled in
production. Despite other changes this also provides an update
of librsvg to 2.40.16 which fixes several long-standing bugs in
SVG rendering:
https://phabricator.wikimedia.org/T44090https://phabricator.wikimedia.org/T64987https://phabricator.wikimedia.org/T97758https://phabricator.wikimedia.org/T111815
(Please note that this currently only applies to one out of eight
systems, I'll send a followup once all scalers are migrated).
This has been tested quite a bit and no problems were found, but if
you notice anything unusual related to image/SVG scaling (e.g. due to
font changes) please drop a note in #wikimedia-operations or file a
Phabricator task and add the Operations project.
Cheers,
Moritz
== tl;dr ==
On June 29th git.wikimedia.org (running Gitblit) will redirect all
requests to Phabricator. The vast majority of requests will be correctly
redirected.
== What is happening? ==
In an effort to reduce the maintenance burden of redudant services we
will be removing git.wikimedia.org. The software that has been serving
git.wikimedia.org, Gitblit, has given our Operations team many headaches
over the years[0] and now that we have all repositories hosted in
Phabricator[1] there is no reason to keep Gitblit around. Phabricator's
Diffusion (the name of the code browser) provides the needed
functionality that Gitblit served (mostly viewing/browsing repositories,
something which Gerrit does not do).
== When will it happen? ==
June 29th
https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20160629T1600
== How could this affect me? ==
Potentially, you use an unpopular (in the sense of not used often)
feature of Gitblit that is not supported in Diffusion. This should be
unlikely.
Potentially, a link you follow that pointed to somewhere on
git.wikimedia.org will not redirect correctly. This is also unlikely as
we (mostly @Danny_B and @Paladox) took great care to update many
mediawiki.org templates along with providing very robust redirect
rules[2]. If you find one that isn't working, please let us know (along
with the original url and, if possible, the desired target in
Diffusion).
One known issue to call out: Diffusion does not list commits by person.
However Differential (the code-review tool) does this (not just for new
commits). There is no easy/maintainable way to redirect those,
unfortunately.
Something else broken? Please file a task in Phabricator in the
#Diffusion project[3].
Thanks,
Greg, on behalf of WMF Release Engineering (and all the volunteers who
helped along the way (and Ops!))
[0] eg: https://phabricator.wikimedia.org/T73974
[1] https://phabricator.wikimedia.org/diffusion/
[2] https://phabricator.wikimedia.org/T137224
[3] https://phabricator.wikimedia.org/project/profile/53/
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hey all,
Following a brief chat in IRC, I've proposed[0] adding curl to the list of
PHP extensions required by MediaWiki, and Chad thought it'd be a good idea
to get wider thoughts before merging.
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 already require mbstring (as discussed in March) alongside xml, ctype,
json, and iconv. If you have an opinion, please weigh in on the task.[1]
[0] - https://gerrit.wikimedia.org/r/#/c/294259/
[1] - https://phabricator.wikimedia.org/T137926
J.
--
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester