Hi all,
as we just decided, because it is too hot, we will skip deployment cycle
wmf-8 too.
We will have a code freeze on Tuesday, 25th, at 4pm, to orderly prepare for
the following deployment (i.e. wmf-9).
For the future, we are currently discussing internally how to make this a
bit smoother.
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.
Hey,
Since we now have a few more components, here are some new handy shortlinks:
* Review queue: http://bit.ly/wdrieview
* Merged stuff: http://bit.ly/wdmrgd
Included new repos are: WikibaseDataModel, WikibaseDatabase, WikibaseQuery,
WikibaseQueryEngine
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
Hi all.
Currently, a PropertyValueSnak knows the ID of the property it refers to, and
the DataValue object representing the actual value. The DataValue has a "low
level type" used (in the future) by the storage and indexing layer. But whenever
we want to render or validate a snak, we need the property's high level data type.
Currently, we do this via the PropertyDataTypeLookup service.
I think that's quite inconvenient and inefficient. I think the Snak itself
should know the data type's ID. Was there any particular reason not to do this?
I remember a lengthy discussion about this, but I don't recall the outcome (yes,
we really need to write this stuff down).
Having the data type in the Snak would mean that Snaks are self-contained in the
JSON structure, and it would also make us robust against a property changing
it's type.
Of course, changing this now means we have to provide some kind of fallback for
the case that the type id is missing - and that is going to require a
PropertyDataTypeLookup again. Annoying :/
Alternatively, Snak objects could require the type in the constructor - but that
would require database lookups during deserialization; not fun.
Any thoughts on this? Why did we go this route? And is it really too late to
change this now?
-- daniel
Hey,
The PHPUnit tests for Wikibase Repo and Wikibase Client are now run on
TravisCI! There where the last two of our components on the TODO list, so
we now have all our PHPUnit tests running there.
Right now Travis is running 6 jobs for every commit: half repo, half
client. half mysql, half sqlite. And 2 for each of PHP 5.3, 5.4 and 5.5.
https://travis-ci.org/wikimedia/mediawiki-extensions-Wikibase/builds/8155338
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
A quick heads up:
We have a breaking change for the API in the pipeline:
<https://gerrit.wikimedia.org/r/#/c/68406/12>. This has not been merged yet, but
I expect this to go into the next branch (to be deployed on June 24, if I'm not
mistaking).
It's really a fix for previously underspecified and dangerous behavior:
the editentity module would automatically create a new item when called without
giving an ID of the entity to modify.
With the patch, editentity now requires that either the 'id' parameter or the
'new' parameter be set, explicitly stating which entity to modify resp. what
kind of entity to create.
That is, bots that wish to create an item now need to provide the new=item
parameter, instead of just not supplying an id parameter. This affects all bots
that create items.
We could keep the old behavior as a B/C mode, but it's dangerous and ill
defined; I think it's better to break some bots now, it's easy to fix anyway.
But it should of course be announced in due time.
-- daniel
I' currently thinking about how to best validate incoming Snaks / DataValues.
I have been looking at the ValueValidator interface, and it seems to be somewhat
inconvenient.
* why do we need the setOptions() method? Shouldn't the validator be fully
configured in the constructor?
* why is there no canValidate() method? This would be very handy for finding
applicable validators for a given object.
This seems a bit odd, but where it gets really problematic is the
ValueValidatorsObject base class:
* why are errors collected in a member? I would expect a validator to be
stateless and reusable.
* why do we need the Result object? Can't we just throw an exception? The "value
with warnings" use case for MediaWiki's status object doesn't seem to apply here.
* There is a lot of "convenient stuff" implemented in the base class which i
expect many implementations are not going to need, e.g. the
allowdValues/forbiddenValues stuff.
* options are passed to sub-validators using an option map, changing the
configuration and thus behavior of the (sub-)validators on the fly. That seems
like asking for trouble.
I propose a lighter design:
* the ValueValidator interface has two methods, validate() and canValidate().
validate() can throw a validation exception, which contains one or more errors.
* Validators are stateless and get configured completely and finally by the
constructor.
* Validators should generally implement only a single constraint - so instead of
a String validator that implements min/max length, min/max value, and a regex
check, each of these checks should have their own validator; A
CompositeValidator could be used to bundle multiple validations, if needed.
* ValueValidatorFactory gets a getApplicableValidators() method that returns all
validators that can be used to validate a given object.
As far as I can see, the Validator interface isn't yet widely used, so it would
be easy enough to change these things.
What do you think?
-- daniel
Hey :)
Here's the list of issues as I promised:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=49415 - Henning has a
patch for it that needs backporting
* https://gerrit.wikimedia.org/r/67862 - supposedly live already
* https://bugzilla.wikimedia.org/show_bug.cgi?id=49417 - Katie has a
hotfix - not sure about the status
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Technical Projects
Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
WMF is switching over to the one-week deployment schedule, starting
tomorrow!
https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl…
For this time, I'm recommending we keep test2 on the wmf5 branch of
Wikibase etc.
We will need to run all tests tomorrow to make sure there is (unlikely) no
compatibility issue with our branch and wmf6 core.
Then we deploy our wmf6 branch of Wikibase etc. on Monday to wikidata and
test2. Next Thursday, the clients all get wmf6 branch of Wikibase.
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.
Hi,
trying to edit anything on Wikidata, I get the following error message:
"""
An error occurred while trying to perform save and because of this, your
changes could not be completed.
"""
There seem to be Recent Changes by others going on though. Any ideas?
Cheers,
Markus