[Wikidata-bugs] [Maniphest] [Commented On] T113034: RFC: Overhaul Interwiki map, unify with Sites and WikiMap

[Legoktm]

Legoktm added a comment.


  https://gerrit.wikimedia.org/r/#/c/250150/ is probably the first step in 
implementing this, and I was planning to merge it by the end of this week.

TASK DETAIL
  https://phabricator.wikimedia.org/T113034

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, Legoktm
Cc: RobLa-WMF, gerritbot, Quiddity, Bene, hoo, zhuyifei1999, jayvdb, Spage, 
Isarra, Smalyshev, Ltrlg, GWicke, Purodha, Ricordisamoa, MZMcBride, Krenair, 
MrStradivarius, Legoktm, TTO, Anomie, ori, aaron, Aklapper, daniel, Lewizho99, 
Maathavan, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, fbstj, Mbch331, 
Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[brion]

brion added a comment.


  In https://phabricator.wikimedia.org/T107595#2266131, @GWicke wrote:
  
  > The use case for providing metadata is so that we can use stores like 
RESTBase, which already provide an API keyed on title, revision & render ID. It 
also already deals with the complexities you mention.
  >
  > Basically, if we don't have a way to provide this key information to the 
backend store, then we can't access all the multi-content revision data that's 
already out there through this interface.
  
  
  As I understand it, restbase is a front-end caching proxy store, exposed to 
the public internet. Meanwhile the blob store is the equivalent of MediaWiki's 
existing text table and external storage backing system, entirely internal and 
containing data that is sometimes private (eg deleted or revdel'd page content).
  
  A front-end restbase could proxy access to MediaWiki revisions, backed by 
MediaWiki and the blob store. This would mean that slot data, metadata, titles, 
revision ids etc are all preserved and exposed because you'd be hooking up to 
the level of MediaWiki that has that information.
  
  Is that what you mean, or do you have something else in mind?

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, brion
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Unassigned] T133470: [Task] Remove outdated message "Wikibase-after-page-move"

[D3r1ck01]

D3r1ck01 removed D3r1ck01 as the assignee of this task.

TASK DETAIL
  https://phabricator.wikimedia.org/T133470

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: D3r1ck01
Cc: D3r1ck01, thiemowmde, Ricordisamoa, Lydia_Pintscher, gerritbot, TerraCodes, 
He7d3r, GoEThe, Aklapper, Lewizho99, Maathavan, Izno, Wikidata-bugs, aude, 
TheDJ, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134432: Missing labels and descriptions in "other languages" box

[aude]

aude added a comment.


  Now fixed on Wikidata, though still want us to split the code that generates 
the TermListView into a separate class so it can be tested more properly or 
otherwise make sure it's well tested

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: Stashbot, Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, 
Zppix, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T134432: Missing labels and descriptions in "other languages" box

[aude]

aude removed a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: Stashbot, Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, 
Zppix, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Lowered Priority] T134432: Missing labels and descriptions in "other languages" box

[aude]

aude lowered the priority of this task from "Unbreak Now!" to "High".

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: Stashbot, Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, 
Zppix, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134432: Missing labels and descriptions in "other languages" box

[Stashbot]

Stashbot added a comment.


  Mentioned in SAL [2016-05-04T23:54:31Z]  Synchronized 
php-1.27.0-wmf.23/extensions/Wikidata: Fix bug in other languages box: 
https://phabricator.wikimedia.org/T134432 (duration: 02m 18s)

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Stashbot
Cc: Stashbot, Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, 
Zppix, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  In https://phabricator.wikimedia.org/T107595#2266131, @GWicke wrote:
  
  > Basically, if we don't have a way to provide this key information to the 
backend store, then we can't access all the multi-content revision data that's 
already out there through this interface.
  
  
  I agree we should find an appropriate abstraction that allows us to use the 
information that is already available via RESTbase. It seems to me that this 
would be an abstraction layer on the level on slots, between RevisionBuilder 
and BlobStore. it seems pretty clear to me that the BlobStore interface doesn't 
fit: it represents something more low level than what RESTbase is currently 
used for.
  
  We should keep this in mind, but perhaps we can postpone the details until we 
implement derived (dynamic) slots. We will want those to be purely 
programmatic, and not to be forced to rely on slot entries in the database. The 
`RevisionContentLookup` interface from the original proposal would be the 
reading side of this.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[GWicke]

GWicke added a comment.


  The use case for providing metadata is so that we can use stores like 
RESTBase, which already provide an API keyed on title, revision & render ID. It 
also already deals with the complexities you mention.
  
  Basically, if we don't have a way to provide this key information to the 
backend store, then we can't access all the multi-content revision data that's 
already out there through this interface.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, GWicke
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134426: Review shared data namespace (tabular data) implementation

[Yurik]

Yurik added a comment.


  My apologies to anyone who is not interested in the implementation review of 
this feature - please unsubscribe. I am hoping to deploy this fairly soon, as 
there is clearly a huge demand for this functionality, so any feedback would be 
great. Thanks!

TASK DETAIL
  https://phabricator.wikimedia.org/T134426

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Yurik
Cc: DannyH, StudiesWorld, Steinsplitter, Aklapper, Lydia_Pintscher, ekkis, 
Matanya, MarkTraceur, JEumerus, Thryduulf, Milimetric, MZMcBride, Bawolff, 
-jem-, gerritbot, Pokefan95, TerraCodes, intracer, ThurnerRupert, brion, 
Jdforrester-WMF, Eloy, TheDJ, Yurik, Zppix, Riley_Huntley, D3r1ck01, Izno, 
Luke081515, JAllemandou, Wikidata-bugs, aude, El_Grafo, Ricordisamoa, Shizhao, 
fbstj, Fabrice_Florin, Mbch331, Jay8g, Krenair, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134432: Missing labels and descriptions in "other languages" box

[gerritbot]

gerritbot added a comment.


  Change 287013 merged by jenkins-bot:
  Fix issue of missing languages in "other languages" term box
  
  https://gerrit.wikimedia.org/r/287013

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Stashbot, Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, 
Zppix, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T113034: RFC: Overhaul Interwiki map, unify with Sites and WikiMap

[RobLa-WMF]

RobLa-WMF added a comment.


  @Daniel nominated this RFC for discussion at next week's ArchCom-RFC meeting 
(https://phabricator.wikimedia.org/E171), which seemed like a good idea to 
everyone at the time.  The last RFC meeting we had on this subject was October, 
and there's now patch 285018  awaiting 
review in Gerrit.

TASK DETAIL
  https://phabricator.wikimedia.org/T113034

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, RobLa-WMF
Cc: RobLa-WMF, gerritbot, Quiddity, Bene, hoo, zhuyifei1999, jayvdb, Spage, 
Isarra, Smalyshev, Ltrlg, GWicke, Purodha, Ricordisamoa, MZMcBride, Krenair, 
MrStradivarius, Legoktm, TTO, Anomie, ori, aaron, Aklapper, daniel, Lewizho99, 
Maathavan, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, fbstj, Mbch331, 
Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134432: Missing labels and descriptions in "other languages" box

[gerritbot]

gerritbot added a comment.


  Change 287013 had a related patch set uploaded (by Aude):
  Fix issue of missing languages in "other languages" term box
  
  https://gerrit.wikimedia.org/r/287013

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Stashbot, Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, 
Zppix, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134432: Missing labels and descriptions in "other languages" box

[gerritbot]

gerritbot added a comment.


  Change 287005 merged by jenkins-bot:
  Fix issue of missing languages in "other languages" term box
  
  https://gerrit.wikimedia.org/r/287005

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Stashbot, Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, 
Zppix, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[brion]

brion added a comment.


  If I understand, the case for passing more metadata to the blob store is as a 
hint for cross-blob data compression.
  
  For this I think we mainly want to pass the identifier of a related blob: the 
blob with the data from the same slot in the previous revision. If the related 
blob is in the same store, then the blob store can potentially optimize its 
actual backing storage (with diff-based storage, or by gzipping adjacent blob 
contents together with a window size larger than the blobs, etc).
  
  It might also be useful to specify a type for 'hey this is precompressed 
binary data, don't bother trying to recompress it or diff it'.
  
  But I would strongly recommend against being too clever. Revision metadata 
may change (yes, change -- revdel etc) and blobs are explicitly reused across 
multiple revisions. Revision histories can be rewritten (yes, rewritten -- 
import/export and delete/undelete can change ordering & adjacency, etc). And 
definitely don't include things like titles that are completely arbitrary and 
may change at any time.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, brion
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T133660: [Story] Improve editing of textual representation - add and delete

[gerritbot]

gerritbot added a comment.


  Change 286885 merged by jenkins-bot:
  Deleting of triples in textual representation
  
  https://gerrit.wikimedia.org/r/286885

TASK DETAIL
  https://phabricator.wikimedia.org/T133660

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Aklapper, Jonas, Avner, Lewizho99, Maathavan, debt, Gehel, 
D3r1ck01, FloNight, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, 
Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T119915: Create response time monitoring for WDQS endpoint

[Smalyshev]

Smalyshev moved this task from In progress to Done on the 
Discovery-Wikidata-Query-Service-Sprint board.

TASK DETAIL
  https://phabricator.wikimedia.org/T119915

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1239/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Gehel, Smalyshev
Cc: gerritbot, Gehel, Ricordisamoa, hoo, Addshore, Aklapper, Smalyshev, Avner, 
Lewizho99, Maathavan, debt, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, 
Jdouglas, aude, Deskana, Manybubbles, Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Closed] T119915: Create response time monitoring for WDQS endpoint

[Smalyshev]

Smalyshev closed this task as "Resolved".

TASK DETAIL
  https://phabricator.wikimedia.org/T119915

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Gehel, Smalyshev
Cc: gerritbot, Gehel, Ricordisamoa, hoo, Addshore, Aklapper, Smalyshev, Avner, 
Lewizho99, Maathavan, debt, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, 
Jdouglas, aude, Deskana, Manybubbles, Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134432: Missing labels and descriptions in "other languages" box

[gerritbot]

gerritbot added a comment.


  Change 287005 had a related patch set uploaded (by Aude):
  Fix issue of missing languages in "other languages" term box
  
  https://gerrit.wikimedia.org/r/287005

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Stashbot, Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, 
Zppix, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T119915: Create response time monitoring for WDQS endpoint

[Gehel]

Gehel moved this task from Backlog to In progress on the 
Discovery-Wikidata-Query-Service-Sprint board.

TASK DETAIL
  https://phabricator.wikimedia.org/T119915

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1239/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Gehel
Cc: gerritbot, Gehel, Ricordisamoa, hoo, Addshore, Aklapper, Smalyshev, Avner, 
Lewizho99, Maathavan, debt, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, 
Jdouglas, aude, Deskana, Manybubbles, Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Claimed] T119915: Create response time monitoring for WDQS endpoint

[Gehel]

Gehel claimed this task.
Gehel added a project: Discovery-Wikidata-Query-Service-Sprint.
Gehel set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T119915

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Gehel
Cc: gerritbot, Gehel, Ricordisamoa, hoo, Addshore, Aklapper, Smalyshev, Avner, 
Lewizho99, Maathavan, debt, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, 
Jdouglas, aude, Deskana, Manybubbles, Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T119915: Create response time monitoring for WDQS endpoint

[gerritbot]

gerritbot added a comment.


  Change 286992 merged by Gehel:
  Add response time checks to WDQS
  
  https://gerrit.wikimedia.org/r/286992

TASK DETAIL
  https://phabricator.wikimedia.org/T119915

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Gehel, Ricordisamoa, hoo, Addshore, Aklapper, Smalyshev, Avner, 
Lewizho99, Maathavan, debt, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, 
Jdouglas, aude, Deskana, Manybubbles, Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T119915: Create response time monitoring for WDQS endpoint

[gerritbot]

gerritbot added a comment.


  Change 286992 had a related patch set uploaded (by Gehel):
  Add response time checks to WDQS
  
  https://gerrit.wikimedia.org/r/286992

TASK DETAIL
  https://phabricator.wikimedia.org/T119915

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Gehel, Ricordisamoa, hoo, Addshore, Aklapper, Smalyshev, Avner, 
debt, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, 
Manybubbles, Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T119915: Create response time monitoring for WDQS endpoint

[gerritbot]

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T119915

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Gehel, Ricordisamoa, hoo, Addshore, Aklapper, Smalyshev, Avner, 
Lewizho99, Maathavan, debt, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, 
Jdouglas, aude, Deskana, Manybubbles, Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T134432: Missing labels and descriptions in "other languages" box

[Stashbot]

Stashbot added a comment.


  Mentioned in SAL [2016-05-04T20:28:25Z]  rebuilt wikiversions.php 
and synchronized wikiversions files: Wikidata back to 1.27.0-wmf.22 due to 
https://phabricator.wikimedia.org/T134432. Poke 
https://phabricator.wikimedia.org/T131557.

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Stashbot
Cc: Stashbot, Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, 
Zppix, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134432: Missing labels and descriptions in "other languages" box

[gerritbot]

gerritbot added a comment.


  Change 286961 merged by jenkins-bot:
  Put wikidata back on wmf/1.27.0-wmf.22
  
  https://gerrit.wikimedia.org/r/286961

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, Zppix, 
Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T134432: Missing labels and descriptions in "other languages" box

[hashar]

hashar added a blocked task: T131557: MW-1.27.0-wmf.23 deployment blockers.

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hashar
Cc: Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, Zppix, 
Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T134432: Missing labels and descriptions in "other languages" box

[aude]

aude triaged this task as "Unbreak Now!" priority.
Herald added subscribers: Luke081515, TerraCodes, Urbanecm.

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: Urbanecm, TerraCodes, Luke081515, gerritbot, Aklapper, aude, Zppix, 
Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T134432: Missing labels and descriptions in "other languages" box

[gerritbot]

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Aklapper, aude, Zppix, Lewizho99, Maathavan, D3r1ck01, Izno, 
Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134432: Missing labels and descriptions in "other languages" box

[gerritbot]

gerritbot added a comment.


  Change 286961 had a related patch set uploaded (by Aude):
  Put wikidata back on wmf/1.27.0-wmf.22
  
  https://gerrit.wikimedia.org/r/286961

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Aklapper, aude, Zppix, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T134432: Missing labels and descriptions in "other languages" box

[aude]

aude created this task.
Herald added subscribers: Zppix, Aklapper.

TASK DESCRIPTION
  Some items that have labels (and descriptions), such as in the user language 
or other languages, don't have these displayed in the "other languages" box on 
the page:
  
  F3967193: wikidata-nolabels.png 
  
  we purged the parser cache (and I also tried purging manually and editing 
some of these items).  None of this helps.  Clicking random or nearby items, 
some are affected by this bug and others not.
  
  Now that I look at my local wiki, this is easily reproducable and thus 
hopefully an easy fix.

TASK DETAIL
  https://phabricator.wikimedia.org/T134432

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: Aklapper, aude, Zppix, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134426: Review shared data namespace (tabular data) implementation

[matmarex]

matmarex added a comment.


  Surely this doesn't need all these tags and all these people. Please pay 
attention when creating subtasks :(

TASK DETAIL
  https://phabricator.wikimedia.org/T134426

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Yurik, matmarex
Cc: DannyH, StudiesWorld, Steinsplitter, Aklapper, Lydia_Pintscher, matmarex, 
ekkis, Matanya, MarkTraceur, JEumerus, Thryduulf, Milimetric, MZMcBride, 
Bawolff, -jem-, gerritbot, Pokefan95, TerraCodes, intracer, ThurnerRupert, 
brion, Jdforrester-WMF, Eloy, TheDJ, Yurik, Zppix, Riley_Huntley, D3r1ck01, 
Izno, Luke081515, JAllemandou, Wikidata-bugs, aude, El_Grafo, Ricordisamoa, 
Shizhao, fbstj, Fabrice_Florin, Mbch331, Jay8g, Krenair, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T134426: Review shared data namespace (tabular data) implementation

[Yurik]

Yurik created this task.
Herald added a subscriber: Zppix.

TASK DESCRIPTION
  Please review implementation details of the cross-wiki sharable data 
namespace implementation for tabular data:
  
  - usage and technical description 

  - demo 
  - community discussion 


TASK DETAIL
  https://phabricator.wikimedia.org/T134426

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Yurik
Cc: DannyH, StudiesWorld, Steinsplitter, Aklapper, Lydia_Pintscher, matmarex, 
ekkis, Matanya, MarkTraceur, JEumerus, Thryduulf, Milimetric, MZMcBride, 
Bawolff, -jem-, gerritbot, Pokefan95, TerraCodes, intracer, ThurnerRupert, 
brion, Jdforrester-WMF, Eloy, TheDJ, Yurik, Zppix, Riley_Huntley, D3r1ck01, 
Izno, Luke081515, JAllemandou, Wikidata-bugs, aude, El_Grafo, Ricordisamoa, 
Shizhao, fbstj, Fabrice_Florin, Mbch331, Jay8g, Krenair, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Block] T120452: Allow tabular datasets on Commons (or some similar central repository) (CSV, TSV, JSON, XML)

[Yurik]

Yurik created blocking task T134426: Review shared data namespace (tabular 
data) implementation.

TASK DETAIL
  https://phabricator.wikimedia.org/T120452

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Yurik
Cc: TheDJ, Eloy, Jdforrester-WMF, brion, ThurnerRupert, intracer, TerraCodes, 
Pokefan95, gerritbot, -jem-, Bawolff, MZMcBride, Milimetric, Thryduulf, 
JEumerus, MarkTraceur, Yurik, Matanya, ekkis, matmarex, Lydia_Pintscher, 
Aklapper, Steinsplitter, StudiesWorld, DannyH, Riley_Huntley, D3r1ck01, Izno, 
JAllemandou, Wikidata-bugs, aude, El_Grafo, Ricordisamoa, Shizhao, 
Fabrice_Florin, Mbch331, Jay8g, Krenair, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  In https://phabricator.wikimedia.org/T107595#2265186, @GWicke wrote:
  
  > >> In addition to title and revision (which I assume remains an integer), 
we'd need an optional v1 UUID parameter to retrieve specific renders, in both 
the request & response interfaces.
  >
  >
  >
  > > I have thought about this, too. My solution is to encode this in the slot 
name. So you could have an html.canonical (sub)slot, and a 
html.29e68f78-8765-49f8-86d5-dfc438d459fe, or html.en, or whatever.
  >
  > Hmmm, this sounds like a rather ugly hack. I thought the 'slot' is 
identifying the kind of content, and is not some general-purpose string that is 
used to append otherwise missing parameters, and differs with each render.
  
  
  The slot name defines the function or disposition of the content. I think 
"english html representation" fits that bill.
  
  Since we want to associate some meta-info with slot names (content model, 
primary orderived, blob store to use, etc), we'd have a stable prefix plus an 
optional dynamic suffix.
  
  I think this is conceptually sound, and allows for nice things like finding 
all html.canonical slots in the database easily. Putting hashes or uuids in 
there is less pretty, I agree, but still not horrible. When we start encoding 
JSON in there, then something went wrong indeed...
  
  > I would argue that it is a case of finding an abstraction at the right 
level. A simple blob store is a very low-level abstraction, and severely limits 
the backend's abilities to optimize storage, distribution & consistency. It 
also limits the backend's usefulness as an API in its own right.
  
  A narrow and dumb interface for the BlobStore is quite intentional. I want to 
be able to *easily* implement a BlobStore based on the file system or CDB or 
whatever. Yes, it's fairly low level, but I think we should have it. And I 
think we should have such a low level BlobStore that is backed by RESTBase. But 
perhaps RESTBase can also implement a more high level interface, for managing 
slot information. But I think that should be kept separate from the 
intentionally low level BlobStore interfacce.
  
  > Instead, I think we should clearly define the API for each slot to provide 
/ consume
  > 
  > - page id,
  > - page title,
  > - revision id, and
  > - a UUID / hash / etag.
  
  Every //slot//, yes. Every //blob//, no. The BlobStore should not know or 
care about these things. I guess that is where we disagree.
  
  > This makes sure that backends can continue to implement higher-level 
functionality & important optimizations. This should be part of the API, and 
not a case of a "leak". That said, backends *can* choose to ignore all of this 
(but the UUID / hash).
  
  Yes, that's the kind of high level functionality a RevisionStore would 
provide. If you want to do that in RESTBase, then you'd have to implement a 
RESTBase RevisionStore (or RevisionSlotStore, if we introduce an intermediate 
layer of abstraction).
  
  My point is that we shouldn't have all the meta-info in the //lowest// layer 
of abstraction of storage. And BlobStore is the lowest in this context. And I 
believe we should indeed have such a low level abstraction layer, if only to 
encapsulate what's there already: the text table, and external store.
  
  > A minimum set of metadata (like the versioned content-type) should always 
be provided. It would be nice to model this in a way that's compatible with 
normal HTTP headers, as stored & returned by services like RESTBase.
  
  Our baseline implementation is just what's in the text table. The next level 
implementation is just what ExternalStore has. Neither of them can handle or 
provide meta-data. Our interface needs to be compatible with that baseline.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Retitled] T53051: Set useful and consistent (in client/repo) default namespaces

[matej_suchanek]

matej_suchanek changed the title from "Set useful and consistent (in 
client/repo) default namespaces." to "Set useful and consistent (in 
client/repo) default namespaces".
matej_suchanek removed a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T53051

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: matej_suchanek
Cc: gerritbot, liangent, aude, Lucie, Lydia_Pintscher, daniel, hoo, D3r1ck01, 
Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  @GWicke Perhaps some confusion is caused by us thinking of the storage 
backend in different terms. For me, RESTBase is a BlobStore. A BlobStore deals 
with binary data, which it stores and assignes urls to, and which it can 
retrieve given such a url. That's it.
  
  It seems to me that you think of RESTBase more on the level of managing slot 
meta-data. I don't really see how that would work. Though I do see how we can 
expose some of that meta-data to RESTBase (and BlobStores in general) so 
optimization can be applied.
  
  In my mind, a higher level RESTbase interface, eg. one dealing with entire 
revisions, would be based on the  new functionality of RevisionStore and 
friends, not vice versa.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[GWicke]

GWicke added a comment.


  > In any case, the PageUpdater / WikiPage code needs to trigger notifications 
(produce events). I don't care what mechanism it used for that. Or rather: I'm 
very happy if we get a generalized mechanism. We'll have to agree on some kind 
of schema for revisions, slots, and blobs, but that should be easy enough.
  
  Makes sense. Thanks for the clarification!
  
  >> In addition to title and revision (which I assume remains an integer), 
we'd need an optional v1 UUID parameter to retrieve specific renders, in both 
the request & response interfaces.
  
  
  
  > I have thought about this, too. My solution is to encode this in the slot 
name. So you could have an html.canonical (sub)slot, and a 
html.29e68f78-8765-49f8-86d5-dfc438d459fe, or html.en, or whatever.
  
  Hmmm, this sounds like a rather ugly hack. I thought the 'slot' is 
identifying the kind of content, and is not some general-purpose string that is 
used to append otherwise missing parameters, and differs with each render.
  
  >> How would a dumb blob store figure out which content belongs to the same 
page (and is thus similar), if all it has is the content & some metadata, but 
not the page id, title, revision & render UUID? This is the same design issue 
that plagues ExternalStore, and something we addressed in RESTBase. With 
large-window compression algorithms like brotli, we are getting down to 2-3% of 
the input HTML size (see https://phabricator.wikimedia.org/T122028). Without 
this locality information, you are likely to use an order of magnitude more 
storage as you are foregoing efficient delta compression.
  > 
  > This is a good point. Once again, we want our abstraction to be a bit 
leaky, to allow for optimizations.
  
  I would argue that it is a case of finding an abstraction at the right level. 
A simple blob store is a very low-level abstraction, and severely limits the 
backend's abilities to optimize storage, distribution & consistency. It also 
limits the backend's usefulness as an API in its own right.
  
  Instead, I think we should clearly define the API for each slot to provide / 
consume
  
  - page id,
  - page title,
  - revision id, and
  - a UUID / hash / etag.
  
  This makes sure that backends can continue to implement higher-level 
functionality & important optimizations. This should be part of the API, and 
not a case of a "leak". That said, backends *can* choose to ignore all of this 
(but the UUID / hash).
  
  > I havn't thought this through yet, but my inclanation is that we could 
associate a metadata array (k/v set) with the blob, which could include things 
like a hash and the page title. A BlobStore would be free to use this or not, 
to store it or not, and to make it retrievable or not.
  
  A minimum set of metadata (like the versioned content-type) should always be 
provided. It would be nice to model this in a way that's compatible with normal 
HTTP headers, as stored & returned by services like RESTBase.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, GWicke
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  There is no redirection to maintain. The blob url from the old revision
  
  In https://phabricator.wikimedia.org/T107595#2265137, @GWicke wrote:
  
  > Makes sense, some of these fields won't change between revisions. Depending 
on the constraints, it might still make sense to store unchanged content & rely 
on compression to encode it efficiently, rather than introduce & maintain a 
redirection.
  
  
  There's no redirection. When a slot is not edited between revisions, the 
respective rows in the slots table would simply contain the same blob ID. Or to 
put it differently: when creating a new revision, all (primary) slots are 
copied to the new revision, except for the ones explicitly changed for the new 
revision. So if rev 1 has a slot record for slot X that specified the blob url 
restbase:uri:abc (1,X,restbase:uri:abc), and rev 2 doesn't edit slot X, then 
rev 2 will have   (2,X,restbase:uri:abc). No aliasing, no redirection. Just the 
same blob data url.
  
  > In any case, as long as you ask the backend for content for a specific 
title / page id, revision & UUID, backends are free to use whatever performs 
best.
  
  As the code is currently designed, the storage backend would never be called 
for slots that remain the same for the new revision. Why would it? We'd have to 
load all the data and then send it back to the backend, for nothing.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[GWicke]

GWicke added a comment.


  > Blobs would typically be shared by different revisions of the same page. 
This happens every time one primary slot is edited, but another is not changed. 
E.g. the free wikitext description of a file is edited, but the structured data 
isn't (or vice versa). Or the quality assessment data of an article is updated, 
but the article text isn't edited. In both cases, one of the blobs would be 
re-used by the new revision. I think this will actually be more common than 
editing all primary streams at once.
  
  Makes sense, some of these fields won't change between revisions. Depending 
on the constraints, it might still make sense to store unchanged content & rely 
on compression to encode it efficiently. This is likely what we'll continue to 
do in RESTBase, as this makes sure that access by revision continues to perform 
predictably.
  
  In any case, as long as you ask the backend for content for a specific title 
/ page id, revision & UUID, backends are free to use whatever performs best.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, GWicke
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T56097: [Story] allow to select globe in the UI

[Smalyshev]

Smalyshev added a comment.


  Since it uses pywikibot, it is limited by what pywikibot's set of globes, 
which currently seems to have some missing. I'll submit a patch to update it.

TASK DETAIL
  https://phabricator.wikimedia.org/T56097

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Smalyshev
Cc: Smalyshev, Nikki, Aklapper, Liuxinyu970226, Wikidata-bugs, Micru, 
Ricordisamoa, Lydia_Pintscher, D3r1ck01, Izno, aude, TheDJ, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T133658: [Story] Improve textual representation of query parameters and services

[gerritbot]

gerritbot added a comment.


  Change 286806 merged by jenkins-bot:
  Textual representation of LIMIT
  
  https://gerrit.wikimedia.org/r/286806

TASK DETAIL
  https://phabricator.wikimedia.org/T133658

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Aklapper, Jonas, Avner, Lewizho99, Maathavan, debt, Gehel, 
D3r1ck01, FloNight, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, 
Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T133044: [Task] Handle cases where assiging a fresh ID to a new entity expects numeric entity IDs

[gerritbot]

gerritbot added a comment.


  Change 277582 merged by jenkins-bot:
  Only use numeric ids on supported entity types
  
  https://gerrit.wikimedia.org/r/277582

TASK DETAIL
  https://phabricator.wikimedia.org/T133044

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine, gerritbot
Cc: gerritbot, Steinsplitter, Aklapper, Bene, JeanFred, Ricordisamoa, El_Grafo, 
Jheald, Micru, DannyH, Raymond, Ayack, Smalyshev, LikeLifer, adrianheine, 
Pokefan95, aude, TerraCodes, Tobi_WMDE_SW, Lewizho99, Maathavan, D3r1ck01, 
Izno, Wikidata-bugs, Fabrice_Florin, Mbch331, Tgr



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI)

[kaldari]

kaldari edited the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T127929

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: kaldari
Cc: Sadads, Pokefan95, gerritbot, DannyH, Micru, intracer, mkroetzsch, 
Aklapper, daniel, Steinsplitter, Lydia_Pintscher, Riley_Huntley, D3r1ck01, 
Izno, Wikidata-bugs, aude, El_Grafo, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  In https://phabricator.wikimedia.org/T107595#2264799, @GWicke wrote:
  
  > It is not entirely clear to me whether PageUpdater (and RevisionUpdater) 
are meant to only handle synchronous low-level updates, or whether they are 
meant to orchestrate asynchronous change propagation as well. I would suggest 
focusing PageUpdater and RevisionUpdater on synchronous / low-level updates 
only, and leave asynchronous change propagation to EventBus / the change 
propagation service.
  
  
  RevisionUpdater/RevisionBuilder operates on the same level as Revision: no 
secondary data, no notifications. Just storage.
  
  PageUpdater would operate on the same level as WikiPage, but I think we 
should first get RevisionBuilder working, and leave PageUpdater as it is, for 
now.
  
  In any case, the PageUpdater / WikiPage code needs to trigger notifications 
(produce events). I don't care what mechanism it used for that. Or rather: I'm 
very happy if we get a generalized mechanism. We'll have to agree on some kind 
of schema for revisions, slots, and blobs, but that should be easy enough.
  
  >> The bob-store is (potentially) content-adressable, so the same blob may be 
used for different revisions of different pages.
  > 
  > Blob sharing would complicate your storage significantly, as you'd either 
have to forgo deleting content forever (very expensive for something like HTML 
renders), 
  >  or incur significant complexity of implementing an atomic reference 
counting scheme.
  
  I have pushed by the //derived slots// in my mind until we have the 
//primary// slots working. I agree that for "volatile" data, we'd not want to 
use content-adressable blobs, for the reason you menationed.
  
  > For textual content, I am pretty certain that sharing is rare, and the 
complexity would overall be a loss in performance and reliability.
  
  Sharing between different pages is probable rare, but:
  
  >> Even for blobs that have an incremental ID (e.g. using the current text 
table storage mechanism), the same blob would frequently be used for multiple 
blobs of the same page.
  
  Blobs would typically be shared by different revisions of the //same// page. 
This happens every time one primary slot is edited, but another is not changed. 
E.g. the free wikitext description of a file is edited, but the structured data 
isn't (or vice versa). Or the quality assessment data of an article is updated, 
but the article text isn't edited. In both cases, one of the blobs would be 
re-used by the new revision. I think this will actually be more common than 
editing all primary streams at once.
  
  > How would a dumb blob store figure out which content belongs to the same 
page (and is thus similar), if all it has is the content & some metadata, but 
not the page id, title, revision & render UUID? This is the same design issue 
that plagues ExternalStore, and something we addressed in RESTBase. With 
large-window compression algorithms like brotli, we are getting down to 2-3% of 
the input HTML size (see https://phabricator.wikimedia.org/T122028). Without 
this locality information, you are likely to use an order of magnitude more 
storage as you are foregoing efficient delta compression.
  
  This is a good point. Once again, we want our abstraction to be a bit leaky, 
to allow for optimizations.
  
  I havn't thought this through yet, but my inclanation is that we could 
associate a metadata array (k/v set) with the blob, which could include things 
like a hash and the page title. A BlobStore would be free to use this or not, 
to store it or not, and to make it retrievable or not.
  
  > I am generally trying to work out how RevisionContentLookup would work for 
use cases like fetching HTML from RESTBase. Some notes / questions:
  > 
  > - In addition to title and revision (which I assume remains an integer), 
we'd need an optional v1 UUID parameter to retrieve specific renders, in both 
the request & response interfaces.
  
  I have thought about this, too. My solution is to encode this in the slot 
name. So you could have an html.canonical (sub)slot, and a 
html.29e68f78-8765-49f8-86d5-dfc438d459fe, or html.en, or whatever.
  
  > - Will getTouched() return the UUID timestamp of a specific render 
(last-modified, essentially), or is this about page_touched? Also, should we 
expose UUIDs to make sure that we have a unique ID with a high-resolution 
timestamp?
  
  getTouched() will return the touch date of the slot. For primary slots, this 
will always be the revision (edit) timestamp. For derived slots, it would be 
the time that slot was last updated [i'd love to use a logical clock for this, 
instead of wall clock time...].
  
  I'd expose URLs. Their format would be left to the blob store. Could be a 
UUID.
  
  > - For content from RESTBase, read restrictions are always enforced as part 
of the API request. No information about the applied restrictions is returned. 
In this context, 

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  ///me notes that we are getting side tracked here, and this could turn into a 
separate rfc//
  
  I'd rather have the Transaction object know about the database, than the 
other way around. Why should the database be in charge of transactions (other 
than transactions inside the database)? So I'd turn this around a little:
  
$trx = new Transaction();
$trx->addDatabaseConnection( $dbw );

$trx->run(function($trx) use ($this) {
  // ...
  $url = $blobStore->saveBlob( $data, $trx );
  // ...
});
// if we reach this far, the transaction successfully committed.
// otherwise it'll have thrown an exception

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T123087: [Task] Track use of Create Article and Translate Article buttons

[gerritbot]

gerritbot added a comment.


  Change 286839 merged by jenkins-bot:
  Track the create-article button
  
  https://gerrit.wikimedia.org/r/286839

TASK DETAIL
  https://phabricator.wikimedia.org/T123087

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Lucie, Addshore, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, 
Wikidata-bugs, aude, jayvdb, Ricordisamoa, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Retitled] T134371: [Story] Highlight already-existing properties while adding a new statement on an item to avoid duplicate edits

[Lydia_Pintscher]

Lydia_Pintscher changed the title from "Suggestion: Identify already-existing 
properties on an item to avoid duplicate edits" to "[Story] Highlight 
already-existing properties while adding a new statement on an item to avoid 
duplicate edits".
Lydia_Pintscher triaged this task as "Normal" priority.

TASK DETAIL
  https://phabricator.wikimedia.org/T134371

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher
Cc: Lydia_Pintscher, BrillLyle, Nemo_bis, Aklapper, Zppix, agray, D3r1ck01, 
Izno, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134371: Suggestion: Identify already-existing properties on an item to avoid duplicate edits

[Lydia_Pintscher]

Lydia_Pintscher added a comment.


  Yes highlighting the case but still allowing it where it makes sense sounds 
good to me too. We'll do that but it'll take time. Thank you for the idea!

TASK DETAIL
  https://phabricator.wikimedia.org/T134371

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher
Cc: Lydia_Pintscher, BrillLyle, Nemo_bis, Aklapper, Zppix, agray, D3r1ck01, 
Izno, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T107595: [RFC] Multi-Content Revisions

[GWicke]

GWicke added a comment.


  > Where do I propose another mechanism for change propagation? The 
PageUpdater would do exactly what Revision does now: schedule DataUpdates.
  
  EventBus & the change propagation service are moving away from scheduling 
"jobs", and towards an event processing approach based on Kafka. In this model, 
subscribers react to change events associated with resources. Event production 
& processing / consumption is decoupled and decentralized.
  
  PageUpdater (and RevisionUpdater) as proposed seem to be moving in the 
opposite direction, towards more jobs & away from event processing.
  
  > The bob-store is (potentially) content-adressable, so the same blob may be 
used for different revisions of different pages.
  
  Blob sharing would complicate your storage significantly, as you'd either 
have to forgo deleting content forever (very expensive for something like HTML 
renders), or incur significant complexity of implementing an atomic reference 
counting scheme. For textual content, I am pretty certain that sharing is rare, 
and the complexity would overall be a loss in performance and reliability.
  
  > Even for blobs that have an incremental ID (e.g. using the current text 
table storage mechanism), the same blob would frequently be used for multiple 
blobs of the same page.
  
  How would a dumb blob store figure out which content belongs to the same page 
(and is thus similar), if all it has is the content & some metadata, but not 
the page id, title, revision & render UUID? This is the same design issue that 
plagues ExternalStore, and something we addressed in RESTBase. With 
large-window compression algorithms like brotli, we are getting down to 2-3% of 
the input HTML size (see https://phabricator.wikimedia.org/T122028). Without 
this locality information, you are likely to use an order of magnitude more 
storage as you are foregoing efficient delta compression.
  
  I am generally trying to work out how RevisionContentLookup would work for 
use cases like fetching HTML from RESTBase. Some notes / questions:
  
  - In addition to title and revision (which I assume remains an integer), 
we'll need an optional v1 UUID parameter to retrieve specific renders, in both 
the request & response interfaces.
  - Will getTouched() return the UUID timestamp of a specific render 
(last-modified, essentially), or is this about page_touched? Also, should we 
expose UUIDs to make sure that we have a unique ID with a high-resolution 
timestamp?
  - For content from RESTBase, read restrictions are always enforced as part of 
the API request. No information about the applied restrictions is returned. In 
this context, getReadRestrictions() would basically always return the empty set.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, GWicke
Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, 
intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, 
awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134371: Suggestion: Identify already-existing properties on an item to avoid duplicate edits

[Nemo_bis]

Nemo_bis added a comment.


  > the existing lines could "snap down" to be displayed alongside the new line 
for that item
  
  This is the best solution (or alternatively, scroll up to the existing box 
for that property).

TASK DETAIL
  https://phabricator.wikimedia.org/T134371

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Nemo_bis
Cc: Nemo_bis, Aklapper, Zppix, agray, D3r1ck01, Izno, Wikidata-bugs, aude, 
Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T53051: Set useful and consistent (in client/repo) default namespaces.

[gerritbot]

gerritbot added a comment.


  Change 177526 abandoned by Lucie Kaffee:
  added Item to wikibase-item
  
  Reason:
  Too old, no discussion, so abandoning it.
  
  https://gerrit.wikimedia.org/r/177526

TASK DETAIL
  https://phabricator.wikimedia.org/T53051

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, liangent, aude, Lucie, Lydia_Pintscher, daniel, hoo, Lewizho99, 
Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[brion]

brion added a comment.


  > This assumes the BlobStore will actually talk to the (same) database. I 
would like to have Transaction separate from the DB stuff, so it can be used 
just as well with files, or Cassandra, or Swift, or whatever we come up with to 
store blobs. We shouldn't assume that it knows about SQL at all.
  
  Quite so...
  
  Let's try instead:
  
$dbw->transact(function($trx) use ($this, $dbw) {
  // $trx is a Transaction obj managed by the Database object, which will
  // have its commit or rollback callbacks triggered when Database\transact 
reaches its end state

  // ...
  $url = $blobStore->saveBlob( $data, $trx );
  // ...
  
});
// if we reach this far, the transaction successfully committed.
// otherwise it'll have thrown an exception

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, brion
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134238: Query service fails with "Too many open files"

[Stashbot]

Stashbot added a comment.


  Mentioned in SAL [2016-05-04T16:19:14Z]  restarting blazegraph 
(https://phabricator.wikimedia.org/T134238)

TASK DETAIL
  https://phabricator.wikimedia.org/T134238

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Gehel, Stashbot
Cc: Smalyshev, Joe, Stashbot, Envlh, JanZerebecki, hoo, Frog23, Karima, 
Aklapper, Yair_rand, Zppix, Avner, debt, Gehel, D3r1ck01, FloNight, Izno, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134386: Wikidata build has faling test Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest

[JanZerebecki]

JanZerebecki added a comment.


  New build: https://gerrit.wikimedia.org/r/#/c/286891/1

TASK DETAIL
  https://phabricator.wikimedia.org/T134386

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: daniel, Urbanecm, TerraCodes, Luke081515, Aklapper, JanZerebecki, Zppix, 
D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  In https://phabricator.wikimedia.org/T107595#2264511, @brion wrote:
  
  > and internally in the BlobStore's save method, we add the rollback callback 
straight onto the db object:
  >
  > That avoids having transaction state live separately in both the connection 
and a Transaction object. Good model? Bad model?
  
  
  This assumes the BlobStore will actually talk to the (same) database. I would 
like to have Transaction separate from the DB stuff, so it can be used just as 
well with files, or Cassandra, or Swift, or whatever we come up with to store 
blobs. We shouldn't assume that it knows about SQL at all.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134351: [Bug] HTMLFormField calls Message::setContext( null )

[gerritbot]

gerritbot added a comment.


  Change 286864 merged by jenkins-bot:
  ApiOptions: set form field parent earlier
  
  https://gerrit.wikimedia.org/r/286864

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tgr, gerritbot
Cc: Urbanecm, TerraCodes, Tgr, Anomie, Luke081515, gerritbot, Aklapper, Zppix, 
Tobi_WMDE_SW, aude, hoo, JanZerebecki, Lydia_Pintscher, thiemowmde, Lewizho99, 
Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Closed] T134351: [Bug] HTMLFormField calls Message::setContext( null )

[Tgr]

Tgr closed this task as "Resolved".
Tgr added a comment.


  Splitting the generic problem to T134401: It is unclear what should happen 
when HTMLFormField::$mParent is null 
.

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tgr
Cc: Urbanecm, TerraCodes, Tgr, Anomie, Luke081515, gerritbot, Aklapper, Zppix, 
Tobi_WMDE_SW, aude, hoo, JanZerebecki, Lydia_Pintscher, thiemowmde, Lewizho99, 
Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134386: Wikidata build has faling test Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest

[daniel]

daniel added a comment.


  This was apparently fixed in Ic0e7cd97fc23f5e0e0422208ba66fe940f6b4dcc, see 
https://gerrit.wikimedia.org/r/#/c/286409/2/src/View/MediaInfoView.php

TASK DETAIL
  https://phabricator.wikimedia.org/T134386

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: daniel, Urbanecm, TerraCodes, Luke081515, Aklapper, JanZerebecki, Zppix, 
D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T134386: Wikidata build has faling test Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest

[daniel]

daniel added a comment.


  Can't reproduce with current master of Wikibase 
(https://phabricator.wikimedia.org/rEWBAe185e960d35430a0d70586450c39517cffadf46c)
 and MediaInfo 
(https://phabricator.wikimedia.org/rEWBIbd4bb05d5b859bbedcecedb5ef852a88552eef36).
 MediaInfoViewTest passes, and MediaInfoView calls getHtml with 7 parameters, 
as expected.

TASK DETAIL
  https://phabricator.wikimedia.org/T134386

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: daniel, Urbanecm, TerraCodes, Luke081515, Aklapper, JanZerebecki, Zppix, 
D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T134351: [Bug] HTMLFormField calls Message::setContext( null )

[ReleaseTaggerBot]

ReleaseTaggerBot added projects: WMF-deploy-2016-05-08_(1.28.0-wmf.1), 
MW-1.27-release-notes, WMF-deploy-2016-05-01_(1.27.0-wmf.23).

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tgr, ReleaseTaggerBot
Cc: Urbanecm, TerraCodes, Tgr, Anomie, Luke081515, gerritbot, Aklapper, Zppix, 
Tobi_WMDE_SW, aude, hoo, JanZerebecki, Lydia_Pintscher, thiemowmde, Lewizho99, 
Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[brion]

brion added a comment.


  In https://phabricator.wikimedia.org/T107595#2264334, @daniel wrote:
  
  > We could (optionally?) provide a transaction context to the blob store like 
this:
  
  
  I kinda like that, yeah. Maybe extend Database with a transactional interface 
that takes a callback:
  
$dbw->transaction(function() use ($this, $dbw) {
  // blah blah blah
});
// if we reach this far, the transaction successfully committed.
// otherwise it'll have thrown an exception
  
  and internally in the BlobStore's save method, we add the rollback callback 
straight onto the db object:
  
$dbw->addRollbackCallback( function() use ( $url ) { $this->delete( $url ); 
} )
  
  That avoids having transaction state live separately in both the connection 
and a Transaction object. Good model? Bad model?

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, brion
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T133660: [Story] Improve editing of textual representation - add and delete

[gerritbot]

gerritbot added a comment.


  Change 286885 had a related patch set uploaded (by Jonas Kress (WMDE)):
  Deleting of triples in textual representation
  
  https://gerrit.wikimedia.org/r/286885

TASK DETAIL
  https://phabricator.wikimedia.org/T133660

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Aklapper, Jonas, Avner, Lewizho99, Maathavan, debt, Gehel, 
D3r1ck01, FloNight, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, 
Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  In https://phabricator.wikimedia.org/T107595#2264302, @brion wrote:
  
  > The remaining questions are
  >
  > - whether we want to pass the $dbw parameter through (do we always go 
through load balancer in which case it'll be the same connection anyway? or are 
there cases where a separate connection may be used to insert revs for some 
reason?) and
  
  
  I think the RevisionBuilder can hold a single Database reference for the time 
between initialization and apply(). At the end of apply(), it should release 
the Database objects via LoadBalancer::reuseConnection(). A LoadBalancer 
instance should be injected into the RevisionBuilder from the RevisionStore.
  
  > - whether there's any nested-transaction problems if someone tries to 
insert multiple revs in an explicitly larger transaction
  
  Do we need to support this? Do we have any code that does this? It seems like 
even during import, a transaction shouldn't span multiple revisions. The new 
code should basically expect a transaction bracket exactly where there is one 
now.
  
  Hm... that probably means that we cant have begin/commit/collback inside 
apply(). This needs to be done by the caller, and the caller would need to call 
either apply() (aka commit) or rollback() on the RevisionBuilder.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Assigned] T134351: [Bug] HTMLFormField calls Message::setContext( null )

[thiemowmde]

thiemowmde lowered the priority of this task from "Unbreak Now!" to "Normal".
thiemowmde assigned this task to Tgr.
thiemowmde moved this task from Proposed to Done on the 
Wikidata-Sprint-2016-04-26 board.

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1939/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tgr, thiemowmde
Cc: Urbanecm, TerraCodes, Tgr, Anomie, Luke081515, gerritbot, Aklapper, Zppix, 
Tobi_WMDE_SW, aude, hoo, JanZerebecki, Lydia_Pintscher, thiemowmde, Lewizho99, 
Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T133299: [Task] Replace bogus $ anchor in regular expressions with \z

[gerritbot]

gerritbot added a comment.


  Change 286813 merged by jenkins-bot:
  Fix newline injection vector in MediaInfoId validation
  
  https://gerrit.wikimedia.org/r/286813

TASK DETAIL
  https://phabricator.wikimedia.org/T133299

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, gerritbot
Cc: adrianheine, gerritbot, daniel, JanZerebecki, Tobi_WMDE_SW, Aklapper, 
Lydia_Pintscher, thiemowmde, TerraCodes, Lewizho99, Maathavan, D3r1ck01, Izno, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  We could (optionally?) provide a transaction context to the blob store like 
this:
  
$trx = new Transaction();
$trx->addDBConnection( $dbw ); 
$trx->start();
try {
  foreach ( $something as $thing ) {
$url = $blobStore->saveBlob( $data, $trx );
...
  }

  $trx->commit();
} catch ( Exception $ex ) {
  $trx->rollback();
  throw $ex;
}
  
  Now we no longer have to worry about whether the data urls are unique or 
content based. The blob store itself knows how to do the cleanup right. Inside 
`saveBlob`, TRX support could look something like this:
  
$url = $this->write( $data );
$try->addRollbackCallback( function() use ( $url ) { $this->delete( $url ); 
} )
return $url;
  
  or perhaps:
  
$url = $this->makeUrl( $data );
$try->addCommitCallback( function() use ( $url, $data ) { $this->write( 
$url, $data ); } )
return $url;
  
  I'd like to bake this ability into the design from the start, or at least 
keep it in mind so it's not too hard to add later. That doesn't mean that the 
blob store has to actually use the trx context. Or that we initially need a trx 
object at all.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[brion]

brion added a comment.


  (if RevisionBuilder takes a $dbw param via constructor/factory, then the 
question of the connection is easier)

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, brion
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[brion]

brion added a comment.


  > The above code would replace much of what is in the Revision class now, in 
particular insertOn(). We can keep Revision around, but I'm not sure we can 
provide b/c for insertOn().
  
  b/c here looks relatively straightforward to me; it creates a new revision 
with an updated default slot from the text content & metadata in the Revision 
object. This should be implementable by calling through to RevisionBuilder.
  
  The remaining questions are
  
  - whether we want to pass the $dbw parameter through (do we always go through 
load balancer in which case it'll be the same connection anyway? or are there 
cases where a separate connection may be used to insert revs for some reason?) 
and
  - whether there's any nested-transaction problems if someone tries to insert 
multiple revs in an explicitly larger transaction
  
  (Revision\insertOn doesn't try to manage transactions itself, and will leak 
external storage blobs if its text & revision updates get rolled back.)

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, brion
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134351: [Bug] HTMLFormField calls Message::setContext( null )

[gerritbot]

gerritbot added a comment.


  Change 286855 merged by jenkins-bot:
  Fix HTMLFormField calling Message::setContext with null
  
  https://gerrit.wikimedia.org/r/286855

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Urbanecm, TerraCodes, Tgr, Anomie, Luke081515, gerritbot, Aklapper, Zppix, 
Tobi_WMDE_SW, aude, hoo, JanZerebecki, Lydia_Pintscher, thiemowmde, Lewizho99, 
Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[brion]

brion added a comment.


  re this:
  
$bs->deleteBlob( $dataUrl ); // dk: this goes wrong if the URL is 
content/hash based!
  
  I think the return from this:
  
$dataUrl = $bs->saveBlob( $content->serialize() );
  
  needs to signal whether a blob was created or whether an existing blob was 
reused. This means the blob store itself needs a transactional concept at least 
within the boundaries of 'does this blob exist?' followed by 'store this blob'. 
If two processes conflict (adding the same content at around the same time), 
then the second one needs to be able to detect the conflict and return the 
'reference to existing' signal instead of the 'inserted new' signal.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, brion
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  Pseudo-code for `saveRevisionRecord()`
  
// assume we are in a db transaction
$this->checkIsCurrentRevision( $this->baseRevision ); // protect against 
race condition

$model = $slots['main']->getModel(); // "main" model must always be there
$length = SUM( $slots[*]->getModel() );
$hash = count($slots) < 2 ? $slots[0]->getHash() : HASH( 
$slots[*]->getHash() ); // special case for b/c

$revId = $this->insertRevision( $user, $comment, $timestamp, $model, 
$length, $hash, $parentRev, ... );

foreach ( $slots as $name => $slot ) {
$this->insertSlot( $revId, $name, $slot );
}

$this->updatePage( $this->title, $revId ); // make the new revision the 
current revision.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134351: [Bug] HTMLFormField calls Message::setContext( null )

[Tgr]

Tgr added a comment.


  At a glance, the methods which will break if `mParent` is not set are
  
  - HTMLFormField::getErrorsAndErrorClass 
,
 HTMLFormField::getErrorsRaw 

 and HTMLFormField::getLabelHtml 

  - HTMLButtonField::getInputHTML 

  - HTMLCheckMatrix::getOneCheckbox 

 (eventually called from getInputHTML) and HTMLCheckMatrix::loadDataFromRequest 

  - HTMLFormFieldCloner::getInputHTMLForKey 

 (called from getInputHTML)
  - HTMLHiddenField::getTableRow 

  - HTMLMultiSelectField::getOneCheckbox 

  - HTMLSelectLimitField::validate 

  - HTMLTitleTextField::validate 

 and HTMLTitleTextField::getInputWidget 

  - HTMLUserTextField::getInputWidget 

 and HTMLUserTextField::getInputHtml 


TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tgr
Cc: Urbanecm, TerraCodes, Tgr, Anomie, Luke081515, gerritbot, Aklapper, Zppix, 
Tobi_WMDE_SW, aude, hoo, JanZerebecki, Lydia_Pintscher, thiemowmde, Lewizho99, 
Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134351: [Bug] HTMLFormField calls Message::setContext( null )

[gerritbot]

gerritbot added a comment.


  Change 286864 had a related patch set uploaded (by Gergő Tisza):
  ApiOptions: set form field parent earlier
  
  https://gerrit.wikimedia.org/r/286864

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Urbanecm, TerraCodes, Tgr, Anomie, Luke081515, gerritbot, Aklapper, Zppix, 
Tobi_WMDE_SW, aude, hoo, JanZerebecki, Lydia_Pintscher, thiemowmde, Lewizho99, 
Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[daniel]

daniel added a comment.


  Thanks for moving this forward, Brion!
  
  Your code is pretty close to what I had in mind. I have repeated it below 
with some changes marked `// dk`
  
  In https://phabricator.wikimedia.org/T107595#2263968, @brion wrote:
  
  > In MediaWiki in general we're pretty lax about allowing unused data to 
accumulate in places like that, as long as its presence isn't harmful. Not the 
best practice but it has plenty of precedent. :)
  
  
  Indeed, and I don't think we should try to implement ACID semantics here. But 
I would like to design the interface in a way that provides a natural place for 
a transaction bracket to be implemented, if we ever have the need.
  
  > So an update pseudocode might look like:
  
$plu = $something->getPageLookupService();
$pr = $plu->getPageRecord( $title );   // dk: $pr is a "dumb" 
record, not a store
$initialRevId = $pr->getCurrentRevisionId();

$rs = $ps->getRevisionStore();

$rb = $rs->getRevisionBuilder( $initialRevId, $baseRevId ); // dk: the 
$baseRevId may not be the same as the $initialRevId
$rb->setUser($user); // dk: let's avoid RequestContext
$rb->setComment("awesome sauce");
$rb->updateSlot('main', $updatedTextContent); // dk: $updatedTextContent 
and $updatedScriptData are Content objects
$rb->updateSlot('script', $updatedScriptData);

$rs->apply( $rb ); // dk: or just save()?
  
  > where inside the RevisionStore\apply method there's something like:
  
$dbw->start();
$bs = $this->blobStore();
$addedBlobs = [];
if ($previousRevision) {
  $oldSlots = $previousRevision->getSlots();
} else {
  $oldSlots = [];
}
try {
  foreach( $this->slotUpdates as $name => $content ) { // dk: slot name => 
Content object
// dk: The blob store knows nothing about revisions or slots or content 
models.
// The idea is that the same service interface can be used for all 
kinds of blobs.
// We could add optional suppor for meta-data there, but it's not 
needed.
$dataUrl = $bs->saveBlob( $content->serialize() );
$addedBlobs[] = $dataUrl;
// dk: the slot table associates $revId + $name to $dataUrl. We'll also 
want to
// store content model, size and hash from the Content object.
$slots[$name] = new Slot( $dataUrl, $content->getModel(), 
$content->getSize(), ... );
  }
  // dk: saveRevisionRecord() has to do a lot of things: intert into the 
revision table,
  // insert into the slot table for each slot (using the new revision id), 
update the
  // page table. rev_len and rev_sha1 need to be calculated from the slots, 
rev_content_model
  // and page_content_model should be set to the main slot's model for b/c. 
  // And it needs to check against $baseRevisionId to detect race 
conditions.
  this->saveRevisionRecord( $blah1, $blah2, $slots ); 
  $dbw->commit();
} catch (Exception $e) {
  // If update failed, clean up any newly added backing blobs, which
  // may be in external databases, filesystems, or services.
  try {
foreach( $addedBlobs as $dataUrl ) {
  $bs->deleteBlob( $dataUrl ); // dk: this goes wrong if the URL is 
content/hash based!
}
  } catch (Exception $e2) {
 // if we can't get in to delete them, let them leak. they're safe.
  }
  try {
// dk: this shoud roll back al lchanges to the page table, the revision 
table, and the slot table.
$dbw->rollback();
  } catch (Exception $e3) {
// that probably means the db connection died.
  }
  throw $e;
}
  
  The above code would replace much of what is in the Revision class now, in 
particular insertOn(). We can keep Revision around, but I'm not sure we can 
provide b/c for insertOn(). 
  I suppose the update logic outlined at the top would would for now live in 
WikiPage for now. It would be called pretty much in the places where we now 
call Revision::insertOn().
  
  Of course, WikiPage should also be refactored, but trying to do this at the 
same time as we introduce multi-content revisions is probably a bad idea. In 
fact, it's what got me stuck when I first tried to implement this.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T134351: [Bug] HTMLFormField calls Message::setContext( null )

[JanZerebecki]

JanZerebecki added projects: Wikidata, Wikidata-Sprint-2016-04-26.

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Urbanecm, TerraCodes, Tgr, Anomie, Luke081515, gerritbot, Aklapper, Zppix, 
Tobi_WMDE_SW, aude, hoo, JanZerebecki, Lydia_Pintscher, thiemowmde, Lewizho99, 
Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T133044: [Task] Handle cases where assiging a fresh ID to a new entity expects numeric entity IDs

[gerritbot]

gerritbot added a comment.


  Change 277582 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
  Only use numeric ids on supported entity types
  
  https://gerrit.wikimedia.org/r/277582

TASK DETAIL
  https://phabricator.wikimedia.org/T133044

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine, gerritbot
Cc: gerritbot, Steinsplitter, Aklapper, Bene, JeanFred, Ricordisamoa, El_Grafo, 
Jheald, Micru, DannyH, Raymond, Ayack, Smalyshev, LikeLifer, adrianheine, 
Pokefan95, aude, TerraCodes, Tobi_WMDE_SW, Lewizho99, Maathavan, D3r1ck01, 
Izno, Wikidata-bugs, Fabrice_Florin, Mbch331, Tgr



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T134386: Wikidata build has faling test Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest

[JanZerebecki]

JanZerebecki moved this task from Proposed to Backlog on the 
Wikidata-Sprint-2016-04-26 board.

TASK DETAIL
  https://phabricator.wikimedia.org/T134386

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1939/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Urbanecm, TerraCodes, Luke081515, Aklapper, JanZerebecki, Zppix, D3r1ck01, 
Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T134386: Wikidata build has faling test Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest

[JanZerebecki]

JanZerebecki triaged this task as "Unbreak Now!" priority.
JanZerebecki edited the task description.
Herald added subscribers: Luke081515, TerraCodes, Urbanecm.

TASK DETAIL
  https://phabricator.wikimedia.org/T134386

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Urbanecm, TerraCodes, Luke081515, Aklapper, JanZerebecki, Zppix, D3r1ck01, 
Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T134386: Wikidata build has faling test Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest

[JanZerebecki]

JanZerebecki created this task.
Herald added subscribers: Zppix, Aklapper.

TASK DESCRIPTION
10:06:23 1) 
Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest::testGetHtml with 
data set #0 (Wikibase\MediaInfo\DataModel\MediaInfo Object (...))
10:06:23 getHtml() expects exactly 7 parameters, 5 given
10:06:23 
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/src/View/MediaInfoView.php:92
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/Wikibase/view/src/EntityView.php:105
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/tests/phpunit/mediawiki/View/MediaInfoViewTest.php:157
10:06:23 
10:06:23 2) 
Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest::testGetHtml with 
data set #1 (Wikibase\MediaInfo\DataModel\MediaInfo Object (...), 
Wikibase\MediaInfo\DataModel\MediaInfoId Object (...))
10:06:23 getHtml() expects exactly 7 parameters, 5 given
10:06:23 
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/src/View/MediaInfoView.php:92
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/Wikibase/view/src/EntityView.php:105
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/tests/phpunit/mediawiki/View/MediaInfoViewTest.php:157
10:06:23 
10:06:23 3) 
Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest::testGetHtml with 
data set #2 (Wikibase\MediaInfo\DataModel\MediaInfo Object (...), 
Wikibase\MediaInfo\DataModel\MediaInfoId Object (...), 
Wikibase\DataModel\Term\TermList Object (...), 'en', 
Wikibase\DataModel\Statement\StatementList Object (...))
10:06:23 getHtml() expects exactly 7 parameters, 5 given
10:06:23 
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/src/View/MediaInfoView.php:92
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/Wikibase/view/src/EntityView.php:105
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/tests/phpunit/mediawiki/View/MediaInfoViewTest.php:157
10:06:23 
10:06:23 4) 
Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest::testGetHtml with 
data set #3 (Wikibase\MediaInfo\DataModel\MediaInfo Object (...), 
Wikibase\MediaInfo\DataModel\MediaInfoId Object (...), 
Wikibase\DataModel\Term\TermList Object (...), 'lkt')
10:06:23 getHtml() expects exactly 7 parameters, 5 given
10:06:23 
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/src/View/MediaInfoView.php:92
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/Wikibase/view/src/EntityView.php:105
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/tests/phpunit/mediawiki/View/MediaInfoViewTest.php:157
10:06:23 
10:06:23 5) 
Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest::testGetHtml with 
data set #4 (Wikibase\MediaInfo\DataModel\MediaInfo Object (...), 
Wikibase\MediaInfo\DataModel\MediaInfoId Object (...), 
Wikibase\DataModel\Term\TermList Object (...), 'lkt', 
Wikibase\DataModel\Statement\StatementList Object (...))
10:06:23 getHtml() expects exactly 7 parameters, 5 given
10:06:23 
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/src/View/MediaInfoView.php:92
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/Wikibase/view/src/EntityView.php:105
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/tests/phpunit/mediawiki/View/MediaInfoViewTest.php:157
10:06:23 
10:06:23 6) 
Wikibase\MediaInfo\Tests\MediaWiki\View\MediaInfoViewTest::testPlaceholderIntegration
10:06:23 getHtml() expects exactly 7 parameters, 5 given
10:06:23 
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/src/View/MediaInfoView.php:92
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/Wikibase/view/src/EntityView.php:105
10:06:23 
/mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Wikidata/extensions/MediaInfo/tests/phpunit/mediawiki/View/MediaInfoViewTest.php:326

TASK DETAIL
  https://phabricator.wikimedia.org/T134386

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Aklapper, JanZerebecki, Zppix, 

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

[brion]

brion added a comment.


  Regarding transactional nature:
  
  Assuming the backing blob storage continues to work on the model of the 
current `text` table blobs with external storage backing, the "easy way" is to 
allow extra backend blobs to leak in case of transaction rollback, and let them 
be garbage-collected.
  
  If you want to get *fancy* you can do explicit cleanup after a rollback that 
happens in PHP-land (say after catching an exception, aborting the transaction, 
and then re-throwing the exception). But this will fail in the case of a fatal 
error that can't be caught, or the process being killed, leading to leaks again.
  
  In MediaWiki in general we're pretty lax about allowing unused data to 
accumulate in places like that, as long as its presence isn't harmful. Not the 
best practice but it has plenty of precedent. :)
  
  So an update pseudocode might look like:
  
$plu = $something->getPageLookupService();
$ps = $plu->getPageStore($title);
$initialRevId = $ps->getCurrentRevisionId();

$rs = $ps->getRevisionStore();

$rb = $rs->getRevisionBuilder( $initialRevId );
$rb->setUser($context->getUser());
$rb->setComment("awesome sauce");
$rb->updateSlot('main', $updatedTextContent);
$rb->updateSlot('script', $updatedScriptData);

$rs->apply( $rb );
  
  where inside the RevisionStore\commit method there's something like:
  
$dbw->start();
$bs = $this->blobStore();
$addedBlobs = [];
if ($previousRevision) {
  $slots = $previousRevision->getSlots();
} else {
  $slots = [];
}
try {
  foreach( $this->slotUpdates as $su ) {
$blob = $bs->saveDataBlob( $su->getData() );
$addedBlobs[] = $blob;
$slots[$su->getName()] = $this->saveRevisionSlot( $blob );
  }
  $this->saveRevisionRecord( $blah1, $blah2, $slots );
  $dbw->commit();
} catch (Exception $e) {
  // If update failed, clean up any newly added backing blobs, which
  // may be in external databases, filesystems, or services.
  try {
foreach( $addedBlobs as $blob ) {
  $blob->delete();
}
  } catch (Exception $e2) {
 // if we can't get in to delete them, let them leak. they're safe.
  }
  try {
$dbw->rollback();
  } catch (Exception $e3) {
// that probably means the db connection died.
  }
  throw $e;
}

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, brion
Cc: JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, 
Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T123087: [Task] Track use of Create Article and Translate Article buttons

[Addshore]

Addshore added a comment.


  Also added commenyts to https://gerrit.wikimedia.org/r/#/c/280954/ and 
https://gerrit.wikimedia.org/r/#/c/280950/ which should both include the 
tracking

TASK DETAIL
  https://phabricator.wikimedia.org/T123087

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: gerritbot, Lucie, Addshore, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, 
Wikidata-bugs, aude, jayvdb, Ricordisamoa, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134351: [Bug] HHVM on test.wikidata.org dies with no output when setting an option

[thiemowmde]

thiemowmde added a comment.


  Issue introduced in https://gerrit.wikimedia.org/r/283846, mostly because the 
local property is not properly documented as `HTMLForm|null`. Please either 
revert the patch or provide a fix.

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde
Cc: Urbanecm, TerraCodes, Tgr, Anomie, Luke081515, gerritbot, Aklapper, Zppix, 
Tobi_WMDE_SW, aude, hoo, JanZerebecki, Lydia_Pintscher, thiemowmde, D3r1ck01, 
Izno, Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T134351: [Bug] HHVM on test.wikidata.org dies with no output when setting an option

[thiemowmde]

thiemowmde triaged this task as "Unbreak Now!" priority.
thiemowmde added subscribers: Anomie, Tgr.
thiemowmde removed a project: Patch-For-Review.
Herald added subscribers: Luke081515, TerraCodes, Urbanecm.

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde
Cc: Urbanecm, TerraCodes, Tgr, Anomie, Luke081515, gerritbot, Aklapper, Zppix, 
Tobi_WMDE_SW, aude, hoo, JanZerebecki, Lydia_Pintscher, thiemowmde, D3r1ck01, 
Izno, Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T123087: [Task] Track use of Create Article and Translate Article buttons

[gerritbot]

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T123087

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Lucie, Addshore, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, 
Wikidata-bugs, aude, jayvdb, Ricordisamoa, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T123087: [Task] Track use of Create Article and Translate Article buttons

[gerritbot]

gerritbot added a comment.


  Change 286839 had a related patch set uploaded (by Addshore):
  Track the create-article button
  
  https://gerrit.wikimedia.org/r/286839

TASK DETAIL
  https://phabricator.wikimedia.org/T123087

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Lucie, Addshore, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, 
jayvdb, Ricordisamoa, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T134351: [Bug] HHVM on test.wikidata.org dies with no output when setting an option

[JanZerebecki]

JanZerebecki edited the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: gerritbot, Aklapper, Zppix, Tobi_WMDE_SW, aude, hoo, JanZerebecki, 
Lydia_Pintscher, thiemowmde, Lewizho99, Maathavan, D3r1ck01, Izno, 
Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T75647: [Story] Log/graph dispatch lag

[Addshore]

Addshore added a comment.


  https://phabricator.wikimedia.org/T125989

TASK DETAIL
  https://phabricator.wikimedia.org/T75647

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Ricordisamoa, Aklapper, Addshore, JanZerebecki, Liuxinyu970226, D3r1ck01, 
Izno, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134351: [Bug] HHVM on test.wikidata.org dies with no output when setting an option

[gerritbot]

gerritbot added a comment.


  Change 286805 merged by jenkins-bot:
  Expand term box by default even if option does not exist
  
  https://gerrit.wikimedia.org/r/286805

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Aklapper, Zppix, Tobi_WMDE_SW, aude, hoo, JanZerebecki, 
Lydia_Pintscher, thiemowmde, Lewizho99, Maathavan, D3r1ck01, Izno, 
Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134238: Query service fails with "Too many open files"

[Stashbot]

Stashbot added a comment.


  Mentioned in SAL [2016-05-04T12:34:11Z]  restarting blazegraph 
(https://phabricator.wikimedia.org/T134238)

TASK DETAIL
  https://phabricator.wikimedia.org/T134238

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Gehel, Stashbot
Cc: Smalyshev, Joe, Stashbot, Envlh, JanZerebecki, hoo, Frog23, Karima, 
Aklapper, Yair_rand, Zppix, Avner, debt, Gehel, D3r1ck01, FloNight, Izno, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T125980: [Task] Avoid id="coordinates" in HTML ArticlePlaceholder output

[gerritbot]

gerritbot added a comment.


  Change 286664 merged by jenkins-bot:
  Avoid id="coordinates" in HTML ArticlePlaceholder output
  
  https://gerrit.wikimedia.org/r/286664

TASK DETAIL
  https://phabricator.wikimedia.org/T125980

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lucie, gerritbot
Cc: gerritbot, daniel, Aklapper, hoo, Lucie, thiemowmde, Lewizho99, Maathavan, 
D3r1ck01, Izno, Wikidata-bugs, aude, jayvdb, Ricordisamoa, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134265: [Task] Add EntityDifferStrategy builder to MediaInfo entity type definition

[gerritbot]

gerritbot added a comment.


  Change 286757 merged by jenkins-bot:
  Register EntityDifferStrategy builder and EntityId builder pair
  
  https://gerrit.wikimedia.org/r/286757

TASK DETAIL
  https://phabricator.wikimedia.org/T134265

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine, gerritbot
Cc: gerritbot, Aklapper, adrianheine, Zppix, Lewizho99, Maathavan, D3r1ck01, 
Izno, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T134264: [Task] Add EntityId builder pair to MediaInfo entity type definition

[gerritbot]

gerritbot added a comment.


  Change 286757 merged by jenkins-bot:
  Register EntityDifferStrategy builder and EntityId builder pair
  
  https://gerrit.wikimedia.org/r/286757

TASK DETAIL
  https://phabricator.wikimedia.org/T134264

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine, gerritbot
Cc: gerritbot, Aklapper, adrianheine, Zppix, Lewizho99, Maathavan, D3r1ck01, 
Izno, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T134351: [Bug] HHVM on test.wikidata.org dies with no output when setting an option

[hoo]

hoo added a project: Wikimedia-log-errors.
hoo added a comment.


  I tried this twice and got the following fatal:
  
May  4 12:13:56 mw1017:  #012Catchable fatal error: Argument 1 passed to 
Message::setContext() must implement interface IContextSource, null given in 
/srv/mediawiki/php-1.27.0-wmf.23/includes/Message.php on line 676
  
  There's no backtrace available, see https://phabricator.wikimedia.org/T89169 
for that.

TASK DETAIL
  https://phabricator.wikimedia.org/T134351

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hoo
Cc: gerritbot, Aklapper, Zppix, Tobi_WMDE_SW, aude, hoo, JanZerebecki, 
Lydia_Pintscher, thiemowmde, Lewizho99, Maathavan, D3r1ck01, Izno, 
Wikidata-bugs, Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T134371: Suggestion: Identify already-existing properties on an item to avoid duplicate edits

[agray]

agray created this task.
Herald added subscribers: Zppix, Aklapper.

TASK DESCRIPTION
  When adding a property to Wikidata items using the web interface, it is easy 
to unintentionally create a duplicate property entry - particularly on large 
items, where you may not notice that the property already existed.
  
  This isn't a major problem - many properties are intended to have multiple 
values, after all! - but can be a little frustrating:
  
  a) it can be confusing for the user, as after creating the new Pxxx line it 
"snaps up" to display alongside the existing Pxxx line, and so may seem like 
it's not been added when they look at the end of the page;
  b) it means someone has to do a little work in future removing the duplicate.
  
  A way round this might be to highlight in some way that a property Pxxx 
already exists. For example, when a user goes to add a new property to an item, 
and selects a property, the interface could check if it exists. If so, there's 
various ways to highlight that this is a possible duplicate:
  
  - the blue outline box could turn to orange;
  - a note could appear on the left underneath the property name: "An entry for 
https://phabricator.wikimedia.org/P569 (Date of birth) already exists for this 
item".
  - the existing lines could "snap down" to be displayed alongside the new line 
for that item

TASK DETAIL
  https://phabricator.wikimedia.org/T134371

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: agray
Cc: Aklapper, Zppix, agray, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T134012: Named Queries

[JanZerebecki]

JanZerebecki added a comment.


  Dedup this ticket with https://phabricator.wikimedia.org/T67626 and 
https://phabricator.wikimedia.org/T132784.

TASK DETAIL
  https://phabricator.wikimedia.org/T134012

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Jonas, daniel, JanZerebecki, Aklapper, D3r1ck01, Izno, Luke081515, 
Wikidata-bugs, aude, fbstj, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T133299: [Task] Replace bogus $ anchor in regular expressions with \z

[gerritbot]

gerritbot added a comment.


  Change 286813 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
  Fix newline injection vector in MediaInfoId validation
  
  https://gerrit.wikimedia.org/r/286813

TASK DETAIL
  https://phabricator.wikimedia.org/T133299

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, gerritbot
Cc: adrianheine, gerritbot, daniel, JanZerebecki, Tobi_WMDE_SW, Aklapper, 
Lydia_Pintscher, thiemowmde, TerraCodes, Lewizho99, Maathavan, D3r1ck01, Izno, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T133470: [Task] Remove outdated message "Wikibase-after-page-move"

[thiemowmde]

thiemowmde added a comment.


  I believe this tickets description is misleading. One can not simply "remove" 
a message. It's shown for a reason and will always be needed for installations 
that do not update the repo automatically when a page on a client is moved.
  
  When I look at the code in `UpdateRepoHookHandlers::doTitleMoveComplete` (see 
https://phabricator.wikimedia.org/diffusion/EWBA/browse/master/client/includes/Hooks/UpdateRepoHookHandlers.php;554ea0e6b343d08dc58de4b0b2dc2096b6abc6af$257
 and 
https://phabricator.wikimedia.org/diffusion/EWBA/browse/master/client/includes/Hooks/MovePageNotice.php;554ea0e6b343d08dc58de4b0b2dc2096b6abc6af$153)
 the message in question will be displayed when the MediaWiki job queue does 
not accept our request. There is not much we can do in this case other than 
telling the user exactly that: please update the Wikidata item manually.
  
  So without a way to reproduce this or an idea how to avoid the situation I 
suggest to close this ticket.

TASK DETAIL
  https://phabricator.wikimedia.org/T133470

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: D3r1ck01, thiemowmde
Cc: thiemowmde, Ricordisamoa, Lydia_Pintscher, gerritbot, TerraCodes, He7d3r, 
GoEThe, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, 
TheDJ, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T133470: [Task] Remove outdated message "Wikibase-after-page-move"

[gerritbot]

gerritbot added a comment.


  Change 286213 abandoned by Thiemo Mättig (WMDE):
  i18n wikibase-after-page-move removed
  
  Reason:
  See https://phabricator.wikimedia.org/T133470.
  
  https://gerrit.wikimedia.org/r/286213

TASK DETAIL
  https://phabricator.wikimedia.org/T133470

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: D3r1ck01, gerritbot
Cc: Ricordisamoa, Lydia_Pintscher, gerritbot, TerraCodes, He7d3r, GoEThe, 
Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, TheDJ, 
Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T133658: [Story] Improve textual representation of query parameters and services

[gerritbot]

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T133658

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Aklapper, Jonas, Avner, Lewizho99, Maathavan, debt, Gehel, 
D3r1ck01, FloNight, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, 
Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs