At the Hackathon in Amsterdam, we started a general discussion on architecture
guidelines for MediaWiki. RobLa is driving the process; at the moment, the wiki
page is mostly a summary of what we discussed, with some inline notes:
https://www.mediawiki.org/wiki/Architecture_guidelines
The goal is to agree on guidelines and have a finished document by Wikimania, at
the latest. I expect that the current brainstorming document will be turned into
a first draft over the next couple of weeks.
Please have a look and feel free to comment. However, I feel we should really
concentrate on general principles, and leave detailed discussions and best
practices for later / elsewhere.
-- daniel
PS: One result of the discussion was that we need to get the RDF process
unstuck. This is important so architectural questions get discussed and decided
in a timely manner.
Hey,
We now have Travis [0] hooked up to the Diff [1] repository that gets
automatically updated from the WMF hosted one [2]. This means that for
every commit, a build will be made and listed here [3].
The builds are currently done by running the tests on all of PHP 5.3, 5.4
and 5.5. This and other config can be specified in a .travis.yml in the
root dir of the component [4]. Travis supports SQLite, MySQL and PostGres,
so hopefully we'll be able to have the tests for Wikibase run on all of
these. The PHPUnit tests are run using the phpunit.xml.dist config file in
the root dir, so this is more reliable then the WMF jenkins setup at this
point, which is still using the MediaWiki hook manual test registration
stuff.
Currently this is only done for Diff, though we are working on also having
this work for our other components. The main problem there is getting the
relevant dependencies pulled and loaded, which could be done with some git
clones in the setup section of the Travis config file. It'd however be
better to not duplicate this info which is already in composer.json and
actually use Composer to do the task. I'm going to try to get that working
for Ask and then Wikibase. If that takes to long, I'll switch to using
simple git clones so this testing stuff is not blocked on getting our
components to work with Composer.
[0] https://travis-ci.org/
[1] https://www.mediawiki.org/wiki/Extension:Diff
[2] https://github.com/wikimedia/mediawiki-extensions-Diff/
[3] https://travis-ci.org/wikimedia/mediawiki-extensions-Diff/builds/
[4]
https://github.com/wikimedia/mediawiki-extensions-Diff/blob/master/.travis.…
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Hey,
in order to sanity check the code we have written in the Wikidata project,
we have asked an external company to review our code and discuss it with
the team. The effort was very instructional for us.
We want to share the results with you. The report looks dauntingly big, but
this is mostly due to the appendixes. The first 20 pages are quite worth a
read.
Since the Wikidata code is an extension to MediaWiki, a number of the
issues raised are also relevant to the MediaWiki code proper. I would hope
that this code review can be regarded as a contribution towards the
discussion of the status of our shared code-base as well.
I will unfortunately not be at the Hackathon, but a number of Wikidata
developers will, please feel free to chat them up. Daniel Kinzler is also
preparing a presentation to discuss a few lessons learned and ideas at the
Hackathon.
The review is available through this page: <
http://meta.wikimedia.org/wiki/Wikidata/Development/Code_Review>
Cheers,
Denny
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
We have put the easyRdf library into gerrit, so it is available for deploy
in production as a submodule in Wikibase.
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Wikibase/easyr…
When you pull latest master, you probably should update the submodule.
It might be necessary to delete the contents of the /contrib/easyRdf folder
and do git submodule init (update) and git submodule sync (to clean
references to the github remote)
Cheers,
Katie
--
Katie Filbert
Wikidata Developer
Wikimedia Germany e.V. | NEW: Obentrautstr. 72 | 10963 Berlin
Phone (030) 219 158 26-0
http://wikimedia.de
Wikimedia Germany - Society for the Promotion of free knowledge eV Entered
in the register of Amtsgericht Berlin-Charlottenburg under the number 23
855 as recognized as charitable by the Inland Revenue for corporations I
Berlin, tax number 27/681/51985.
Hey,
I sat down with Denny today and we had a look over the QueryEngine
component code. It however still needs a more formal review.
Current unreviewed code is sitting on the sqlstore feature branch.
Difference with master:
https://github.com/wikimedia/mediawiki-extensions-Wikibase/compare/master..…
This branch currently contains two commits [0, 1] that I made against
master for non QueryEngine improvements that where needed to get the tests
for the QueryEngine component to run on their own. So it'd be good to have
these reviewed first, then merge master into sqlstore, and no longer have
them in the diff there.
[0] https://gerrit.wikimedia.org/r/#/c/63218/
[1] https://gerrit.wikimedia.org/r/#/c/63219/
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Hey,
FYI, the PHPUnit tests for Wikibase are enabled again on WMF Jenkins and
switched to voting. So take care to not break tests. ;)
Thx to Jeroen & Hashar for their work.
cheers, tobi
--
Tobi Gritschacher
Software Developer - Wikidata - http://www.wikidata.org
Imagine a world, in which every single human being can freely
share in the sum of all knowledge. That‘s our commitment.
Wikimedia Deutschland e.V. | Obentrautstraße 72 | 10963 Berlin
Phone +49 (0)30 219 158 260
http://wikimedia.de <http://www.wikimedia.de/>
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hey,
I added a phpunit xml file to the Ask library [0] which enables you to run
the tests like
j@wd42:~/www/extensions/Ask$ phpunit
or
j@wd42:~$ phpunit --configuration www/extensions/Ask/phpunit.xml.dist
This will invoke the test bootsrtap code that loads the dependencies,
production classes and test classes. Improvements over our previous
situation:
* The tests are now run without MediaWiki - we thus know when a dependency
on MW sneaks in
* The tests are now run without MediaWiki - so they now take "0" seconds to
run rather than 5
* Since the config file specifies a directory, there no longer is the need
to register each test file somewhere.
This mail is about the later point.
Not having to register the test files is good. Less maintenance. Less
likely people forget to register their tests (this somehow did happen quite
a few times during the project so far).
I'll be adding similar test config and bootstrapping code to Diff and
DataValues soonish. Might be a bit more tricky for the different Wikibase
extensions and components.
We can however not quite get rid of the test registration code yet if we
want to continue running the tests via the MediaWiki test runner. This
runner currently, as far as I know, does not support registering those
config files or directories or whatever. So we might want to look into
making some improvements there to get rid of the registration code.
[0] https://gerrit.wikimedia.org/r/#/c/62589/
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Hey,
One of the interesting things that I learned today during a tutorial by
PHPUnit author Sebastian Bergmann is that there is a useful @covers tag.
http://phpunit.de/manual/3.7/en/appendixes.annotations.html#appendixes.anno…
He suggested we ought to use it for all our tests if we want our test
coverage reports to be accurate rather then having every line of code that
got executed marked as tested. So lets follow his advice and add this from
now on to new tests.
What might not be clear from the docs is that this can be done on the class
level.
This annotation is already used in MW core, so ought to not be stupidly
controversial :)
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--