[10:56:30] New patchset: Hashar; "Wikibase depends on DataValues extension" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/25245 [10:56:41] Change merged: Hashar; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/25245 [11:00:32] So when triggerring 25246 https://gerrit.wikimedia.org/r/25246 there are still a few issues :/ [11:00:33] https://integration.mediawiki.org/ci/job/MediaWiki-Tests-Extensions/941/console [11:00:34] https://integration.mediawiki.org/ci/job/MediaWiki-Tests-API/5998/console [11:00:35] https://integration.mediawiki.org/ci/job/MediaWiki-Tests-Misc/5904/console [11:02:57] wrong window :) [11:46:29] New patchset: Stefan.petrea; "added utf8, pthread_joins, more comments" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/25169 [12:58:53] New review: Diederik; "Hey Stefan, getting real close! Some final issues:" [analytics/webstatscollector] (master); V: 1 C: -1; - https://gerrit.wikimedia.org/r/25169 [14:05:04] Change abandoned: Diederik; "(no reason)" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/2289 [14:19:23] New review: Ottomata; "Aside from my one in line comment in udp-filter.c, looks good!" [analytics/udp-filters] (master); V: 0 C: 0; - https://gerrit.wikimedia.org/r/25195 [14:32:51] hello ? [14:32:59] are there proejcts dealing with the dump of wikipedia ? [14:33:06] I mean Mediawiki::API [14:33:09] hi there average_drifter [14:33:09] uh [14:33:18] hey sumanah , you know me, and I know you :) [14:33:19] tell us about what you're aiming to do [14:33:21] and we can help you do it [14:33:40] sumanah: well, I was just wondering if there are projects involving the dump and if I could contribute to them [14:33:59] * sumanah can't quite recall the face or walletname that corresponds to average_drifter  [14:34:00] sumanah: I've worked with the wikipedia dump before and I could put my knowledge to good use [14:34:55] so, apergos is very interested in having folks help out with the Dumps architecture & features [14:35:10] hey apergos [14:35:21] average_drifter: we should chat [14:35:24] oh, we are :-D [14:35:27] apergos: :D [14:36:55] average_drifter: https://bugzilla.wikimedia.org/buglist.cgi?list_id=148786&resolution=---&query_format=advanced&component=DumpHTML&product=MediaWiki%20extensions [14:42:04] New patchset: Diederik; "Add support for filtering based on referer." [analytics/udp-filters] (master) - https://gerrit.wikimedia.org/r/25195 [14:43:56] average_drifter: hope that's useful [14:46:26] sumanah: thank you ! [14:47:43] oh, yeah I don't touch the dumphtml stuff [14:47:58] so I can't help there but otoh afaik it is needing some love [18:47:21] New review: Diederik; "Ok." [analytics/udp-filters] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/25195 [18:47:21] Change merged: Diederik; [analytics/udp-filters] (master) - https://gerrit.wikimedia.org/r/25195 [19:01:09] New patchset: Stefan.petrea; "added utf8, pthread_joins, more comments" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/25169 [19:04:46] New review: Diederik; "Ok." [analytics/webstatscollector] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/25169 [19:04:46] Change merged: Diederik; [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/25169 [19:22:13] Hmmm. Should we tag extensions into core with submodules when we make branches/tags? :/ [19:22:40] sort of works for extensions we bundle [19:22:50] not so much for the rest of the extensions many people won't want [19:27:42] Reedy: I think we should [19:28:34] I guess with them being submodules, doing a git clone isn't going to just pull all the unwanted extensions... But it might confuse some people [19:30:32] Actually, now that I'm re-reading, maybe not. [19:30:45] I don't want to confuse people [19:31:00] But having them linked, somehow, would be nice.. Not sure the best way to do it [19:31:08] Yeah.. [19:31:17] In SVN we branched off a copy of /trunk/extensions [19:31:27] We've not really put much thought into how to do this on git [19:32:09] I think it would be great if each extension had a branch or tag that worked with each MW version [19:32:28] And then we could (i think ) do some voodoo to pull them in automatcially [19:33:12] But that probably puts too much responsibility on the extension owners [19:33:52] * Reedy closes the bucket of worms, then climbs ontop of it, and jumps up and down to make sure the lid is shut [20:05:37] New patchset: Diederik; "Misc fixes" [analytics/udp-filters] (master) - https://gerrit.wikimedia.org/r/25408 [20:42:38] ^demon, could you also take a look at https://gerrit.wikimedia.org/r/#/c/25268/ ? [20:43:34] <^demon> MaxSem: Tag me to review it, kinda busy at the moment. [20:44:19] ok [20:44:32] thanks [21:40:14] New patchset: Diederik; "Fix build issues" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/25434 [21:41:25] New review: Diederik; "Ok." [analytics/webstatscollector] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/25434 [21:41:26] Change merged: Diederik; [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/25434 [21:45:48] Reedy: would you happen to have any knowledge about how the MW API handles caching? specifically how I might go about overriding it to use different values? [21:46:19] The API doesn't do much caching itself [21:46:42] Squid scaches quite a lot of things, based on parameters, and cache headers then sent by the api [21:46:45] What are you trying to do>? [21:47:15] I'm moving some high usage central notice calls from being in a special page into an API call [21:47:43] the special page sets the CC header by hand... :p [21:49:22] gerrit question: I have a branch off master with one commit that I submitted for `git review`. I've amended that commit locally. Can I do `git review -R` , or must I do `git review -d < change number>` to checkout my own change? [21:50:29] You should just be able to do "git review" to upload the new one [21:50:44] With -R if you want to stop it rebasing against master [21:51:27] Make sure you didn't modify the Change-ID [21:55:45] Krenair, thanks! https://www.mediawiki.org/wiki/Git/Tutorial#Amending_a_change tells you to `git review -d < change number>` , please someone fix it to clarify when this is actually necessary. Maybe "If you want to amend someone else's change..." [21:57:40] spagewmf: it's also good practice in case someone else has modified your change since you last committed [22:00:34] Krenair, I don't know if I want gerrit to "stop it rebasing against master". I want a clean patch 2 without extraneous diffs, but I also want a patch that upon approval will merge cleanly to master. ?? [22:01:15] spagewmf: The git review -d bit is so you can get to the branch, which isn't necessary if you're already there [22:01:22] In some projects at some times it will be clean no matter what you do [22:01:24] spagewmf: So we'll leave it, but maybe make it clearer [22:01:33] But sometimes, you have to rebase [22:01:45] spagewmf: If you want a clean merge, you should upload your patch, then rebase (with the gerrit rebase button if possible) [22:02:06] I suggest always using -R, then rebasing only when you want to [22:05:07] spagewmf: https://www.mediawiki.org/wiki/Git/Tutorial#Amending_a_change should be mildly clearer now [22:05:58] spagewmf: Though it's worth noting that, if you use the git review method, you get any changes others have made since you uploaded the first patchset [22:15:40] `git review -R` on my existing branch worked fine, nobody had modified my change. [22:17:35] But the git message is confusing "* [new branch] HEAD -> refs/publish/master/feature/lognewaccounts". That's exactly what git said the first time I did `git review`. [22:19:44] spagewmf: That is confusing. Upstream bug report, methinks [22:20:04] (I think that's a server response, not a git response)