On 5 May 2014 22:59, Sumana Harihareswara <sumanah(a)wikimedia.org> wrote:
> Mozilla has a new Wiki Working Group[0] "to develop and drive a roadmap
> of improvements to http://wiki.mozilla.org". They're currently on
> MediaWiki 1.19, and I predict they will want to get onto 1.23 once that
> is released (since it's going to be the long-term support
> release[1][2]), and that they're going to want VisualEditor and Flow as
> soon as possible. However, they have a custom theme to port over.
Instant thread derail! So ... how is 1.23 and Visual Editor?
* Has anyone sat down and written out how to add VE magic to a 1.23
tarball install?
* VE is big and complicated. I'm not clear on what it needs. Parsoid
as a daemon or something?
* Are our esteemed packagers at Debian and Fedora in the loop?
I ask out of interest for my intranet stuff, where I would *love* a VE
to wave at users who basically can't work computers and are presently
just doing stuff as Google Docs.
- d.
So sorry for the cross-posting and for this shout for help that some can
read as a forum shopping, but this is really annoying.
https://bugzilla.wikimedia.org/show_bug.cgi?id=64622
In short, we on all Wikisource wikis are unable to start working on new
pages from digitized books (or for newly overwritten uploads) without
poking the server N times in order to generate a single resized image.
Please fix it ASAP. Please see also #c18 on the mentioned bug.
Hi all,
I'm planning to spend some time in Zurich getting a centralauth role for
vagrant working (part of
https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Topics#Production…).
I wanted to get opinions (probably more bikeshed) about how you would like
to access multiple wikis on a single vagrant instance. If anyone is
interested in using CentralAuth on vagrant for development/testing, please
chime in!
We can either use a different subdirectory per wiki, or different domain
per wiki.
Different domains is closer to how we run thing in production, but it would
require copying dns settings to your host (there doesn't seem to be a good,
cross-platform way to do this from vagrant itself, but if anyone has a
solution, that would make the decision easy). So you would work on,
http://localhost:8080/ (main vagrant wiki)
http://loginwiki.dev:8080/ (loginwiki)
etc.
Different subdirectories is how I currently do development and I personally
don't mind it, but it makes turning CentralAuth on and off more of a
challenge, since the current wiki is in the web root. So
http://localhost:8080/wiki/ (main vagrant wiki)
http://localhost:8080/loginwiki/ (loginwiki)
etc.
Preferences?
Chris
I'm very happy to announce that Filippo Giunchedi is joining us as an Operations Engineer in the Technical Operations team. Filippo is Italian, but he lives in Dublin where he interned at Google and worked at Amazon before coming to Wikimedia. He's gained a lot of experienced working with large scale distributed systems and infrastructure there.
Filippo will be working with us remotely. Today is his start day, but we were lucky to have him join us at our Ops off-site meeting in Athens a few weeks ago, where he helped improve our monitoring of system metrics with Graphite.
Fiddling with machines has always been his passion - it led to being fascinated by computers in the late 90s. He got involved in free software projects (e.g. Debian, as a Debian Developer) in the mid-2000s. System level technologies, infrastructure, distributed systems and networking are his main interests. On a different level, he's also interested in online privacy and secure/anonymous communications (e.g. Tor).
You can find Filippo on IRC (Freenode), using the nick name "godog".
Please join me in welcoming Filippo!
—
Mark Bergsma <mark(a)wikimedia.org>
Lead Operations Architect
Director of Technical Operations
Wikimedia Foundation
Hi,
I'm trying to resend this message that got lost.
Best
Physikerwelt
On Tue, Apr 15, 2014 at 1:13 PM, Moritz Schubotz <schubotz(a)tu-berlin.de> wrote:
> Dear all,
>
> I had some trouble to run the database tests that worked well locally on jenkins.
> In the onLoadExtensionSchemaUpdates hook I check for mysql/sqllite via
> $type = $updater->getDB()->getType();
> if ( $type == 'sqlite' ) {
> $type = 'mysql'; // The commands used from the updater are the same
> }
> if ( $type == 'mysql' ) {
>
> jenkins, that uses sqllite modifies
> -- Timestamp of the last update
> math_timestamp timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
> CURRENT_TIMESTAMP,
> to
> math_timestamp TEXT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
> which does not look like sqllite
> (http://stackoverflow.com/questions/6578439/on-update-current-timestamp-with…).
>
> I think the assumption that mysql and sqllite is wrong and also not a
> good style. Is there an example of an extension that runs database
> tests with jenkins?
>
> Is there any usage statistics on how frequent the database types are.
> Does it make sense to mainatain
>
> 1) mysql
> 2) sqllite
> 3) mssql
> 4) oracle
> 5) pg
>
> or are some of those databases seldomly used like db2 that was removed
> a while ago?
>
> Best
> Physikerwelt
Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_May_5th>
Of interest: May 7th - 12th is the Mediawiki Hackathon in Zürich. Hope
to see many of you there!
<https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014>
A quick list of notable items...
== Tuesday ==
* MediaWiki deploy
** group1 to 1.24wmf3: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf3>
== Thursday ==
* MediaWiki deploy
** group2 to 1.24wmf3 (all Wikipedias)
** group0 to 1.24wmf4 (test/test2/testwikidata/mediawiki)
* MediaViewer
** Will be enabled on Japanese, Portuguese, Spanish, Swedish, Telugu
Wikipedias
** <https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Timeline>
Thanks and as always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |