[14:47:33] anomie, i was referring to https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions#Advantages_over_Multipart_Content .. i couldn't remember the name exactly when i typed it. [14:52:22] subbu: Ah, I see. BTW, I still feel like I'm not really understanding your questions there. [14:57:24] anomie, in the middle of something .. will get back on that and clarify. [15:26:04] ... Weird. Adding a comment to a merged change, Gerrit will now allow me to +1 or +2, but not -1 or -2. [15:26:55] that behavior is a bit wonky, because if you had +2'd it and then leave a comment afterwards, jenkins will interpret it as a re+2 and then run all the tests again [15:28:04] it's helpful behavior when a test fails randomly, and instead of deleting / readding your vote, you can just comment something and jenkins will retry [15:32:29] anomie, i'm going to respond on the flow thread later but, quickly .. i think sure, from a consistency PoV, a revision = page + all slots .. i.e. whenever some slot tied to the page is modified, rev id is bumped presumably. But, beyond that consistency requirement, from what I can tell, most disagreements seem ot boil down to what abstraction gets exposed to individual apps, skins, and from there to the end-user browsing the wiki. [15:32:57] if the entire revision is what is exposed to applications, then those apps would hae to deal with the content + all slots (including slots that they don't know anything about). [15:33:41] if it is just page + slots they are responsible for, then the page is not necessarily dealing with the entire revision but only apart of it .. the qn arises how do you deal with any inadvertent dependencies between slots. [15:34:18] i was mostly trying to understand what the application level api is that sits on top of mcr. [15:35:04] and that api is informed my what abstractions it exposes. and what you describe in that last response there on the thread clarify some of that. [15:35:37] subbu: As far as I know, the current plan isn't to allow "applications" or end users to create arbitrary slots. A MediaWiki extension would define a potential slot, for which users or applications could provide content (or ignore). For display, applications and end users would generally deal with HTML from an already-combined ParserOutput. [15:36:18] terminology: i treat SDC as a product / application .. not sure what the accepted term for that is. [15:37:13] right, even if not arbitrary, over time, the desire to exploit mcr and add new slots will be there ... [15:37:37] so, will SDC have to deal with all these new slots that get added? [15:38:33] In that case, what SDC would see is part of what's being argued about. Does SDC control the whole page and by extension what slots are valid for it? Or does it just control its slot (and which pages that slot is valid for) and ignore any other slots, leaving them to their own extensions? [15:39:10] right. [15:41:45] The first suffers from lack of flexibility if two extensions want to do things to the same page. The second suffers from potential for ordering issues or other merge conflicts if two extensions' slot handlers are trying to do something to the same part of the page (e.g. if both want to add their content at the top). [15:41:50] one solution is for sdc to only see its slots, but also declare what other slots it is going to observe modifications for ... so, that if some other extension/production modifies that slot, sdc's handlers would have ot be invoked to ensure there is consistency. would that be a mechanism to resolve this? in the common case, there won't be any observers or listeners. [15:42:06] we were both typing :) [15:44:26] That sounds like some sort of hybrid: SDC controls the page, but tries to support slot handlers for other slots. That seems like it could easily have the drawbacks of both approaches. [15:44:40] i think some trigger / listener / observer (terminology) mechanism might be useful to address the ordering / consistency issues. you still need some consistency model wrt ordering of updates when multiple extensions are interested in the same slot or there are dependenices. [15:44:52] maybe ... [15:46:01] I think it's unlikely that multiple extensions are going to care about the same *slot*. Look at content models now, other than maybe "wikitext" every model I can think of is specific to an extension or feature. [15:47:26] right, i think conflicts and dependencies are likely going to be uncommon, but you need some consistency model or mechanism to handle scenarios where that might pop up .. i.e either reject such extensions .. or provide apis (like the listener api) .. or something like that. [15:47:52] Ok, also "text" and maybe "json", "javascript", and "css". [15:48:48] right. [15:52:05] just to finish thinking aloud about my much earlier thought about exposed abstractions .. from the user-endpoint, i cannot imagine any scenario where the entire revision (main slot + all slots across all extensions) will be relevant (except maybe some admin UI) ... so, i think what end-users will see are product-specific APIs / views of a revision .. in this model, a skin would have to register for the slots it is interested in .. if not, it [15:52:05] gets to only see the default main slot like now (or whatever default m/w core comes up with). [15:52:14] I'm not sure how you'd do a listener for two different extensions prepending HTML or the like, without creating specific operations like "prependHTML". Or what either of the extensions should do when they hear the other trying to do so. [15:53:05] I still think skins seeing slots is crossing too many levels, Revision→ParserOutput→OutputPage→Skin. [15:53:13] ya ... i haven't thought through the details .. that listener mechanism was an idea that popped as i was talking with you here. [15:54:16] anomie, maybe ... but, that to me, seems like an implementation artefact. [15:56:00] Readers probably won't have to care about slots at all. Editors (meaning humans), on the other hand, should be able to edit multiple slots' content at once in most cases. VE might take some extra thought. [15:57:14] perhaps .. reg editing. [15:58:31] For the action API's revision-fetching modules, I plan to let the client specify which slots it wants content for. While action=parse's output for a multi-slot revision will likely work more akin to viewing. [20:39:28] [{exception_id}] {exception_url} MWException from line 332 of /srv/mediawiki/php-1.31.0-wmf.25/includes/jobqueue/JobQueue.php: Got delayed 'cdnPurge' job; delays are not supported. [20:39:31] AaronSchulz: ^^ [20:46:21] maybe related to the jobqueue migration? I'm not working on that project though. [20:47:43] maybe Pchelolo would know [21:20:19] no_justification: just wikitech? https://phabricator.wikimedia.org/T189344 [21:21:32] Reedy: Didn't look that far [21:39:48] [{exception_id}] {exception_url} BadMethodCallException from line 48 of /srv/mediawiki/php-1.31.0-wmf.25/extensions/Thanks/includes/ThanksHooks.php: Call to a member function getUser() on a non-object (null) [21:39:49] Bleh [21:39:52] Somebody broke Thanks [21:41:33] public static function insertThankLink( $rev, &$links, $oldRev = null, User $user ) { [21:41:33] $recipientId = $rev->getUser(); [21:41:58] Also, $user needs to have a default if it's after $oldRev [21:42:28] lol [21:42:45] They haven't been touched in years [21:42:47] *2 years [21:43:22] Well, there's a large spat of them in logstash for wmf.25 [21:43:38] I blame the new commit that calls that function [21:43:38] https://github.com/wikimedia/mediawiki-extensions-Thanks/commit/9f393ef9dd6818be79ff1c57e107341175bfee47 [21:43:58] + $revision = Revision::newFromId( $entry->getAssociatedRevId() ); [21:43:58] + static::insertThankLink( $revision, $links, null, $wgUser ); [21:44:03] newFromId returns null [21:44:09] All same URL [21:44:18] https://gerrit.wikimedia.org/r/#/c/415803/ [21:44:27] Commonswiki [21:45:24] https://commons.wikimedia.org/wiki/File:Natur.jpg.jpg [21:46:11] I bet it has a log entry without a user attached or somesuch [21:46:43] heh [21:46:51] How spammy is it? [21:46:55] Worth reverting that patch out of .25? [21:47:05] 185 hits / 15mins [21:47:58] Seems potentially worthwhile if a bug is filed too [21:49:11] Lemme grab the stacktrace for the bug [21:49:38] https://gerrit.wikimedia.org/r/#/c/419597/ if you want a revert in .25 [21:51:04] https://phabricator.wikimedia.org/T189752 [21:52:10] ThanksHooks::insertThankLink(NULL, NULL, NULL, User) [21:52:13] I wonder what the problem is [21:53:26] Well didn't you say we were getting the user from the $rev [21:54:52] Trying to [21:55:13] $user is the one performing it [21:55:31] $rev->getUser() being getting who made the log entry [21:59:56] no_justification: Shall I unbreak prod? [22:00:08] Go for it, I'm mildly afk at the moment