[01:23:53] so i'm looking into how to speed up some post-upload processing for an extension i'm working on. i've found a way that might decrease the processing time needed by over 50% (from roughly 30 seconds to 10-15 seconds), but it requires using multiple cpu cores. would it be possible to use multiple cores on the server that the file is uploaded to? [01:26:00] the speed increase seems like it'd be directly proportional to the number of cores the processing was divided among. (my laptop is dual core, thus the ~2X speed increase) [01:29:30] (the processing is ray-tracing a 3d model) [01:33:41] hey hashar [01:33:52] hello :-D [01:34:03] I am in SF this week! [01:34:20] It took you a journey the other half of the world for us to be online at the same time, eventhough we live in the same timezone xD [01:34:37] so true! [01:35:34] hashar: What're you working on this week [01:36:48] Making everything public [01:36:56] http://cdn.memegenerator.net/instances/400x/20168942.jpg [01:37:06] hehe [01:37:26] we are working on replicating the production cluster onto labs instances [01:37:39] Aha [01:37:48] making beta-labs more like the real cluster [01:38:37] hashar: puppetizing cluster behavior? If so, that'd be nice for production in general as well. [01:38:47] that is the idea [01:38:50] assuming the same puppet can than be used for both [01:38:54] then* [01:39:05] get most of what is not yet public to be public so we can reuse it on labs [01:39:07] (different branch maybe) [01:39:11] Emw: good luck, sorry I do not know how to help [01:39:12] yeah [01:39:14] nice :) [01:39:24] Emw: I do not know whether MediaWiki knows about multicore at all [01:48:44] sumanah: thanks for the feedback in any case. the program i'm calling seems like it could manage the multicore aspect of the task, so it might conveniently not depend on mediawiki's support there. [01:48:56] ah good! [02:10:50] I should book travel related things for Berlin.. (Though, nothing about hotels yet..) [02:11:47] Reedy: hotel is arranged by WMF for us [02:11:54] i know [02:11:59] Reedy: ask Laura / Mariel to book a plane for ya :-D [02:12:04] I'm driving again :p [02:12:07] But I've not had any confirmation of when I've got a room [02:12:17] driving from UK to Berlin through the channel ? [02:12:18] I've got to book a halfway hotel (probably), and a channel crossing [02:12:24] Under or over [02:12:33] why don't you take plane ? [02:13:26] I enjoyed the drive :p [02:22:15] Reedy: I know Rachel's working remotely again in case you need to chat about the hotel stuff [02:22:27] She was in the office today :p [02:22:38] OK, remove "remotely" then [02:22:50] heh [02:22:54] I meant I knew she was working [02:22:59] I just need someone to confirm dates etc [02:23:04] you've asked her? [02:23:10] No, I didn't even think to [02:23:22] she responds to email [02:23:24] I presumed (hoped?) things might've been somewhat confirmed now [02:23:35] go ahead & ask [02:24:21] if you actually want me to spend a few kilobytes explaining why some things have been settled and others haven't etc etc etc then just say so and I will [02:24:33] otherwise, just email Rachel & cc Mariel & Laura, and ask [02:28:38] Hmm yeah this is somewhat scary for me too I guess [02:29:16] My inbound flight is a week ahead of the conference to the travel people don't actually know when I arrive in Berlin until they ask me, which they haven't done yet [02:29:37] If I had had an inbound flight booked directly into Berlin then I could be confident they'd arrange matching hotel dates [02:29:54] So go ahead and email them to inform them of the relevant info? [02:30:04] Yeah, will probably do that at some point [02:30:09] Sooner's better [02:45:41] hi pranavrc [02:47:01] https://www.mediawiki.org/wiki/Git/aliases is getting fuller [02:47:05] good stuff [15:39:11] Hi everyone. There's a Meta and mediawiki.org translation tools bug triage at 16:00 UTC in #mediawiki-i18n. That's in about 20 minutes. [15:40:16] oh [15:40:21] what should I expect? [15:40:27] * ToAruShiroiNeko braces for impact [15:40:46] wait my chair has wheels, bracing it is kind of pointless :( [15:43:23] * guillom tosses ToAruShiroiNeko out the nearest airlock. [16:03:01] Hi everyone. There's a Meta and mediawiki.org translation tools bug triage now in #mediawiki-i18n. [16:10:52] guillom haha :D [17:10:52] hola [17:13:47] Nikerabbit: do you want to play irc ping pong. table seems clear [17:14:02] Nikerabbit: ping [17:14:15] planemad: ong [17:14:27] Nikerabbit: where's the p? [17:14:32] packet loss [17:14:36] haha [17:14:55] hahahaha [17:15:10] planemad: are you going to attend our 20% checkin meeting? [17:15:24] i dont know what that means. but when is it? [17:15:34] planemad: in two minutes [17:15:35] hi there planemad [17:15:42] sumanah: hola :) [17:15:43] planemad: https://www.mediawiki.org/wiki/Wikimedia_engineering_20%25_policy [17:17:13] Nikerabbit: anything you want to chat about? [17:17:28] planemad: you & your team decide what your "20% day" is going to be, basically [17:17:36] hmm, its on webex or here? [17:18:07] planemad: just here [17:18:39] i'll be around. working on some things by the side [17:18:43] sumanah: well... a bit [17:19:10] sumanah: basically I'm still unsatisfied with Gerrit, but anyway I've did multiple hours of code review this morning and during the week [17:19:21] Thank you [17:19:43] having looked at random patches, I wish for "Fix (trailing) whitespace" button [17:20:10] Nikerabbit: is that already a request in the Gerrit bugtracker? [17:20:23] sumanah: dunno, I filed one in our bug tracker [17:20:42] ^demon: ^ can you take a look at this, at Nikerabbit's request? [17:20:45] https://bugzilla.wikimedia.org/show_bug.cgi?id=36169 [17:20:53] sumanah: ^demon knows :) [17:20:56] ok. [17:21:02] never mind, then, ^demon [17:21:31] besides, I have much more urgent wishes for ^demon, so let him concentrate on those [17:21:34] planemad: ok, talk with your team and possibly with Alolita & figure out what your 20% checkin day should be. Thanks [17:21:42] <^demon> So many pings.... [17:21:48] sorry Chad. [17:21:49] <^demon> No wonder I'm going insane. [17:21:50] <^demon> :) [17:21:53] but basically there is enough code to be reviewed at any moment [17:21:57] True. [17:22:00] OK, thank you Nikerabbit [17:22:02] <^demon> I decided this morning I've gone completely insane. [17:22:10] <^demon> Just tossed my last shreds of sanity out the window. [17:22:22] ^demon: ready for party? [17:22:24] Just in time for graduation! [17:26:22] ok, that's it for the 20% checkin today, thanks! [17:26:27] thx [17:29:26] am back [17:29:30] so, i think i missed the main part [17:29:49] Nikerabbit: what would be a checkin for an interaction designer? [17:43:48] There isn't a lot, arun. [17:55:49] jorm: hi! [17:56:59] jorm: what do you do for the checkin? [17:57:14] i don't. [17:57:32] ah :) [17:57:39] we kind of do our own thing, as needed. [17:57:45] correct [17:57:57] there is 20% code to review that gets tagged as "design" every now and then, but that usually falls into my bucket. [17:58:31] if you're not doing really coding, or don't know it, or whatever, i think that - especially with interaction designers - code review is probably a waste of your time. [17:58:37] however, there are other things you can do. [17:59:16] we have been doing the Design Cabal meetings, which I think are poorly timed for you (they're at noon, PST). [17:59:25] and we review each other's design work. [17:59:53] yup, peer review will be very useful [18:00:11] that's like, 12:30 your time, I think. [18:00:35] its not bad, i'll make it next week [18:00:38] i'm trying to get the list to be more useful; i saw you suggestions for the watchlist but I haven't had a chance to look them over. [18:00:43] okay. you want an invite? [18:00:51] we skype in pau. [18:00:57] and the rest of us eat lunch. [18:00:57] yes please [18:01:04] what email? [18:01:16] aganesh@wikimedia [18:02:03] done. [18:02:09] i'll need your skype handle. [18:02:20] arungraphy [18:02:33] awesome, never been part of a cabal before [18:02:52] heh. [18:03:24] Gotta get 'em all. [18:06:24] <^demon> jorm: Could you come up with 3 colors that go together nicely? I [18:06:29] <^demon> 'm trying to reskin gerrit. [18:06:33] of course. [18:06:44] context? [18:06:47] <^demon> http://gerrit-dev.wmflabs.org/r/#/q/status:merged,n,z - the three main colors are the white-ish background, the blue highlights, and the green boxes. [18:06:56] <^demon> And we can change the black text, if wanted. [18:07:25] would that also go on this: https://gerrit.wikimedia.org/r/#/c/4549/ [18:07:33] <^demon> Yep, that's just my testbed :) [18:08:43] <^demon> I was shooting for something that was reminiscent of Vector color-wise, but I'm open to anything that looks better than puke green/yellow :) [18:08:53] sure. gimme a few seconds. [18:08:57] <^demon> Thanks! [18:09:06] we really only have one major color, and then a highlight? [18:09:14] <^demon> Yeah, plus the background. [18:09:45] <^demon> http://gerrit-dev.wmflabs.org/r/Documentation/config-gerrit.html#_a_id_theme_a_section_theme - here's all the color options, if that's useful to you [18:09:55] <^demon> I think you can change the trim/topMenu separately from one another [18:15:39] ^demon: email? [18:15:57] <^demon> chad@wikimedia.org [18:16:17] k. if you want to email me a copy of that config, i can just inject the colors for you. [18:16:24] but i'm mailing you the two major elements now. [18:16:55] puke green 4ever [18:18:18] i don't know if this is going to make people puke any less, but we can play with it. [18:18:21] <^demon> Restarting gerrit-dev. [18:21:16] <^demon> Whooooops. [18:21:17] <^demon> Typo [18:21:22] <^demon> http://gerrit-dev.wmflabs.org/r/#/q/status:open,n,z ;-) [18:21:53] OMAHGAWD MAH EYEZ [18:22:06] ponies please [18:22:21] wow. [18:22:24] <^demon> Restarting again...give it a moment.... [18:22:43] i would be okay with a my little pony or hello kitty themed code review tool. [18:22:44] <^demon> That pink is actually FA0DAC instead of 5A0DAC ;-) [18:22:55] yeah. heh. [18:23:34] <^demon> Ok, got the new colors on. [18:23:46] <^demon> Text is hard to read though :\ [18:24:55] right. we'll have to fix that. [18:25:05] that's what i meant by "send me the config, and i'll just put the colors in" [18:25:17] <^demon> One moment. [18:25:48] wait. holy shit. [18:25:54] it looks like you can't change text colors. [18:26:09] i'll look for the config itself, but if so, then we need different ones entirely. [18:26:19] gah. so sick of pastels. [18:26:41] <^demon> Sent. [18:29:08] k. gimme a few. [18:29:20] <^demon> Sure, no rush. [18:36:53] <^demon> jorm: New colors are up. http://gerrit-dev.wmflabs.org/r/#/q/status:merged,n,z nicely shows all of them together. [18:37:13] hrm. still not happy with the menu color. [18:37:13] ^demon: I don't like the white background [18:37:28] <^demon> It's not white, it's off-white :) [18:37:37] <^demon> #F3F3F3 :) [18:37:42] well. we can't change text colors overall. we can change *one* color, and that will goof everything else. [18:38:26] <^demon> Yeah. The site CSS is kind of wonky right now so I was trying to make due just with the theming. [18:38:27] ^demon: just kill the topMenuColor line. [18:38:52] I used to think that gerrit couldn't get any uglier… ^demon has proven me wrong. [18:39:15] <^demon> Hey, these aren't my colors. I asked jorm for help to get rid of the green/yellow :) [18:39:36] it's not very flexible. [18:39:56] <^demon> No, it's not. Maybe we should just abandon this until we can do some more legit CSS work on it [18:40:05] agreed. [18:40:16] <^demon> Thanks anyway for trying :) [18:40:35] those first colors would have been great if we could goof with font colors but so it goes. [18:40:44] everything has to drop to shitty pastel versions. [18:41:03] <^demon> Right now the big flaw in gerrit is customized CSS is included before site CSS, so you have to throw !important on everything for it to work. [18:41:07] <^demon> Those should be reverised :) [18:41:14] <^demon> reversed, even [18:41:30] I filed a bug for that [18:41:35] <^demon> I know. [18:41:47] <^demon> Maybe I could dig into that. I can't imagine it's *hard* [18:41:54] Y U NO MAKE GERRIT PRETTEH? [18:42:02] ^demon: Famous last words [18:42:20] <^demon> jorm: We actually ended up with the school colors for my middle school. [18:42:23] <^demon> Purple and gold :p [18:42:27] hah! [18:42:40] my middle school colors were blue and silver. [18:42:49] and in high school they were red, white, and blue. [18:43:02] I went to a school uniform which was purple and yellow/gold also... [18:43:06] *which uniform [18:44:13] <^demon> Does anyone know a switch for ack that excludes binary files? [18:46:28] ^demon: Doesn't --nobinary work? [18:46:49] <^demon> Nope [18:47:28] <^demon> I guess I'll just tweak my .ackrc to exclude .class files. Going through the gerrit source is a pain :) [18:47:46] Does ack-grep --java work [18:47:48] ? [18:48:52] <^demon> I think my .ackrc of doing -a is overriding it. [18:48:54] <^demon> Which is stupid. [18:50:03] <^demon> Hmm, -a and --no[type] seem to be mutually exclusive. -a overrides any other switches. [18:51:12] boo [19:06:53] c~~p ,---------. [19:06:53] ,---'oo ) \ [19:06:53] ( O O )/ [19:06:53] `=^=' / [19:06:53] \ , . / [19:06:55] \\ |-----'| / [19:06:58] ||__| |_|__| [19:08:06] Is it hungry? [19:08:43] om nom nom [19:10:47] you awoke the predator! [19:10:47] blackman: fight the power [19:10:48] i knew today would be a good day [19:10:55] yay our troll is back! [19:10:59] XD [19:11:09] blackman: don't let them keep you down [19:11:21] <^demon> RoanKattouw: I think GerritSite.css is included properly on the gitweb side :) [19:11:24] Ryan_Lane: let's go on a picnic [19:11:33] hell yeah [19:13:18] blackman: your trolling is really letting me down [19:13:24] could you troll harder? [19:15:04] http://zipmeme.com/uploads/generated/g1332726385297172262.jpg [19:15:49] blackman: the troll is coming FROM INSIDE THE WIKIMEDIA FOUNDATION [19:17:54] notpeter: OH N O U DIDN'T [19:25:09] TrevorParscal: ping [19:25:53] he's eating his lunch [19:26:32] k [19:42:06] gwicke: howdy! [19:42:16] hi Trevor! [19:42:42] I was wondering about the elements currently supported in the editor UI, but just got a list from Christian on Skype [19:43:46] looks fairly doable for the parser side, especially without manual source editing [19:48:07] Krinkle: Ohai! [19:48:13] hey [19:48:36] I worked early today, sorry forgot to notify you... [19:48:38] What have you been working on today [19:48:40] No worries [19:48:46] I started late and forgot to notify you too [19:48:51] Mostly because I decided this at like 4am [19:48:59] yeah I left around 6pm my time [19:49:15] Yeah [19:49:17] (an hour after we were scheduled to start) [19:49:22] I think I was getting out of bed right around then [19:49:32] Anyway, I'm only starting to do RL2 stuff [19:49:44] I've been reviewing your commits and working on integrating my local style-position branch with the new master that came from those merges. [19:49:52] Our 10-minute VE standup kind of took >30, and I had to do some CR [19:49:52] I'll finish up tonight, [19:50:06] Your local branch = style-position in the UI? [19:50:10] <^demon> RoanKattouw: http://code.google.com/p/gerrit/source/browse/gerrit-httpd/src/main/java/com/google/gerrit/httpd/raw/HostPageServlet.java - this is where your custom CSS is injected. Ctrl+F for injectCssFile. [19:50:21] <^demon> Dunno how the other part gets injected at the end of the yet. [19:50:50] ^demon: Yeah you'd need to find the built-in CSS too [19:50:59] <^demon> I'm still looking :\ [19:51:22] Krinkle: I've got a patch ready that'll make the shared gadgets tab behave the way it should [19:51:25] gerrit is java? [19:51:56] yus [19:52:01] wow. [19:52:08] this is. . . totally the wrong way to go about doing this. [19:52:16] RoanKattouw: yeah, UI [19:52:23] RoanKattouw: k [19:53:01] well. it's not like we can port it to a framework and use jsps, i guess. [19:54:04] Krinkle: i.e. display per-category as opposed to per-repo-per-category, and merge cats with the same display name [19:54:30] RoanKattouw: nice [19:54:30] Krinkle: Did we figure out whether we want to also include local gadgets in this and have just one Gadgets tab, or do we want to keep the local/foreign separation? [19:54:47] RoanKattouw: Good question... I think for now we should keep them separate [19:54:55] OK [19:55:17] until Gadgets 3.0 is on the horizon (see my proposal) I expect a few gadgets that will only have a dependency on a global gadget and set default:true [19:55:27] which would ideally have the same name so that preferences clash [19:55:30] yeah, ugly like that :P [19:55:39] and likewise stuff moving from local to global [19:57:34] <^demon> RoanKattouw: What if we moved the style inclusion below the body? That'd be very trivial, actually. [19:57:56] Does that work / validate? [19:58:01] Oh, awit [19:58:03] No, you can't do that [19:58:06] FOUC [19:58:18] <^demon> FOUC? [19:58:33] https://en.wikipedia.org/wiki/FOUC [19:59:24] If you include the styles outside of the , the browser will render the page without the styles, then encounter the styles, then rerender everything with the proper style [19:59:32] <^demon> yuck. [19:59:50] BRB [19:59:58] <^demon> Wouldn't it style based on the head, then restyle based on the ones outside the head? [20:00:06] Yes, it would [20:00:13] <^demon> Ugh. [20:00:13] Oh, you want to move /custom/ styles, right [20:00:16] <^demon> Yeah [20:00:38] So then you wouldn't get the FOUC from hell (completely unstyled page), but still a FOUC [20:00:47] gwicke: re: manual source editing - theoretically later on we could round trip through the parser as a pre-save transformation step, which would enforce any normalization that would normally be applied to a visually edited document [20:01:34] yeah, full normalization sounds very convenient [20:01:58] it is very risky though, as everything needs to work 100% right at the start [20:02:45] we also need to support diffs between old and new revisions [20:18:23] Krinkle: https://gerrit.wikimedia.org/r/7085 [20:18:45] (note that it will probably conflict with https://gerrit.wikimedia.org/r/5871 ) [20:39:29] anyone familiar with WMF profiling system? what sampling rate does it use? [20:40:05] <^demon> MaxSem: Whatever's defined in http://noc.wikimedia.org/conf/highlight.php?file=StartProfiler.php [20:42:04] hm,, 1/50th [20:47:27] MaxSem: I was just complaining about that earlier [20:47:28] meh [20:47:45] AaronSchulz, too high/too low? [20:48:17] I'd would be nice to sample a tad more, though I guess it's a matter of udp traffic and collector CPU [20:48:53] also, what time period is used here http://noc.wikimedia.org/cgi-bin/report.py ? [20:52:22] since the collector or started, or was sent an explicit flush (generally a long time) [20:54:34] heh [20:55:19] N calls per random period of time is nice [21:59:04] Krinkle: quint's expect does not appear to be accumulative [21:59:06] which sucks [21:59:09] any thoughts? [21:59:13] qunit [21:59:31] TrevorParscal: there is an open bug for that, bug there is some controversy about it [21:59:42] Reedy, yes *qunit [21:59:47] hmm [21:59:54] status quo so far: Use if if you know it ahead of time, if you don't know it, don't use expect(), defauts the purpose of expect() [21:59:56] I was like wtf is quint [21:59:57] defeats* [21:59:59] expect() and expectMore() maybe? [22:00:03] ist is not required [22:00:26] yeah, but I prefer to use it [22:00:37] You can't know the number of tests ahead of time [22:00:38] ? [22:00:39] and part of what I'm doing is much better if I have it [22:00:48] elaborate please :) [22:00:50] I can, I just don't want to have to add them all up manually [22:01:16] i have a function that checks 2 data structures in a special way, because deepEqual does some evil things I need to avoid [22:01:40] TrevorParscal: note that it doesn't have to be at the top of test() [22:01:44] you can call expect afterwards [22:01:45] the number of assertions this function uses depends on the size of the data structure [22:01:47] maybe thathelps [22:01:53] within the test callback [22:02:10] still clunky, but possible [22:02:22] After the callback is executed, the 'test.finish' hook runs, there the expected runs are asserted [22:02:55] do we have expect in PHPUnit btw? I don't see it used anywhere [22:03:00] PHP is less dynamic though.. [22:03:09] not as fragile, in different ways atleast [22:05:23] TrevorParscal: If you are testing whatever number of properties there are (or some other variable that is not controlled by the test), maybe you don't have to use expect()? [22:05:34] sounds a little bit like ensuring that 1+1=2 [22:06:27] no, cause actual might not return the same number of items [22:06:41] as expected [22:06:54] i could rework it [22:07:07] it may show a flaw in my strategy - that's what you are getting at [22:07:28] I was just bummed cause it seems like expect() should be accumulative [22:07:43] RoanKattow: just added first of two very large commits for review https://gerrit.wikimedia.org/r/#/c/7119/ (this one's the central feedback page, which includes some sql i'd like your opinion on, because i'm not certain about it) [22:08:20] rsterbin: That's not for tomorrow, is it? [22:08:26] yup [22:08:40] TrevorParscal: https://github.com/jquery/qunit/pull/227 https://github.com/jquery/qunit/issues/226 are still open - if you feel like it, feel free to add your arguments :) [22:08:45] there's another one, too -- the redesign [22:09:08] i wish i could have put them in earlier... :-P [22:09:33] I will not be able to review those in time [22:09:57] If things are submitted on Wednesday afternoon, I can't deploy them on Thursday morning, esp. if it's SQL which now has to go through our DBA [22:10:01] Fabrice can blame me if he likes [22:10:51] rsterbin: OK, so you're adding global counts as page_id zero? [22:11:04] yeah [22:11:12] Took me a while to spot that, you might want to clarify that with a comment in filter_count.sql [22:11:15] ok [22:11:51] "logging.log_title LIKE CONCAT('ArticleFeedbackv5/%/', af_id)" [22:11:53] eww [22:11:54] What's that for? [22:12:15] yeeeah [22:12:21] hehehe [22:12:36] that's for making the view activity link turn gray when there's no activity [22:13:19] matthias had it subbing in the page name, but we don't have that on the central page [22:13:35] How does it accomplish that? Instead of encoding the title, it allows any title for that feedback ID [22:13:38] and % with the id will always be correct [22:13:45] Which is weird because from a feedback ID you know the title [22:13:57] true [22:14:33] i'm not actually sure why it was in the log title in the first place [22:14:50] It sounds unnecessary to include both the title and the af_id maybe, but WHERE foo = bar is much more efficient than WHERE foo LIKE 'bar%baz' [22:15:22] would be cool if we have the title, but we don't during that phase [22:15:39] How is it that that code magically no longer has it? It had it before [22:15:58] we have the title during fetch for single article feedback pages [22:16:23] the central feedback page has lots of titles, but we don't know what they are until we fetch them. ;) [22:17:52] Hmm, Ok [22:17:54] Well [22:18:11] You're doing two queries, one to get the af_ids and one to get everything else [22:18:29] You could move the page join into the first query [22:18:45] then you'd have the titles when compiling the second query [22:18:49] or well crap, you'll have multiple titles [22:19:48] yep [22:20:28] Hmm OK [22:21:28] Well you'd have to use multiple queries for getting the metadata, one for each page_id. That's not ideal (ideally it'd be one query) but it's better than a LIKE 'foo%bar' for sure [22:22:05] then we'd have to do separate fetches for the log info, too [22:22:43] Ah, when I said metadata I think I meant log info [22:23:02] the log info is per feedback [22:23:26] Well you could still have the old logging.log_title = CONCAT('ArticleFeedbackv5/" . $dbr->strencode($title) . "/', af_id) thing there [22:23:32] I guess [22:23:51] so... get the feedback ids, each with page info [22:23:59] Yeah, move the page join in there [22:24:11] And then do exactly what you used to be doing, but in a foreach pageid loop [22:25:10] so... if there are 50 feedback rows from 25 pages, we do 25 queries to get them? [22:25:32] 26 instead of 2, yes [22:25:51] yikes. this is better than a like? [22:26:00] It'll scan fewer rows [22:26:12] hm [22:26:16] The LIKE will scan all log entries in the Special: namespace [22:26:37] ugh. [22:27:03] (which in practice is only the aftv5 log currently) [22:27:04] i wonder. do you think we could just do a query to remove the page title from logging.log_title? [22:27:16] Let's see how big that log is [22:27:17] then update the code not to set it, and not to look for it? [22:27:38] Yeah [22:27:52] one slow query now, save lots and lots of queries over time [22:28:46] let me poke around and see what relies on the page title being there... [22:30:37] Only 857 log entries [22:31:54] ok, not bad [22:32:31] would didgets only be a valid title [22:32:47] lol, spelling fail [22:33:30] digits only? Yes [22:34:27] ok, what would not be a valid title? [22:35:16] the title in the log needs to be able to get to the permalink [22:36:14] if i can use something constant in that middle section to indicate permalink, then the id... [22:36:52] Things that aren't a valid title: [22:36:55] * >255 bytes [22:37:20] * contains []{}|#<>%+? [22:37:34] or maybe if there's a way for me to have a Special:ArticleFeedbackv5Permalink/{id} that forwards... [22:37:43] That could work [22:38:22] But it would make it harder to get the log entries for a given title, wouldn't it? [22:38:38] that's true [22:38:41] Cause right now you can do that with a prefix search for Special:ArticleFeedbackv5/Barack_Obama/ [22:40:06] yeah, value there -- i'm just thinking that up to 51 queries every time we load feedback is a high price to pay for a gray link [22:40:51] What is the condition for making the link gray again? [22:41:02] if there aren't any activity log entries for that feedback id [22:41:14] Oh OK [22:41:41] let's do this. i'll back out the whole gray-link change (manually, ugh). [22:41:58] then we add a new field to the feedback row that's a count of activity [22:42:09] and every time we add a log entry, we increment the count. [22:42:44] we can do a join of the activity log to fill in the existing ones [22:42:58] but we can deploy without the gray-link feature [22:44:41] basically, i'll kill the whole logging table join for now, and matthias or i can redo that feature at a later date. [22:45:12] RoanKattouw: would you prefer if i made that a patch to the central log commit, or a new one that depends on it? [22:48:08] Make it an amendment to the central log thing [22:48:24] At least the part where you undo the 'bad' changes [22:48:45] The gray link feature could be in its own commit depending on the big one, or inside the big one, I don't feel strongly about that [22:49:00] As long as we don't have a bunch of changes being applied and then immediately undone by the next commit [22:56:07] ok, will do [23:04:12] RoanKattouw: done [23:17:33] Yay, new tool up and running https://toolserver.org/~krinkle/mwSnapshots/ [23:23:23]