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
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?
"I came across a patch from a user who was keen to move himself from
"Patch contributors" to "Developers" in the MediaWiki CREDITS file
. 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
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
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
PHP files throughout core (grep for @author). As Team Geek  (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.
Etherpad , 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
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  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,
== tl;dr ==
On June 29th git.wikimedia.org (running Gitblit) will redirect all
requests to Phabricator. The vast majority of requests will be correctly
== 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 and now that we have all repositories hosted in
Phabricator 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? ==
== 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
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. If you find one that isn't working, please let us know (along
with the original url and, if possible, the desired target in
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,
Something else broken? Please file a task in Phabricator in the
Greg, on behalf of WMF Release Engineering (and all the volunteers who
helped along the way (and Ops!))
 eg: https://phabricator.wikimedia.org/T73974
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Following a brief chat in IRC, I've proposed 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
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.
 - https://gerrit.wikimedia.org/r/#/c/294259/
 - https://phabricator.wikimedia.org/T137926
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester