There are build errors in the mediawiki builds on travis-ci, which
have been happening for four months.
https://travis-ci.org/wikimedia/mediawiki-core/builds
Is anyone using that to help with development. I doubt it, given they
are broken.
Could they be disabled, as those jobs are causing other travis-ci jobs
under 'wikimedia' to be delayed. e.g. the pywikibot-core builds,
where the developer team actively uses the travis builds.
https://travis-ci.org/wikimedia/pywikibot-core/builds
--
John Vandenberg
On Tuesday, August 19, 2014, Jon Robson <jdlrobson(a)gmail.com> wrote:
>
> I was curious to how generic the rating system is. For example would
> it be possible to use such a thing on something like BetaFeatures or
> was it specifically designed for extension rating?
>
I'm not sure how related is this, but Article Feedback allowed user rating
+ comment, and it was deployed in Wikimedia servers. Editors didn't find it
that useful for regular articles (too much extra work processing too little
value feedback on top of Talk pages), but maybe this could (with small or
not so small adaptation, I don't know) in the very specific context of a
beta feature page.
For instance, imagine a page created specifically for a deployment of a
specific version of a specific beta feature e.g. Winter 0.x. There you
would expect ratings plus optional short feedback without requiring to the
user any background nor any commitment to engage in a discussion. The
deeper discussion would flow (pun intended) across releases at the beta
feature talk page e.g. https://www.mediawiki.org/wiki/Talk:Winter
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
On 20 August 2014 13:02, Antoine Musso <hashar+wmf(a)free.fr> wrote:
> Hello,
>
> The tests results being reported to Gerrit are now much nicer. The
> first ever example is https://gerrit.wikimedia.org/r/#/c/155341/
>
>
> James E. Blair from Openstack found a nice trick to inject HTML in
> Gerrit comment. Christian Aistleitner kindly reviewed and tested the
> regex, and further improved the craziness.
>
> Daniel Zahn deployed the change on spot a few minutes ago and we now
> have slightly nicer and more readable test results being reported.
>
> \O/
>
> Ref:
> https://bugzilla.wikimedia.org/66095
Lovely! Thanks all.
J.
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Hi Wil,
Yes, this newsletter will be similar to those on the page you linked.
The relevance of an article about check fraud is that Wikimedia thematic
organizations should be aware of financial security issues that could
impact them, and check fraud is one of those issues.
Yes, a how-to article about setting up a secure MW installation would be in
scope for the security newsletter.
Pine
On Aug 19, 2014 3:19 AM, "Wil Sinclair" <wllm(a)wllm.com> wrote:
> Hi Pine, I'd love to contribute. I'll mail you offlist about that, but
> I have a few general questions that others may be wondering about.
>
> Would this be similar to one of these newsletters?
> https://meta.wikimedia.org/wiki/Newsletters#List_of_newsletters
>
> If so, from your list of topics it sounds like this one might be a bit
> different than the other newsletters in that material relatively
> unrelated to WM/WP is fair game. Maybe I'm just a small-minded techie,
> but you lost me at check fraud.
>
> I'm assuming a how-to on how to set up a MediaWiki installation
> without getting completely pwned by spammers and mals. Hint: don't let
> untrusted users move and delete pages. :) Also, I'm working on
> security integrations between MW and some other popular open source
> projects. If anyone has anything to say about this stuff, please mail
> me offlist or maybe we can take it to a more specific list.
>
> Anyways, best of luck with wherever you guys/gals take this.
>
> ,Wil
>
> > In collaboration with Chris Steipp, I am considering starting a monthly
> > security newsletter for Wikimedia, focused on common risks and mitigation
> > techniques. The target audience is the broad Wikimedia community
> including
> > developers, WMF and chapter employees, and volunteers with high risk
> > accounts.
> >
> > Example topics:
> > Phishing
> > Coding best practices
> > Wifi security
> > Securing data stored on cell phones
> > Check fraud
> > Preventing insider theft of funds in Wikimedia organizations
> >
> > If you are interested in contributing to the newsletter please email me
> off
> > list.
> >
> > Thanks,
> >
> > Pine
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
In addition to what I said below (this was originally sent to design),
anonymous editing is now enabled. So feel free to test anonymously or
with as many accounts (throw-away accounts are fine on this test wiki)
as you'd like.
Matt Flaschen
-------- Original Message --------
Subject: mwui.wmflabs.org reactivated, showing upcoming MW UI styles
($wgUseMediaWikiUIEverywhere = true;)
Date: Mon, 18 Aug 2014 20:16:24 -0400
From: Matthew Flaschen <mflaschen(a)wikimedia.org>
To: Design list <design(a)lists.wikimedia.org>
I've updated the MW UI demo site
(http://mwui.wmflabs.org/wiki/Main_Page) and enabled
$wgUseMediaWikiUIEverywhere = true; (the global used by Jon's blanket MW
UI change).
Basically, we want to test this version for a while, then make it the
only version. So please click around on
http://mwui.wmflabs.org/wiki/Main_Page (e.g. try editing
http://mwui.wmflabs.org/wiki/Lorem_ipsum, among many other possibilities).
Thanks,
Matt Flaschen
Hello,
Here's a quick status update about the rollout of HHVM.
* Since migrating test.wikipedia.org to HHVM exactly one week ago, we've
had just one segfault (reported upstream: <
https://github.com/facebook/hhvm/issues/3438>). That's very good.
* Giuseppe shared some benchmarks in an e-mail to wikitech: <
https://lists.wikimedia.org/pipermail/wikitech-l/2014-August/078034.html>.
Also very good.
* Re-imaging an app server was surprisingly painful, in that Giuseppe and I
had to perform a number of manual actions to get the server up-and-running.
This sequence of steps was poorly automated: update server's salt key ->
synchronize Trebuchet deployment targets -> fetch scap scripts -> run
sync-common to fetch MediaWiki -> rebuild l10n cache. Doing this much
manual work per app server isn't viable. Giuseppe and I fixed some of this
but there's more work to be done.
* Mark submitted a series of patches (principally <
https://gerrit.wikimedia.org/r/#/c/152903/>) to create a service IP and
Varnish backend for an HHVM app server pool, with Giuseppe and Brandon
providing feedback and amending the change. Brandon thinks it looks good
and he may be able to deploy it some time next week.
* The patch routes requests that are tagged with a specific cookie to the
HHVM backends. Initially, we'll ask you (Wikimedia engineers and
technically savvy / adventurous editors) to opt-in to help with testing by
setting the cookie explicitly. The next step after that will be to divert a
fraction of general site traffic to those backends. When exactly that
happens will depend on how many bugs the next round of testing will uncover.
* We'll be adding servers to HHVM pool as we reimage them.
* Tim is looking at modifying the profiling feature of LuaSandbox to work
with HHVM. We currently disable it, due to <
https://bugzilla.wikimedia.org/show_bug.cgi?id=68413>. (Feedback from users
re: how important is this feature to you would be useful).
* Giuseppe and Filippo noticed a memory leak on the HHVM job runner
(mw1053). Aaron is trying to isolate it. Tracked in bug <
https://bugzilla.wikimedia.org/show_bug.cgi?id=69428>.
* Giuseppe is on vacation for the week of 8/18 - 8/22; Filippo is the
point-person for HHVM in TechOps.
Lets all welcome the new overlord Erik.
Add a new protection level called "superprotect"
Assigned to nobody by default. Requested by Erik Möller for the purposes
of protecting pages such that sysop permissions are not sufficient to
edit them.
Change-Id: Idfa211257dbacc7623d42393257de1525ff01e9e
<https://gerrit.wikimedia.org/r/#q,Idfa211257dbacc7623d42393257de1525ff01e9e…>
https://gerrit.wikimedia.org/r/#/c/153302/
Someone clearly can't take criticism of their projects well.