FYI. A performance regression was found and we rolled back all wikis to
1.25wmf14. Follow the bug mentioned for updates.
- Forwarded message from Ori Livneh o...@wikimedia.org -
Date: Wed, 4 Feb 2015 02:49:37 -0800
From: Ori Livneh o...@wikimedia.org
To: Development and Operations
One strategy
employed by Netflix is to introduce a second API layer
http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html
on
top of the general content API to handle device-specific needs. I think
this is a sound strategy, as it contains the volatility in a
On Wed, Feb 4, 2015 at 8:51 AM, Brian Gerstle bgers...@wikimedia.org wrote:
TL;DR; this discussion is great, but I think moving to docs/wikis/etc.
instead of continuing the thread could improve communication and give the
people who end up working on this something to reference later. could just
On Tue, Feb 3, 2015 at 11:33 PM, Erik Moeller e...@wikimedia.org wrote:
I think you will generally find agreement that moving client-side
transformations that only live in the app to server-side code that
enables access by multiple consumers and caching is a good idea. If
there are reasons
On 4 February 2015 at 08:40, Bryan Davis bd...@wikimedia.org wrote:
+1 This sort of major design change is exactly the sort of thing that
I think the RfC process is good at helping with. Start with a straw
man proposal, get feedback from other engineers and iterate before
investing in code
Hi all,
it has been since the Dev Summit discussions on SOA/Microservices[1] that I am
pondering the outcomes and I am willing to post some afterthoughts to these
lists. Having been one of the most vocal in raising concerns about
microservices, and having had experience in an heavily
On Wed, Feb 4, 2015 at 8:41 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
Regarding general-purpose APIs vs. mobile: I think mobile is in some ways a
special case as their content transformation needs are closely coupled with
the way the apps are presenting the content. Additionally, at least
Hi, just a note to say that the Phabricator project for the Wikimedia
Hackathon 2015 (Lyon, 23-25 May) has been created.
https://phabricator.wikimedia.org/tag/wikimedia-hackathon-2015/
You are invited to ask questions, provide feedback, and get involved.
Important note: even if we are just
Thanks for all the ideas and suggestions. Will start with enabling oauth
right away.
I'm dead in php so I always look for python related hooks. I think this
will do for the oauth? http://pythonhosted.org/mwoauth/
As regards the conversion to webm instead of ogv, I tried but couldn't get
avconv
Hi Magnus,
On 02/04/2015 04:40 PM, Magnus Manske wrote:
I wrote a PHP class to specifically deal with the Wikimedia OAuth,
including uploads (not chunked though). May be helpful.
https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-02-04
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Minutes and slides from last week's quarterly review of the
Foundation's Editing (formerly VisualEditor) team await perusal at
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Editing/January_2015
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller
tl/dr: The technology we started building against (Titan) is probably
dead. We're reopening the investigation for a backing technology.
Yesterday DataStax http://www.datastax.com/ announced
http://www.datastax.com/2015/02/datastax-acquires-aurelius-the-experts-behind-titandb
that they'd acquired
What about a Gerrit Cleanup Day involving all Wikimedia Foundation
developers and whoever else wants to be involved?
Feedback welcome: https://phabricator.wikimedia.org/T88531
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Top posting to add context: this is for the initiative to get a version of
Magnus' wonderful http://wdq.wmflabs.org/ running in production at WMF.
On Wed, Feb 4, 2015 at 4:50 PM, Nikolas Everett never...@wikimedia.org
wrote:
tl/dr: The technology we started building against (Titan) is probably
But this doesn't remove it from the projects review queue (or search
queries, if you just use project:mediawiki/extensions/MobileFrontend
status:open).
IMHO the distinction between cleaning up personal and global dashboards
is not so important. In the end, code review is performed by
TL;DR; this discussion is great, but I think moving to docs/wikis/etc.
instead of continuing the thread could improve communication and give the
people who end up working on this something to reference later. could just
be my n00b-ness, but I thought others might share the sentiment.
I'm still
For the last year, I've been using schroot to run my local MediaWiki
test instance. After hearing some gripes about Vagrant at the Dev
Summit, I decided to share this idea by automating the setup procedure
and committing the scripts I use. You can read about it here:
Thanks for getting this started, Quim. Is this also the appropriate place
and is this the appropriate time to start proposing focus
areas/projects/sessions/etc? Is there already a theme/scope defined for
project ideas (eg I see a column on the workboard entitled 'New forms of
editing hack ideas' -
On Wed, Feb 4, 2015 at 11:41 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
Regarding general-purpose APIs vs. mobile: I think mobile is in some ways a
special case as their content transformation needs are closely coupled with
the way the apps are presenting the content. Additionally, at least
Go to a change https://gerrit.wikimedia.org/r/#/c/187879/3, click on the
gitbit
https://git.wikimedia.org/commit/apps%2Fios%2Fwikipedia/6532021b4f4b1f09390b1ffc3f09d149b2a8d9d1
link next to a patch set, then behold: MAGIC!!!
In general I'm in favor of more ad-hoc project-specific teams rather than
completely siloing every service to the Services group, or every mobile UI
to the Mobile group.
I strongly agree. Based on experience on both sides of this spectrum, I
recommend (when feasible) favoring feature teams over
On 4 February 2015 at 15:00, Brion Vibber bvib...@wikimedia.org wrote:
In general I'm in favor of more ad-hoc project-specific teams rather than
completely siloing every service to the Services group, or every mobile UI
to the Mobile group.
Agreed. This also ensures that the service exactly
Nice find. The link used to be labeled tree I believe. I'm not sure
it's more discoverable as gitblit, but some of this is moot as I
imagine Gitblit won't survive 2015. Assuming Gerrit stays around for a
while longer, perhaps it would be best to change the link in the Gerrit
user interface to read
On Wed, 2015-02-04 at 17:43 -0700, Arthur Richards wrote:
Thanks for getting this started, Quim. Is this also the appropriate place
and is this the appropriate time to start proposing focus
areas/projects/sessions/etc? Is there already a theme/scope defined for
project ideas (eg I see a column
On Mon, 2015-02-02 at 00:39 -0800, Pine W wrote:
It would be interesting to compare our trends to those of other open source
projects with open bug or task trackers.
For trends in other FOSS projects, see data I posted in
https://phabricator.wikimedia.org/T78639#936184
On Feb 1, 2015 7:47
flame war ahead
For those not adicted to slashdot, see here
http://news.slashdot.org/story/15/02/04/0332238/microsoft-open-sources-coreclr-the-net-execution-engine
.
Licenced under MIT
https://github.com/dotnet/coreclr/blob/master/LICENSE.TXT, plus an
additional patents promise
On Wed, Feb 4, 2015 at 5:09 AM, Yuri Astrakhan yastrak...@wikimedia.org
wrote:
flame war ahead
For those not adicted to slashdot, see here
http://news.slashdot.org/story/15/02/04/0332238/microsoft-open-sources-coreclr-the-net-execution-engine
.
Licenced under MIT
Functionally. If you make a loud public declaration WE SHALL NOT SUE
then you sue, judges *tend* to look upon it very unfavourably. YMMV of
course.
On 4 February 2015 at 13:42, Nikolas Everett never...@wikimedia.org wrote:
On Wed, Feb 4, 2015 at 5:09 AM, Yuri Astrakhan yastrak...@wikimedia.org
Good point. Ideally, what we would need to do is provide the right tools to
developers to create services, which can then be placed strategically
around DCs (in cooperation with Ops, ofc).
Yes. As an organization we should provide good tools that allow
developers to create services. I do fail
On Wed, Feb 4, 2015 at 2:33 AM, Erik Moeller e...@wikimedia.org wrote:
If not, then I think one thing to keep in mind is how to organize the
transformation code in a manner that it doesn't just become a
server-side hodgepodge still only useful to one consumer, to avoid
some of the pitfalls
I wrote a PHP class to specifically deal with the Wikimedia OAuth,
including uploads (not chunked though). May be helpful.
https://bitbucket.org/magnusmanske/magnustools/src/9dc80c2479a41239b9661b35504dcaaaedf367f7/public_html/php/oauth.php?at=master
On Wed Feb 04 2015 at 09:29:28 Nkansah
Hooray! Thank you for this! Gerrit's multi-tab diff has been my biggest
pain point in migrating from GitHub.
On Wed, Feb 4, 2015 at 2:34 PM, Brian Gerstle bgers...@wikimedia.org
wrote:
Go to a change https://gerrit.wikimedia.org/r/#/c/187879/3, click on the
gitbit
I think the way we'd want to go is roughly to have a *partnership between*
the Services and Mobile teams produce and maintain the service.
(Note that the state of the art is that Mobile Apps are using Mobile Web's
MobileFrontend extension as an intermediate API to aggregate format page
data --
On Wed, Feb 4, 2015 at 4:00 PM, Brion Vibber bvib...@wikimedia.org wrote:
I think the way we'd want to go is roughly to have a *partnership between*
the Services and Mobile teams produce and maintain the service.
(Note that the state of the art is that Mobile Apps are using Mobile Web's
35 matches
Mail list logo
