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
+teampractices and wikitech-l for more input
On Wed, Oct 16, 2013 at 11:22 AM, Arthur Richards
<arichards(a)wikimedia.org>wrote:
> I generally agree with James'/VE's approach. I'm not sure we can
> reasonably come up with a sound metric (eg 'degredation that affects
> roughly one percent of users') as it may not always be easily measurable. I
> think a gut-check, qualitative assessment should suffice for these kinds of
> issues, and can probably be broken into a few buckets:
>
> *) critical functionality is BROKEN (eg edits are not being saved, article
> content is not accessible), there is a security concern, or a legal issue -
> this needs to be fixed ASAP, like possibly before the next lightning deploy
> *) semi-critical functionality is broken but doesn't impede basic usage of
> critical site components (imo: reading, editing [in that order]) - (eg the
> watchlist star on an article doesn't accurately indicate if an article is
> being watched) - fixed and backported with earliest possible lightning
> deploy window
> *) annoyances (styling not quite right, obscure javascript errors),
> non-security/legal issues in beta/alpha versions - fixed with next
> deployment train
>
> This has generally been our approach to date on the mobile web team,
> although I don't think we've ever been explicit about a rubric.
>
>
> On Tue, Oct 15, 2013 at 1:53 PM, James Forrester <jforrester(a)wikimedia.org
> > wrote:
>
>> Kenan,
>>
>> For VE we backport (cherry pick) fixes of major issues ASAP (generally by
>> grabbing the next available Lightning Deploy window after we've tested it),
>> but for inconveniences (i.e., things not quite as intended but still
>> workable, or only affecting a few users) we generally just go for the next
>> week's deployment train instead. Otherwise, yeah, they just join the
>> backlog.
>>
>> J.
>>
>>
>> On 15 October 2013 13:49, Kenan Wang <kwang(a)wikimedia.org> wrote:
>>
>>> Hey,
>>>
>>> The mobile team just got onto the deployment train. We're currently
>>> looking to understand what we do when we find bugs caused by the previous
>>> release during the deployment train. I proposed a three tiered triage
>>> system to my team:
>>>
>>> Current train: degradation that affects roughly one percent of users in
>>> a noticeable way
>>> Current iteration, next train: degradation that affects less than one
>>> percent of users in a noticeable way
>>> Backlog: degradation that affects less than .1 percent of users in a
>>> noticeable way, or affects users in a cursory way
>>>
>>> But was wondering if there were any other systems that teams had in
>>> place to deal with this issue.
>>>
>>> Also, if you fix a bug does your team typically deploy during the next
>>> deployment window available or do you wait to deploy until you have a
>>> couple of fixes?
>>>
>>> --
>>>
>>> Kenan Wang
>>> Product Manager, Mobile
>>> Wikimedia Foundation
>>>
>>> _______________________________________________
>>> Wmfproduct mailing list
>>> Wmfproduct(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wmfproduct
>>>
>>>
>>
>>
>> --
>> James D. Forrester
>> Product Manager, VisualEditor
>> Wikimedia Foundation, Inc.
>>
>> jforrester(a)wikimedia.org | @jdforrester
>>
>
>
>
> --
> Arthur Richards
> Software Engineer, Mobile
> [[User:Awjrichards]]
> IRC: awjr
> +1-415-839-6885 x6687
>
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687