Vagrant is a command-line tool for automatically provisioning virtual machines
according to scripted specifications. The mediawiki-vagrant project bundles
together specifications for quickly and easily provisioning a virtual machine
running MediaWiki, suitable for development work.
I announced
What about inserting another domain just to prevent confusion and to
keep current redirects, which would ONLY allow api, such as
commons.api.wikipedia.org
the *.api.project would just be some kind of universal api gateway
for all domains
On Wed, Mar 27, 2013 at 10:07 PM, Juliusz Gonera
How is that meant to pervent confusion? you are just sticking a extra
.api in the address.
On Thu, Mar 28, 2013 at 5:41 PM, Petr Bena benap...@gmail.com wrote:
What about inserting another domain just to prevent confusion and to
keep current redirects, which would ONLY allow api, such as
or MAYBE, even more evil:
commons.wikimedia.api.wikipedia.org -- where first two domains
commons.wikimedia would point to existing domain, that would actually
allow you to enable this gateway instantly on all projects for all
domains, so that you could use api of fr.wikisource using wikispecies
because right now commons.wikipedia.org is already redirecting to wikimedia
if you change this behavior now, you may confuse some people who were
expecting it to redirect... but I don't really care
On Thu, Mar 28, 2013 at 8:44 AM, K. Peachey p858sn...@gmail.com wrote:
How is that meant to
A small issue in this proposition: sub-subdomains are not currently
covered by the https certificate.
~s
Le Thu, 28 Mar 2013 08:41:41 +0100, Petr Bena benap...@gmail.com a écrit:
What about inserting another domain just to prevent confusion and to
keep current redirects, which would ONLY
This is awesome, I've used it as a total MediaWiki noob to poke around at
the internals. One suggestion I'd have is to include a script that
populates some sample data in the db (pages, users, edits, etc.). Does
anyone have such a thing, should we dump a particularly active test setup
from
Hi,
Please join us on the next Wikimedia Bugday:
Tuesday, April 02, 2013 from 16:30 UTC until 20:30 UTC [1]
in #wikimedia-office on Freenode IRC [2]
We will be triaging skin and page rendering bug reports [3] as proposed
on the Bugsquad project talk page [4].
Everyone is welcome to
We have a first write up of how we plan to support queries in Wikidata.
Comments on our errors and requests for clarifications are more than
welcome.
https://meta.wikimedia.org/wiki/Wikidata/Development/Queries
Cheers,
Denny
P.S.: unfortunately, no easter eggs inside.
--
Project director
Le 27/03/13 15:35, Andre Klapper a écrit :
OpenStack also have live graphs at http://status.openstack.org/bugday/
for their bugdays (e.g.
https://wiki.openstack.org/wiki/BugDays/20121213BugSquashing ), but I
have no idea about the implementation, plus bugdays look dormant there.
If anybody
On Wed, 2013-03-27 at 15:35 +0100, Andre Klapper wrote:
OpenStack also have live graphs at http://status.openstack.org/bugday/
for their bugdays (e.g.
https://wiki.openstack.org/wiki/BugDays/20121213BugSquashing ), but I
have no idea about the implementation, plus bugdays look dormant there.
How will be the queries formatted? Do I understand it correctly that a
QueryConcept is a JSON object?
Have you considered using something more in line with the format of
action=query queries?
Though I guess what you need is much more complicated and trying to
fit it into the action=query model
On Thu, Mar 28, 2013 at 7:18 AM, Ori Livneh o...@wikimedia.org wrote:
I hope you check it out, and that you find it useful. Feedback would be
much appreciated.
I have tried it at two Mac machines, it worked without any problems.
Željko
___
I tried it out on my Windows XP, and on `vagrant up` it promptly took all the
1.5 GB of free space on disk C: and crashed (I purposefully keep my system
partition small).
Is it possible to make it write the big files (the downloaded OS image and the
virtual disk) into somewhere else than
Ori, thanks for the great dev environment :)
As mentioned in another email, I would like to have the following added to
default vagrant installation. Having default dev environment would allow us
to quickly get new developers up to speed almost without
any walk-through steps.
* redirect from /
On Thu, Mar 28, 2013 at 8:45 AM, Petr Bena benap...@gmail.com wrote:
I don't know if that is actually good for anything :) but it would
surely allow you to bypass cookie restrictions everywhere (for api's
only). On the other way, I think we could just think of using some
different technology
On Thu, Mar 28, 2013 at 9:59 AM, Seb35 seb35wikipe...@gmail.com wrote:
A small issue in this proposition: sub-subdomains are not currently
covered by the https certificate.
That would make only commons.api.wikipedia.org not work, but not
commons.wikipedia.org, right?
--
Juliusz
Le Fri, 29 Mar 2013 00:45:03 +0100, Juliusz Gonera jgon...@wikimedia.org
a écrit:
On Thu, Mar 28, 2013 at 9:59 AM, Seb35 seb35wikipe...@gmail.com wrote:
A small issue in this proposition: sub-subdomains are not currently
covered by the https certificate.
That would make only
On Thursday, March 28, 2013 at 4:41 PM, Yuri Astrakhan wrote:
As mentioned in another email, I would like to have the following added to
default vagrant installation. Having default dev environment would allow us
to quickly get new developers up to speed almost without
any walk-through
19 matches
Mail list logo
