[00:02:09] ori: starting to get graphite tracking of log event rates now :) -- https://grafana.wikimedia.org/#/dashboard/db/bd808test [00:02:28] nice! [00:02:46] and I already found something to fix -- oauth log verbosity [19:00:09] on #mediawiki: Hi, This is Sanjana Sharma, a 3rd year student from IIIT-Hyderabad. I am interested in contributing in your organisation. Can anybody guide me? [19:00:14] i followed-up, but i have a meeting starting now [19:00:24] would be good if someone answered any follow-up questions, if any [19:29:46] gwicke: can you add aaron to the invite for 12:45? [19:30:33] ori: yup [19:30:56] done [19:31:01] thanks [19:31:04] the BlueJeans thing is open to anybody with the link [19:31:10] if it works, that is [19:33:14] Hey TimStarling. Could you set aside one or more RFC meetings to discuss https://www.mediawiki.org/wiki/Requests_for_comment/Master_%26_slave_datacenter_strategy_for_MediaWiki ? It has been discussed before, but Aaron has made enough progress since then that it would be useful to review the plans and assess where we stand. [19:33:47] It might even make sense to make it a regular item, if time allows. [19:34:14] for the record, the bluejeans webtrc thing doesn't work in Fx, only Chrome (well, it doesn't work in my Iceweasel, but it works in my Chromium) [19:35:15] ori: https://gerrit.wikimedia.org/r/#/c/230698/ [19:35:22] ori: TimStarling isn't awake yet [19:36:14] oh, right [19:37:08] he used to alternate between TimStarling and Tim-away which absolved me from having to remember that Australia exists outside of space-time [19:47:47] AaronSchulz: needs rebase [21:47:22] ori: greg-g legoktm anyone know if we've deployed anything related to logging in? [21:47:25] (e.g. on wikidata) [21:47:47] aude: on test.wikidata yes [21:48:04] might be i need to clear cookies [21:48:15] but on www.wikidata.org, i click login [21:48:31] if possible, enter my info and i am still not logged in [21:48:35] o.O [21:48:41] now i click "login" in the upper right, [21:48:54] get sent to Special:Userlogin [21:49:02] but then it redirects in a second back to the item i was on [21:49:10] and can't even try to login now [21:49:21] it works on firefox [21:50:20] I don't know... [21:54:47] legoktm: cleared my cookies and it works now [21:54:58] not a great solution if others have this problem, though [23:06:34] Hey TimStarling. Could you set aside one or more RFC meetings to discuss https://www.mediawiki.org/wiki/Requests_for_comment/Master_%26_slave_datacenter_strategy_for_MediaWiki ? It has been discussed before, but Aaron has made enough progress since then that it would be useful to review the plans and assess where we stand. [23:06:38] yes [23:07:13] thanks [23:09:00] TimStarling: also, would you consider taking gwicke's html2html binary, making whatever small modifications might be necessary to make it usable as a drop-in replacement for the tidy binary, and shipping that for third-party users and as a fallback to the Java service? [23:09:48] how do you make modifications to a binary? [23:10:12] the problems are the build system and the stability of the API it uses [23:10:39] both of which I would have to deal with if I wanted to rebuild that binary [23:11:00] especially if I wanted to make it officially supported [23:12:02] what is your current plan, then? [23:12:26] you mentioned that the java web service would be your preferred option. what would we ship for third-party users? [23:12:34] java and node, I guess [23:13:30] would the java service be remote or local? [23:14:21] on WMF? that hasn't been discussed on phabricator yet [23:15:03] I think it should probably be local, but that's not a decision that is blocking my work [23:17:06] ok [23:23:01] fwiw, if there is interest I'd be happy to help with the html2html binary or shared library build [23:23:53] I might try hooking up a binary node module first, as that's slightly simpler [23:27:39] you know html5ever already has a C ABI, although it doesn't have a serialization interface [23:28:00] but if you added a serialization interface, they'd probably accept it upstream [23:28:32] it's pretty easy to just export a html2html function [23:29:00] we are only interested in string -> string, and don't really want to mess with DOM access [23:29:39] yeah, you could add that instead [23:29:42] pub extern "C" fn hello(name: *const libc::c_char) { ... } [23:29:45] that's about it [23:30:04] if it was in their tree then it would be less likely to be broken by interface changes [23:30:41] I don't see a strong reason to track their development [23:31:33] I'd just stay with a snapshot as of now, and compile that with stable rust [23:31:56] suit yourself [23:34:26] the issue is that html5ever is under heavy development as part of the servo project [23:35:07] but most of that is irrelevant for us, as we don't need the DOM to integrate with a JS engine & existing C++ codebase