Jeroen De Dauw | 23 Jul 2012 20:23
Picon
Gravatar

Wikidata blockers

Hey,

After discussion with Robla and DanielK, we (the Wikidata team) decided to
write mails to this list now and then complain about our blockers for which
we need WMF (or other core dev) assistance :)

Right now we have three patches to core awaiting review:

* https://gerrit.wikimedia.org/r/#/c/14084/

Simple patch, which as far as I can tell is ready to go in. Development of
core parts of our phase one functionality is blocked by this, and not
having this merged is causing hassle for people that want to setup their
own working Wikidata repo-client install.

* https://gerrit.wikimedia.org/r/#/c/14295/

More complex patch, but has no effect on existing code in core yet, so can
be merged in without much risk. It's less urgent then the first patch,
although it just sitting there is causing overhead in regard to further
developing this code, and is preventing us from starting to work on
updating core code to make use of this rewrite.

* The Wikidata core branch with ContentHandler stuff

DanielK needs to chime in here, as I was unable to find anything sitting on
gerrit waiting for review. In any case, my understanding is that we still
need to get quite a bit merged in, doing this step by step, so obviously we
can only get to the next one when the current one got merged.

(Continue reading)

Lydia Pintscher | 23 Jul 2012 20:36
Picon
Favicon
Gravatar

Re: Wikidata blockers

On Mon, Jul 23, 2012 at 8:23 PM, Jeroen De Dauw <jeroendedauw <at> gmail.com> wrote:
> Hey,
>
> After discussion with Robla and DanielK, we (the Wikidata team) decided to
> write mails to this list now and then complain about our blockers for which
> we need WMF (or other core dev) assistance :)
>
> Right now we have three patches to core awaiting review:
>
> * https://gerrit.wikimedia.org/r/#/c/14084/
>
> Simple patch, which as far as I can tell is ready to go in. Development of
> core parts of our phase one functionality is blocked by this, and not
> having this merged is causing hassle for people that want to setup their
> own working Wikidata repo-client install.
>
> * https://gerrit.wikimedia.org/r/#/c/14295/
>
> More complex patch, but has no effect on existing code in core yet, so can
> be merged in without much risk. It's less urgent then the first patch,
> although it just sitting there is causing overhead in regard to further
> developing this code, and is preventing us from starting to work on
> updating core code to make use of this rewrite.
>
> * The Wikidata core branch with ContentHandler stuff
>
> DanielK needs to chime in here, as I was unable to find anything sitting on
> gerrit waiting for review. In any case, my understanding is that we still
> need to get quite a bit merged in, doing this step by step, so obviously we
> can only get to the next one when the current one got merged.
(Continue reading)

Lydia Pintscher | 23 Jul 2012 20:46
Picon
Favicon
Gravatar

Re: Wikidata blockers

On Mon, Jul 23, 2012 at 8:36 PM, Lydia Pintscher
<lydia.pintscher <at> wikimedia.de> wrote:
> I'd like to add one thing: It'd be awesome if Jens Ohlig could get
> enough gerrit karma to be able to push tags. This way he could create
> a tag whenever he updates the demo system and it'd be easy to see for
> people which patches are live on the current demo system and which are
> not yet.

Jeroen just told me that we can do this ourselves after all and gave
Jens the necessary rights. Please ignore.

Cheers
Lydia

--

-- 
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Wikidata

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.

_______________________________________________
(Continue reading)

Rob Lanphier | 23 Jul 2012 20:50
Picon
Gravatar

Re: Wikidata blockers

Hi Jeroen,

Thanks for this!  Per our conversation, I'd love for this to be
weekly, even if the status is "no change".  Even that is useful
information, since it may uncover cases where we're waiting for each
other thinking that the other party has the next step.

More below:

On Mon, Jul 23, 2012 at 11:23 AM, Jeroen De Dauw <jeroendedauw <at> gmail.com> wrote:
> Right now we have three patches to core awaiting review:
>
> * https://gerrit.wikimedia.org/r/#/c/14084/
>
> Simple patch, which as far as I can tell is ready to go in. Development of
> core parts of our phase one functionality is blocked by this, and not
> having this merged is causing hassle for people that want to setup their
> own working Wikidata repo-client install.

It looks a little more complicated to me, but I agree that the ball is
in our court to provide an alternate design idea.  Tim and/or Asher,
could you weigh in on this?

> * https://gerrit.wikimedia.org/r/#/c/14295/
>
> More complex patch, but has no effect on existing code in core yet, so can
> be merged in without much risk. It's less urgent then the first patch,
> although it just sitting there is causing overhead in regard to further
> developing this code, and is preventing us from starting to work on
> updating core code to make use of this rewrite.
(Continue reading)

Daniel Kinzler | 26 Jul 2012 15:53
Picon
Favicon
Gravatar

Wikidata code review

Hi all

as a follow up to Jeroens mail, I'd like to give a quick overview of things that
need to happen before we can roll out phase I of Wikidata on the first Wikipedia
(scheduled for "late summer"). As we are approaching feature completeness, it
becomes increasingly urgent to have a plan for getting the code deployed. Here's
a quick list of stuff we need:

* The most urgent bit is review of the Wikidata branch, which mainly means
introducing the ContentHandler facility into core, see below.

* The whole Wikibase code (3 extensions: repo, client and shared code in lib)
needs a review (the repo ist the least critical, since it will not be deployed
on Wikipedias). It's fairly large and could use a good looking over by anyone
who could spare a few minutes. If the code is unclear or confusing, also let us
know. I suggest to file any problem you find on bugzilla (in the misleadingly
named WikidataRepo or WikidataClient extensions) - got a better idea?

* Before actual deployment, we need to test in a more-like-production
environment. Ideally, we would use a Beta-Labs project for this. What's the
status of this, what's the procedure for testing a new extension there?

About the Wikidata branch:

On 23.07.2012 20:23, Jeroen De Dauw wrote:
> * The Wikidata core branch with ContentHandler stuff
> 
> DanielK needs to chime in here, as I was unable to find anything sitting on
> gerrit waiting for review. In any case, my understanding is that we still
> need to get quite a bit merged in, doing this step by step, so obviously we
(Continue reading)

Rob Lanphier | 29 Jul 2012 02:59
Picon
Gravatar

Re: Wikidata code review

Hi Daniel,

More inline:

On Thu, Jul 26, 2012 at 6:53 AM, Daniel Kinzler <daniel <at> brightbyte.de> wrote:
> as a follow up to Jeroens mail, I'd like to give a quick overview of things that
> need to happen before we can roll out phase I of Wikidata on the first Wikipedia
> (scheduled for "late summer"). As we are approaching feature completeness, it
> becomes increasingly urgent to have a plan for getting the code deployed. Here's
> a quick list of stuff we need:
>
> * The most urgent bit is review of the Wikidata branch, which mainly means
> introducing the ContentHandler facility into core, see below.

That's filed here:
https://bugzilla.wikimedia.org/38622

Assuming Tim doesn't weigh in before we speak, I'll talk to him next
week about this.

> * The whole Wikibase code (3 extensions: repo, client and shared code in lib)
> needs a review (the repo ist the least critical, since it will not be deployed
> on Wikipedias). It's fairly large and could use a good looking over by anyone
> who could spare a few minutes. If the code is unclear or confusing, also let us
> know.

A bug in Bugzilla per extension would be helpful (e.g. "Review the
Wikibase repo extension for deployment").  Each bug should have a very
brief explanation of what the role of that extension is and a link to
the repo.
(Continue reading)


Gmane