[17:00:29] Hey there and welcome to the - probably last - office hour before toolserver shutdown! [17:00:55] Who is here? Hi Birgit_WMDE andrewbogott akosiaris Coren ! [17:01:02] Hi everyone! [17:01:04] o/ [17:01:13] \o [17:01:43] Let me introduce our new colleague Birgit_WMDE! [17:02:06] Hi, nice to join you all [17:02:11] As you maybe already know, she is here to work on tech communication with communities. [17:02:35] *\o/* [17:02:40] hello [17:02:46] hi nosy! [17:02:49] hi nosy, welcome [17:03:03] hi Silke_WMDE & Birgit_WMDE [17:03:16] I have started to look at all open bugs that are linked in the tracking bugs. [17:03:54] I propose to go through them with Coren and andrewbogott. I started the list here: https://etherpad.wikimedia.org/p/toolserver_office_hour_20140611 [17:04:22] hello [17:04:27] hi matanya [17:04:43] Welcome Brigit [17:04:49] :) [17:04:53] matanya: are you here with special questions? [17:05:34] Silke_WMDE: i'm just looking to see if i can help in anything [17:05:35] o/ [17:05:49] ok [17:05:52] hi Dispenser [17:06:18] so: https://bugzilla.wikimedia.org/show_bug.cgi?id=56995 [17:07:10] Giftpflanze needs it to be done [17:07:24] how much work is it Coren? [17:07:43] This is one I need help with; it requires building a debian package for it, but I have zero knowledge or skill with tcl [17:08:00] Who could help you? [17:08:08] So I don't really know how a tcl package is built in the first place or how it gets installed "normally" [17:08:29] Does Giftpflanze maybe know? [17:09:27] Anyone who knows both tcl and debian packaging; Giftpflanze is probably the best at tcl but I don't know whether he knows how to do packaging. That said, it might be possible for him to install it locally to his tool -- I know python users often do that when they have specialized needs. [17:10:01] The need for a package is really just to make the tcl fcgi code /globally/ available. [17:10:18] An, afaik, he's the only one with a stated need for it. [17:11:38] so he should try and get it running "locally" [17:11:48] if he manages to install it. [17:12:20] That's certainly the easiest way forward for him. Otherwise, I'll need to learn enough of tcl installation to be able to create a debian package, and that will take some time. [17:12:56] ok. next one: https://bugzilla.wikimedia.org/show_bug.cgi?id=58196 [17:13:04] a sec [17:13:17] yes matanya? [17:13:34] Coren: you know there is a pre build private debs for this right ? [17:13:52] matanya: No, I did not. Pointer? [17:13:58] we can review it, and if good, add to our apt [17:13:59] Is Toolserver software (e.g. rmytop, slayerd, etc.) ported to Tool Labs [17:14:05] e.g https://github.com/nagarajanchinnasamy/tclfcgi [17:14:39] matanya: Then yes, all it'd need is a review; adding it to the tool labs local apt repo is trivial. [17:14:57] matanya: Coren ah, sounds good [17:15:12] (We don't even need to do a full production review; tool labs has its own repo) [17:15:55] So what can I add as a comment to that bug? [17:16:29] build localy [17:16:39] and if needed will create a package [17:16:49] Silke_WMDE: Well, the next step changes from "someone needs to build a package" to "someone could review the existing package for correctness". Once I have an okay from someone who speaks tcl, adding it to the repo is - as I said - trivial. [17:17:06] But building locally remains an option. [17:17:12] good. [17:17:25] next one: https://bugzilla.wikimedia.org/show_bug.cgi?id=58196 [17:17:32] * Coren nods. [17:17:58] Coren: one that seems even easier: https://github.com/toshic/libfcgi/tree/master/debian [17:18:26] (meanwhile Dispenser: Where did we ever talk about that software?) [17:18:35] This one requires final okay from Legal with specification on exactly how anonymisation should be done; then for me to create the view matching that. I know there are significant privacy concerns with this, so I don't expect that can be done in time for the ts shutdown. [17:18:58] :( [17:19:07] Is there a request in to legal already? [17:19:18] But afaik, that view is only useful for occasional stats gathering and no "live" tool depends on it. [17:19:28] andrewbogott: Yes, Luis has been interacting regularily with the bug. [17:19:40] oh, so I see :) [17:20:40] I don't know if any "live" tools depend on it. [17:21:20] None is mentioned in the bug, I think. [17:21:40] but is there any way to speed it up? [17:21:57] There /are/ tools that depend on the so-called "filtered" view, but that one was spun off into bug 64115 and that one has been resolved since. [17:22:10] ah ok [17:22:59] Silke_WMDE: Not really (speed it up); the folk at Legal have limited bandwidth for this and given that this has potentially serious privacy issues they are being extra careful. Like I said, I doubt that can be done before August. [17:23:07] Silke_WMDE: hi [17:23:15] ok Coren [17:23:23] hi sund [17:23:41] netx one: https://bugzilla.wikimedia.org/show_bug.cgi?id=58801 [17:23:59] sund: are you here with a specific question? [17:24:46] I hadn't noticed nosy was done with the copy; all I need to do is to move it to the backups share -- I'll be able to do this this afternoon. [17:25:05] cool thanks [17:25:16] then next: https://bugzilla.wikimedia.org/show_bug.cgi?id=58993 [17:25:54] (I admit that I read that one for the first time today.) [17:26:25] and I don't exactly know what it is about. [17:26:30] Silke_WMDE: I just noticed TS software missing. TS's Slayerd daemon kills programs > 4 GB (memory leaks). The rmytop (and mytop) lists active SQL queries; Toolserver: max_user_connections=15, max_connections=500; Labs: max_user_connections=512; max_connections=2000. And DaB wrote the query-killer script. [17:26:30] That's not tools-labs related; that's just for the API. 59167 was the replication/tool labs half and is complete. [17:27:20] Dispenser: There is no current plan to port/replicate those tools. [17:27:31] Dispenser: probably slayerd could be replaced throug cgroups [17:27:53] slayerd has an equivalent written by Petr that has similar functionality [17:28:33] Coren: Do you know its name? [17:28:36] Coren: for building tclfcgi i would need the tcl header file (=dev package?) [17:28:37] terminatord, I believe [17:28:45] terminatord, iirc [17:29:00] yes gifti [17:29:04] ok. Dispenser, you could check out that tool [17:29:24] gifti: That's simple enough; if you find the name of the dev packages you need it takes me ~60s to add them to -login and -dev. :-) [17:29:50] tcl8.5-dev? [17:30:03] gifti: That one is easy enough; do you know if you need others? [17:30:16] not yet [17:30:28] Coren: in ubuntu it is tcl-dev [17:30:32] gifti: Hit me on IRC after the meeting and I can set this up for you. [17:30:38] ok [17:30:51] coming to https://bugzilla.wikimedia.org/show_bug.cgi?id=58993 [17:31:05] ref: http://packages.ubuntu.com/precise/tcl-dev [17:31:42] Silke_WMDE: Yes, like I said, this is not Labs related at all. [17:31:47] ah ok [17:32:13] so I'm removing the dependency [17:32:42] then: https://bugzilla.wikimedia.org/show_bug.cgi?id=61813 [17:33:22] Silke_WMDE: Unnoticed duplicate of 57697; closing now. [17:33:32] ok [17:33:59] gifti again: https://bugzilla.wikimedia.org/show_bug.cgi?id=62387 [17:34:57] Coren: you promised news on that one [17:34:59] Silke_WMDE: This one just needs a backport; it's not very complicated I just need to set an hour aside for it. [17:35:14] Silke_WMDE: nope [17:35:17] I'll try to get to it tomorrow (commenting) [17:35:24] thanks [17:35:51] i suppose this is not related to migration, right: https://bugzilla.wikimedia.org/show_bug.cgi?id=63243 [17:37:30] seems not [17:37:51] ok, then: https://bugzilla.wikimedia.org/show_bug.cgi?id=52976 [17:40:12] Silke_WMDE: That's rather low on my priority list; it blocks nothing and is needed by nothing - but it's also not a very complicated change so it just always gets delayed for "when I have time". [17:40:57] nosy Any opinion? [17:41:50] the wiki..... where is Reedy? https://bugzilla.wikimedia.org/show_bug.cgi?id=60220 [17:42:18] Silke_WMDE: i'd trust merl there [17:42:55] what is so important about this wiki? [17:43:13] isnt it like keeping the manual of the first car although the car is gone? [17:43:20] nosy: Coren: I mean *I* would just do it for merl because he does so much for the Wikiverse. [17:43:44] nosy LOL [17:43:58] Silke_WMDE: What we discussed in Zürich stands; it's almost certainly never going to be deployed as a production wiki - any historical site will have to be community maintained. [17:44:27] sure Coren - and Reedy offered to transform it into a tool [17:45:53] I think, we'll see how important it is. We won't just delete it, so we can still resurrect it if it stays untouched this month. [17:46:05] the redirect webserver: https://bugzilla.wikimedia.org/show_bug.cgi?id=60238 [17:46:49] there is a patch set by Tim sitting somewhere [17:48:34] Coren andrewbogott: nosy and I were discussing to move the domain at some point in August. [17:49:31] * Coren reads context. [17:49:47] because until then OSM and/or merl might need the Toolserver. [17:50:27] There are different tickets on that topic: apart the one mentioned, there is also https://bugzilla.wikimedia.org/show_bug.cgi?id=66113 [17:51:55] Silke_WMDE: I think this will need a wider discussion than just me an Andrew; I expect we need to open dialogue with Erik to see that Engineering is all on the same page. [17:52:27] Coren: that second one? [17:53:15] Both, really, this involves the "big picture" on how to transition. But then again, this is considerably less urgent than the user-facing tools migration - nobody is going to just yank the server away from the rack come July 31. :-) [17:53:22] Doesn't it cause outages either way? if we move it early, it will precede some tool migrations… if we move it late, users will keep hitting toolserver after it's officially shut down [17:53:50] andrewbogott: Better late with a landing page explaining things than just pull the old server from under tool's feet. [17:54:06] yeah [17:54:07] 301 won't be enough in the mean time ? [17:54:23] Also, I don't think anyone has decided what to do with auxiliary services like mail, etc. [17:54:27] Yeah… I was thinking about a tool having a split-brain when it's running in both places, but I guess that has to be left to the tool owner to figure out [17:54:52] So yeah - we need to open dialogue with Engineering as a whole about how to finalize the transition once the deadline is past for tools. [17:55:24] What can I do for this to happen / to support? [17:57:16] matanya: right now the people choose how to redirect themselves, 301, 302 etc . that will do (https://wiki.toolserver.org/view/.htaccess#.htaccess) [17:57:22] Silke_WMDE: I should think that an email to Erik/Mark with the high-level points outlined should get the discussion started; possibly with resources being assigned. [17:57:32] ok [17:57:48] * Silke_WMDE is adding this to her list [17:58:04] Because there are general guestions to be answered first like "How much do we want to take over, how long to we maintain it, etc." [17:58:22] forever :D [17:58:53] yeah, I'll start a discussion about this. [17:59:37] Silke_WMDE: I think promising "we'll do X forever" in the name of the Foundation is above my pay grade. :-P [17:59:51] :) [17:59:57] That was it as to the bugs on my list. [18:00:10] how is the tileserver in labs? [18:00:48] Silke_WMDE: I hear it's going well though there are some kinks left. I'm probably not the best one to ask, however, as I don't really participate. [18:01:24] sure. nosy said they are in the middle for migrating tools, so it sounds on the right way [18:01:57] Are there any other topics that I'm forgetting right now? [18:02:14] None that I am not also forgetting, at least. :-) [18:02:54] OK. So I'll update the bugs we talked about and did not already update [18:03:21] I'll send that mail we just talked about. [18:03:41] And we're all curiously waiting for the end of the month... [18:03:49] yaah [18:04:00] :) [18:04:51] Thanks for attending Coren andrewbogott Dispenser Birgit_WMDE gifti matanya [18:04:52] thanks for your efforts [18:05:11] My pleasure. [18:05:20] Incidentally: ts svn now at /public/backups/Toolserver/svn/ [18:05:54] Coren: permission denied [18:06:15] haha - I'll leave you! [18:06:17] gifti: I said it's there, not that it was usable. :-) (Fixing now) [18:06:21] ^^ [18:06:23] CU soon! bye! [18:06:41] bye! thanks [18:07:51] gifti: fix't [18:08:26] Coren: now it's permission denied on ls [18:08:51] gifti: Yes, I said fix't too soon, it was still in progress. [18:08:54] gifti: It's done now. [18:08:59] ah, yes :) [19:08:07] anyone following along on IRC? [19:08:21] o/ [19:08:34] :) [19:10:11] is it possible to show this in a quick fiddle or something? [19:12:48] this is cool [19:13:03] MartyH: is that a question for the speaker? [19:13:39] rfarrand, I just dropped in, so I'm not sure what the social convention is here, but yes [19:13:46] OK, will ask [19:14:42] Use jsbin!!! [19:14:47] [19:15:38] a quick fiddle. (like in jsfiddle, or in jsbin) [19:15:40] How will RTL be handled? [19:15:56] for example, will it be possible to auto-flip arrows? [19:16:53] now we usually do forward-arrow-ltr.svg and forward-arrow-rtl.svg and CSSJanus flips it automatically. [19:16:55] aharoni: another way to ask questions: If you are in the hangout you can ask directly! :) [19:23:58] what would happen in text browsing ? [19:24:04] rfarrand: ^ [19:24:16] will ask [19:32:12] violetto, mhurd: how much time do you need? Should I do a time check or are we good? [19:32:30] i need 5min? [19:32:34] rfarrand: ^ [19:34:46] rfarrand: mine will only take a minute or two [19:35:08] thanks mhurd & violetto :) [19:39:26] aharoni: that cat......... [19:39:46] purrrrrrrrrrrrrrrr [19:42:23] >^.,.^< [19:45:58] any qs? [20:54:25] ok, 6 minutes till RfC review here on HTML templating, image quality for mobile, and debugging for production servers [20:55:34] whee [20:57:08] * tfinc grabs his popcorn bucket [20:57:50] <^d> mmm, popcorn. [20:58:41] * aude steals popcorn :) [20:59:06] * brion copies popcorn, creating an infinite energy source and violating the laws of thermodynamics [20:59:30] it's nice to have more opinions on the vendor thing [20:59:49] hi all [20:59:53] Hi Sumana and all ! ... [21:00:00] #startmeeting RfC lightning round | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours [21:00:01] Meeting started Wed Jun 11 21:00:00 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:01] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:01] The meeting name has been set to 'rfc_lightning_round___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' [21:00:06] #chair sumanah brion TimStarling [21:00:06] Current chairs: TimStarling brion sumanah [21:00:08] sumanah: i'm here [21:00:12] #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-11 [21:00:14] great dr0ptp4kt! [21:00:22] Today we're talking about HTML templating, reducing image quality for mobile, and (more briefly) about Debugging at production server and Composer. [21:00:35] First up: HTML templating library. I'll cap this at 20 min [21:00:36] #topic HTML templating library [21:00:44] #link https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library [21:01:02] #link http://lists.wikimedia.org/pipermail/wikitech-l/2014-June/076861.html Gabriel Wicke sent an update to wikitech-l recently [21:01:07] dr0ptp4kt especially: does anyone from Mobile have feedback on the prototype? [21:01:48] and [21:01:48] #link https://www.mediawiki.org/wiki/HTML_content_templating - Anyone have initial thoughts on this? [21:02:04] ( hi Scott_WUaS :-)) [21:02:10] :) [21:02:11] <^d> TimStarling: I think there's a whole lot of talking past one another and trying to decide about 3 things at once. [21:02:19] * brion hmms [21:02:34] sumanah: on the image quality stuff, http://lists.wikimedia.org/pipermail/mobile-l/2014-June/007334.html and http://lists.wikimedia.org/pipermail/mobile-l/2014-June/007333.html capture the latest details [21:02:47] as I said in the mail, HTML templating is very early days [21:02:53] for content [21:03:10] i’m actually quite interested in this [21:03:11] mobile has not tested KnockOff / TAssembly yet, but plans to do so soon [21:03:15] sumanah and gwicke, are we going to focus on templating first in this discussion? that way we don't get too many things going at once. [21:03:25] i just asked jdlrobson to join in on #wikimedia-office here [21:03:27] may be a better way to construct some tables than the traditional wikitext template output [21:03:28] sumanah: we have not scheduled time to give it a spin. Would be worth poking jgonera / maryana / awjr to ensure we schedule some time to do that [21:03:33] so that jdlrobson can speak to templating [21:03:36] dr0ptp4kt: yes, the topic for the next 17 min is templating [21:03:46] cool [21:03:47] dr0ptp4kt: we'll talk about image quality next. [21:03:51] we've been too swamped with tablet redirect [21:03:53] sumanah: thx [21:03:54] brion: yes, especially data-driven tables [21:04:15] we have also been discussing the idea of a data-based table render widget in that context [21:04:19] of course any time we go to HTML we need to be careful to define sanitization rules [21:04:37] (eg, use the same rules as we use on wikitext+html now or extend it, or ....) [21:04:50] yes [21:05:14] one of the longer-term ideas behind KnockOff / TAssembly is that you can sanitize templates in the compiler [21:05:32] nice [21:05:36] and get context-sensitive sanitization of user data in the TAssembly runtime [21:06:20] the split between compiler and TAssembly runtime makes it possible to build different compiler front-ends with different sanitization behavior [21:06:27] * dr0ptp4kt stepping away for 5-10 mins [21:06:37] jdlrobson: ok, I'll mark an action item for you [21:06:40] #action jdlrobson to ask Juliusz, Maryana, Arthur, or similar to schedule time to give KnockOff / TAssembly a spin [21:06:41] one idea we'll look into soonish is compiling existing MediaWiki messages to TAssembly using Parsoid [21:07:27] this would probably also combine well with per-template/module CSS style ability (which I plan to help jdlrobson on moving forward with ideas soon) [21:07:28] but it'll be low prio until we have other things done [21:07:35] for separating data and presentation layers a bit [21:07:59] possibly [21:08:22] gwicke: that (compilation of messages via TAssembly) might be nice for localization that’s shared with the apps too [21:08:56] to set expectations: if we have a prototype before Q3 I'll be positively surprised [21:09:00] eg, for templatizing of UI elements for edit warnings and such [21:09:01] Hi Sumana and Gabriel (gwicke), In looking through this -https://www.mediawiki.org/wiki/HTML_content_templating - I didn't see where inter-lingual template (for Wikipedia's 300 languages) planning is heading. [21:09:12] yeah no rush on that, just thinking it could converge nicely :D [21:10:02] #link http://lists.wikimedia.org/pipermail/wikitech-l/2014-June/076846.html spagewmf talking about MobileFrontend's & Flow's experiences [21:10:25] * dr0ptp4kt back [21:10:38] brion: will be very helpful to have your input on this along the way [21:10:52] Scott_WUaS: Hi. I'm sorry for the misunderstanding, but I believe that is not what we are talking about right now. You're welcome to ask more questions about that in #mediawiki or #mediawiki-i18n [21:11:04] ok thanks ... [21:11:21] (there are different kinds of templates, and I believe you are talking about 1 and we're talking about another) [21:11:54] I was just looking through this - https://www.mediawiki.org/wiki/HTML_content_templating ... do you have a link for related other kinds of templates? [21:12:54] It might be good to aggregate all the various template pages on such main pages as this one -https://www.mediawiki.org/wiki/HTML_content_templating - and other main ones. [21:12:55] #info to set expectations: if we have a prototype before Q3 I'll be positively surprised [21:13:42] Scott_WUaS: Let's talk about that in #mediawiki right now and not here, ok? [21:14:31] sounds good [21:15:08] OK, are there any more questions people have for spagewmf or gwicke or others around Knockout, TAssembly, the RfC, or similar? [21:16:29] (crickets) [21:16:54] ok! [21:17:01] #topic Reducing image quality for mobile [21:17:04] #link https://www.mediawiki.org/wiki/Requests_for_comment/Reducing_image_quality_for_mobile [21:17:11] #info the patchset has been merged into core! yay! [21:17:18] #link http://lists.wikimedia.org/pipermail/mobile-l/2014-May/007176.html Adam Baso said: "The next step we think is to rewrite the tags on a popular page (e.g., http://en.m.wikipedia.org/wiki/Cats) when Wikipedia Zero is in force in order to give this a run in production." [21:17:20] gwicke: have u figured out how to feed template expansion into another template's parameters? [21:17:22] that's dr0ptp4kt [21:17:49] #link http://lists.wikimedia.org/pipermail/mobile-l/2014-June/007275.html Yuri asked: do we use it via JavaScript rewrite or Varnish-based rewrite? [21:18:09] so [21:18:12] sumanah: thanks. all, please see http://lists.wikimedia.org/pipermail/mobile-l/2014-June/007334.html and http://lists.wikimedia.org/pipermail/mobile-l/2014-June/007333.html [21:18:15] awight: in wikitext templates? [21:18:23] my recommendation is to do this either varnish-side or php-side with varnish-side cache splitting [21:19:11] JS replacements are not going to play well with the browser pre-downloading things [21:19:18] right now i would say we're all comfortable with the Wikipedia Zero traffic getting the HTML rewritten to use the lower quality thumbs (regular images never get lower quality'd, though) [21:19:36] gwicke: yes. are you planning to reuse the html templating you're working on now for that purpose? (and maybe we should hop channels) [21:19:51] that is, php-side, keeping the existing varnish fragmentation inherent with Wikipedia Zero [21:19:53] awight: #mediawiki-parsoid? [21:21:10] #info my recommendation is to do this either varnish-side or php-side with varnish-side cache splitting ... JS replacements are not going to play well with the browser pre-downloading things [21:21:17] as for doing thumbnail quality reduction /always/ on mobile web, what do people think about my latest suggestion? that is (1) always reducing thumbnail size, then (2) doing the lazy loading of the higher quality thumbnail as the user nears the thumbnail, at least when the user has a higher-JS capable device [21:21:28] #link http://lists.wikimedia.org/pipermail/mobile-l/2014-June/007334.html [21:21:34] #link http://lists.wikimedia.org/pipermail/mobile-l/2014-June/007333.html on gzipping [21:21:47] dr0ptp4kt: it’s something to consider, especially for retina screens [21:21:57] where balancing size and quality weighs a little differently [21:23:03] probably we should wait for things to shake out on the zero side and then do some qualitative testing [21:23:06] heh... [21:23:11] qualitative testing of the quality ;) [21:23:16] and quantitative testing of the bandwidth savings [21:24:04] dr0ptp4kt: about how long do you think it will take for things to settle down? [21:24:27] brion, agreed. sumanah: we can start with the Cat page probably next week. [21:24:38] then i think the week after that we could expand to a full language [21:24:41] http://en.m.wikipedia.org/wiki/Cats ? [21:24:42] then the week after that all languages [21:25:02] yes, and only if the user is on a Wikipedia Zero network [21:25:09] awwww so many kitties [21:25:18] REDUCED QUALITY kitties [21:25:24] :) [21:25:42] if it causes problems, someone will get the handle ImSadMeow [21:25:49] ok dr0ptp4kt shall we set an action item on this? if so, assign it to whom? [21:26:59] sumanah: yes, you can assign it to yuri and me. [21:27:19] cool. [21:27:27] i’ll make a note on apps backlog to look into it also (after our ios release probably) [21:27:52] action plan: 1. en.m.wikipedia.org/wiki/Cats week one on W0. 2. .m.wikipedia.org week 2 on W0. 3. All .m.wikipedia.org on week 3 on W0. [21:28:24] #action dr0ptp4kt Yuri Astrakhan + Adam Baso: try the Cats page next week, then the week after that expand to a full language, then the week after that all languages. Do qualitative testing of image quality + measure bandwidth savings [21:29:31] dr0ptp4kt: brion - are you ready to say #agreed on the Varnish/JS question? [21:30:16] sumanah: yep [21:30:25] go ahead [21:30:39] #agreed PHP-side modification for low-qual images on zero, splitting cache in Varnish. JS not suitable [21:31:08] and it's thumbnails, specifically. no mucking with the regular images atm. [21:31:12] (if ever) [21:31:37] (maybe someday it could be an option for the user if the user wants to save bandwidth there, too, but let's see how thumbs go) [21:32:22] yep [21:32:25] #idea maybe someday we could also change original/regular images, not just thumbnails, if the user wants to save bandwidth there, too, but let's see how thumbs go first. - Adam [21:32:49] ok, sounds like we are ready to move on but I'll wait 30 more seconds on this topic [21:32:58] yurikR: any unanswered questions? [21:33:30] TimStarling I presume you're good with this [21:33:54] I guess so -- is there an ops liason for this? [21:34:01] 'lo [21:34:12] presumably there will be some extra server load as the thumbnails are regenerated [21:34:19] ori: logs till now: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140611.txt starting at 21:00 [21:34:26] thanks [21:34:49] i just confirmed with yurikR he's comfortable with action plan [21:34:57] dr0ptp4kt: who is the Ops liaison for this? [21:35:09] #info Yuri is comfortable with this action plan [21:35:31] sumanah TimStarling - i would recommend we liaise with bblack, as he's our normal point of contact on w0 stuff [21:36:02] yes, sounds good [21:36:21] #action dr0ptp4kt to check in with Brandon Black and either have him as Ops liaison for this project or find someone else :-) [21:36:49] ok, anything else, or shall we move on to #topic Debugging at production server? [21:37:17] * sumanah waits 20 more seconds or so :) [21:37:45] #topic Debugging at production server [21:37:54] #link https://www.mediawiki.org/wiki/Requests_for_comment/Debugging_at_production_server [21:38:14] #info This RfC is by devunt. I asked devunt to be here but I didn't give him/her enough notice, sorry [21:38:20] #info "Problem: Sometimes we have to debug on production wiki, but don't want to show internal information to normal users... But the current architecture of debugging toolbar is available for everyone, so some internal information, like the server's directory structure, debug logs, and so on, can be leaked." [21:38:35] greg-g: chrismcmahon I'd especially like your opinion on this one. [21:38:40] #info Proposal: change things so that only selected users can use the debugging toolbar, and implement this using user rights. [21:38:55] #link https://gerrit.wikimedia.org/r/#/c/119002/ is the patch [21:39:46] how does one enable/see the toolbar now? [21:39:52] <^d> Enable it in settings for all users. [21:39:55] <^d> Or none (default) [21:40:07] <^d> $wgDebugToolbar I believe is the name. [21:40:09] hmmmm, yeah being able to restrict that to certain users migh t b e handy [21:40:26] is this something that's most applicable to non-WMF wikis? [21:40:36] <^d> I think we could definitely use it on beta. [21:40:41] <^d> I've wanted it before. [21:40:48] tell the truth i’d LOVE to be able to turn that on in wmf land too, or near-equivalent [21:40:50] yeah :) [21:41:00] I wonder what the most sensitive private data in the debug logs is [21:41:02] #info at least some people are interested in turning this on in WMF land, such as beta [21:41:06] csteipp: ^ thoughts? [21:41:09] i.e. how well does it need to be protected? [21:41:29] I mean for the main site [21:41:35] well, just a reminder, we still want to protect user ips/etc in beta cluster :/ [21:41:44] i dunno if something might be exposable in user-to-user communications [21:41:51] or if background job processing happens [21:41:53] it's probably going to get lumped into the big pile of mess that is NDA signing/tracking [21:42:03] sumanah: I've never used much less heard of the debugging toolbar, I'm here for the background. having something like this in beta labs would be handy. [21:42:34] <^d> If we made this depend on the structured logging stuff we might be a little more confident about turning it on in WMF land. [21:42:46] <^d> Presumably it'd be easy to mark a log as private at that point. [21:43:01] (continuing my thought) .. unless it doesn't show PII? [21:43:06] http://www.mediawiki.org/wiki/Debugging_toolbar <- for those not familiar with the feature [21:43:16] obviously we don't use $wgJobRunRate on WMF [21:43:16] #link http://www.mediawiki.org/wiki/Debugging_toolbar <- for those not familiar with the feature [21:43:28] <^d> TimStarling: Yeah, so jobs aren't a worry. [21:43:29] do exception backtraces appear in the logs? [21:43:39] I would worry about things like redis passwords [21:43:50] We could assign devunt to look into how to do this in a way that respects what we're trying to protect https://www.mediawiki.org/wiki/Security_for_developers/Architecture#What_are_we_trying_to_protect.3F [21:44:16] <^d> TimStarling: I'm also a bit leery about something like Special:CheckUser. User's name/IP might end up in debug messages easily. [21:44:27] <^d> Easily checked, but still. We've got a lot of extensions. [21:45:00] yeah, it would be a medium for data release that developers were not expecting [21:45:16] so there's potentially a lot of ways for things to go wrong [21:45:29] <^d> So, back to my earlier point. Could we make this depend on structured logging? [21:45:30] (Chris is now reading the backscroll :-) ) [21:45:55] not sure how structured logging helps... [21:46:24] <^d> Maybe if we had a way to flag a log as private or not. [21:46:26] <^d> Just a thought. [21:47:12] doesn't seem to be in the RfC for structured logging [21:47:38] and I think Bryan is unavailable to talk right now [21:47:51] yeah, he's on the beach [21:47:55] <^d> Fair enough, I just wanted to mention it as a possible way around the private data issue. [21:47:55] Yeah, I would worry about things like redis/db passwords showing up... but I'd have to look at it a little more [21:48:17] well, we have a private flag in wfDebugLog() [21:48:34] not sure how much it helps [21:48:39] csteipp: in my opinion that can wait - let's give https://www.mediawiki.org/wiki/Security_for_developers/Architecture#What_are_we_trying_to_protect.3F to devunt and ask him/her to draw The Data Flow Diagram or otherwise project-manage this [21:48:53] <^d> today I learned we have a private flag in wfDebugLog(). [21:49:05] I don't think you need to proactively look into this and push your other 4 full-time jobs aside ;-) right now [21:49:09] <^d> So to summarize because I think we're all on the same page here. [21:49:30] yeah, so ask yourself: if someone else had introduced structured logging, and they added a private flag, would you know about that and use it? [21:49:30] <^d> I think we like the idea in theory of making the debug log available to trusted users (especially on beta) [21:49:32] ^d: TimStarling that isn't mentioned in the structured logging RfC, is that needed there? [21:49:34] <^d> But we have to worry about private data. [21:49:54] <^d> TimStarling: Not necessarily, but I hadn't thought about it until today :p [21:50:03] greg-g: maybe [21:50:18] TimStarling: I'll bug bryan about it when he's back [21:50:54] #action greg-g to ask Bryan about how whether structured logging is a way around the private data issue for this RfC [21:51:26] #info Yeah, I would worry about things like redis/db passwords showing up... but I'd have to look at it a little more [21:51:35] it'd probably only be part of a solution, honestly [21:51:53] even if structured logging was perfect in segmenting out private/non-private [21:52:27] <^d> I think devunt's approach is fine for core, if not sufficient for WMF. [21:53:30] ok, so, this caused more interest than I expected [21:54:06] is there anything else people want to say here? I'll be pasting the summary onto the RfC talk page. [21:54:57] #action devunt to review https://www.mediawiki.org/wiki/Security_for_developers/Architecture#What_are_we_trying_to_protect.3F and draw a data flow diagram https://www.mediawiki.org/wiki/Security_for_developers/Architecture#Threat_Modeling and reach out to Chris Steipp once that's done [21:55:00] I think that covers the preliminary points until we get a better idea on the data flow [21:55:03] +1. Now that I've read the rfc, I do like it in concept for core. I'll think more about it for wmf.. [21:55:56]