Hi everyone,
The signup deadline for the Architecture Summit is coming this Tuesday,
October 22, 17:00 UTC (10am PDT). Put your name here:
https://www.mediawiki.org/wiki/Architecture_Summit_2014
More details are at the page above, and the email below.
Rob
---------- Forwarded message ----------
From: Rob Lanphier <robla(a)wikimedia.org>
Date: Tue, Oct 8, 2013 at 4:25 PM
Subject: Sign up for the MediaWiki Architecture Summit (deadline October 22)
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Hi everyone,
Registration for the MediaWiki Architecture Summit is now open, and
will close Tuesday, October 22, 17:00 UTC (10am PDT). Here is the
essential event information:
January 23-24, 2014
SPUR - 654 Mission Street
San Francisco, CA, USA
Please put your name/information on the following wiki page to sign up:
https://www.mediawiki.org/wiki/Architecture_guidelines/Meetings/Architectur…
NOTE: even if you've previously RSVP'd (having received an early
invitation as we were picking dates), please sign up on the page
above. We're requesting information that will help shape the event.
The target audience of this event are mainly project maintainers and
other developers involved in Requests for Comment and, in general, the
future evolution of MediaWiki and related software components. All
participants must specify their current involvement in the MediaWiki
project, the RFC(s) that are promoting and the main future topics they
want to discuss. We are tentatively aiming to have around 50-60
people and we have some budget to sponsor travel for accepted
participants.
Rob
Dear Wikihackers,
User:Yug[1] from the Graphic Labs and I, User:Planemad[2] a cartographer
from the Indian community, have put together a comprehensive IEG proposal
to improve all the base maps used on WIkimedia projects with updated
cartographic conventions and accuracy using the latest tools and data.
The output will be a large set of editable vector maps, research
documentation and a comprehensive map generation workflow and
infrastructure that anyone can reuse.
The total grant request is for an amount of USD 10500, which will allow
both of us to work on this project full time for a period of 3 months. The
grant also includes a budget to hire external consultants where required to
accomplish the stated goals.
You can view the proposal and provide your valuable feedback/endorsement
here before Oct 22:
https://meta.wikimedia.org/wiki/Grants:IEG/Wikimaps_Atlas
PS: This will be the first step of the much larger Wikimaps[3] project that
aims to be the map engine that brings together Wikidata, Commons and
Openstreetmap.
[1] https://en.wikipedia.org/wiki/User:Yug
[2] https://en.wikipedia.org/wiki/User:Planemad
[3] https://meta.wikimedia.org/wiki/Wikimaps
--
Arun Ganesh
(planemad) <http://en.wikipedia.org/wiki/User:Planemad>
<http://j.mp/ArunGanesh>
In one week, we (Markus Glaser and I) plan to create a REL1_22 branch
for the 1.22.0 that we have scheduled for 6 weeks from now, no later
than November 29th.
In order to facilitate this, please make sure anything you want in 1.22
is ready this week. We'll probably do a couple merges from the WMF
branches in the process of making release candidates, but I'd like to
have any major changes in within the next week.
During the period leading up the release, please consider using the
"critical" severity level ensure any release critical bugs are logged
and tracked.
In addition, please look over
https://www.mediawiki.org/wiki/MediaWiki_1.22 and help update it since
it will be used in our release announcement.
Thanks,
Mark.
Hello and welcome to the lastest and greatest deploy highlights email,
this time for the week of October 21st.
== Highlights of the week ==
On Tuesday October 22nd, Echo (Notifications) will be doing it's final
major release. The wikis included are listed here:
<https://www.mediawiki.org/wiki/Echo/Release_Plan_2013#Final_Release>
== Rest of the schedule ==
=== Monday ===
* MediaWiki upgrade to non-Wikipedia project sites (eg: Commons,
Wikisources, Wiktionaries, etc)
** These site will get MediaWiki 1.22wmf22
** See:
<https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl…>
* The WMF Jenkins install will be upgraded to the latest released
version, 1.509.4. This should have no impact on any editor/reader
facing project or service.
* There will be an upgrade to the CirrusSearch backend, but only on a
network level and there should be no visible changes/impact on any
user facing project or service.
=== Tuesday ===
* The afore mentioned Echo deploy (see above).
=== Thursday ===
* MediaWiki upgrade to all language Wikipedias.
** These sites will get MediaWiki 1.22wmf22
* MediaWiki upgrade to all test wikis (including mediawiki.org)
** These sites will get the first wmf branch of the next MediaWiki
release, 1.23wmf1.
As always, let me know if you have any questions.
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hello,
Too long, dont want to read:
https://integration.wikimedia.org/cover/mediawiki-core/master/php/
Jenkins is nowadays producing a nightly coverage report. The idea is to
run our full PHPUnit tests, track which lines in MediaWiki core have
been executed and show up metrics regarding code not being executed.
That is made possible by using the XDebug php extensions and PHPUnit
code coverage feature.
In June I enforced a PHPUnit feature which force us to mention which
MediaWiki function is covered by a test method [FORCE COVER]. The option
is forceCoversAnnotation and is described in PHPUnit as:
forceCoversAnnotation
Code Coverage will only be recorded for tests that use the
@covers annotation documented in the section called “@covers”.
Jenkins build the coverage report every day at 1am UTC and it takes
roughly 40 minutes to generate. You can access the report by browsing:
https://integration.wikimedia.org
Then on the top menu "Coverage" and pick the MediaWiki core (PHP) link:
https://integration.wikimedia.org/cover/mediawiki-core/master/php/
A first step to enhance our coverage would be to add '@covers'
statements to our unit test methods. The tests for global functions are
good candidates: tests/phpunit/includes/GlobalFunctions
Now I am wondering where on mw.org I can document our coverage system.
Should we get a page under [[Continuous integration]] or maybe another
section in [[Manual:PHP unit testing]] ??
[FORCE COVER] https://gerrit.wikimedia.org/r/66125
[BUG 45594] https://bugzilla.wikimedia.org/45594
--
Antoine "hashar" Musso
Hello,
Yesterday I have updated the Jenkins jobs running PHPUnit to enable
$wgDebugLogFile and provide the result in the build result. That will
hopefully help people figuring what is wrong when a test is failing.
As an example, the VisualEditor extension as a qunit job. It uses
phantomjs (a headless browser) to run the Javascript QUnit tests against
a MediaWiki wiki installed locally. A run example is:
https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/5212/
On that page you will see links to files that have been archived:
Build Artifacts
LocalSettings.php 6.16 KB
mw-debug-cli.log.gz 340 B
mw-debug-www.log.gz 1.55 KB
The LocalSettings.php is the full configuration for that change. It is
crafted using the maintenance/installer.php and appending configuration
files hosted in integration/jenkins.git under /mediawiki/conf.d/ :
http://git.wikimedia.org/tree/integration%2Fjenkins.git/master/mediawiki%2F…
mw-debug-cli.log.gz is the $wgDebugLogFile whenever we have
$wgCommandLineMode
mw-debug-www.log.gz is the $wgDebugLogFile from the Apache hits.
That new feature is NOT enabled yet for mediawiki/core.
Happy testing!
--
Antoine "hashar" Musso
In one of the earlier discussions about revising the deletion schema,
Happy-Melon pointed out, "Right now everyone who has ideas for *an*
implementation isn't working on it because they don't know if it's *the*
implementation we want." It seems to me that if one proposal is clearly
superior, we may as well pick that one, so someone can get to work on it;
but if the proposals are about equally good, then we may as well pick one
at random, or whatever proposal is slightly better than the others, so
someone can get to work on that one.
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/48109
The RFC over at MediaWiki.org hasn't received a lot of comment. Is there
any objection to my implementing the "new field" option described at
https://www.mediawiki.org/wiki/Requests_for_comment/Page_deletion ?
I.e., I would add a new field, page.pg_deleted (analogous to
revision.rv_deleted). Also, I would add revision.rv_logid to store the
log_id of the deletion event. Upon restoring a page, only the revisions
pertaining to the selected deletion event(s) would be restored. So,
suppose you revision delete some revisions from a page for copyvio reasons.
Those revisions are now updated as rv_deleted=[whatever value we want to
use to signify the kind of access restrictions imposed by the deletion],
and revision.rv_log_id=1, assuming that is the first log action ever
performed on that wiki.
Later, you delete the whole page (update rv_log_id=2 for the remainder of
that page's revisions) for notability reasons. Then you decide you were
mistaken about notability, but the copyvios would still be a problem. You
undelete the page, selecting only that second deletion action. You only
restore the revisions that have rv_logid=2, and leave the rv_logid=1
revisions deleted. This will render the archive table obsolete, so it can
be deprecated/eliminated.
I would like to code this for v1.23.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55398 Thanks.
--
Nathan Larson
https://mediawiki.org/wiki/User:Leucosticte
Hello,
Please join us on the next Wikimedia Bugday:
20:00 Thursday, October 24, 2013 - Sunday, October 27 22:00 UTC[1]
in #pywikipediabot on Freenode IRC [2]
We will be triaging bug reports pywikibot [3]. Pywikibot recently
moved its code repository from SVN to Git and its bugtracker from
SourceForge to Wikimedia Bugzilla. Now many older tickets need
retesting and cleanup (around 700 bugs). We will be focusing on
retesting, and we will comment on bug reports that need status
updates, and have a good time working together on improving Pywikibot!
Everyone is welcome to join, and no technical knowledge needed! It's
an easy way to get involved in the community or to give something
back.
This even is part of a weekly QA activity [4], so we encourage you to
triage throughout the week and record your activity on the bug day
etherpad [5].
This information and more can be found here:
https://www.mediawiki.org/wiki/Bug_management/Triage/20131024
For more information on triaging in general, check out
https://www.mediawiki.org/wiki/Bug_management/Triage
I look forward to seeing you there.
Amir on behalf of Pywikibot developers
[1] Timezone converter: http://www.timeanddate.com/worldclock/converter.html
[2] See http://meta.wikimedia.org/wiki/IRC for more info on IRC chat
[3] https://www.mediawiki.org/wiki/Bug_management/Triage/20131024
[4] https://www.mediawiki.org/wiki/QA/Weekly_goals
[5] http://etherpad.wmflabs.org/pad/p/BugTriage