[00:16] wgrant: And you end up getting r15000 [00:16] StevenK: Indeed. [00:17] wallyworld_: https://code.launchpad.net/~stevenk/launchpad/imports-once-more-with-feeling/+merge/98944 [00:18] on it [00:21] StevenK: r=me. i'm sure you'll find some more next week [00:23] Haha, probably. [00:26] wallyworld_: How do you feel about 650ms for a batch of Ubuntu grantees on dogfood? [00:26] wgrant: i think that's ok, no? i have nothing to compare it to though [00:27] what does the profiling say take the time? [00:27] I mean in SQL. [00:27] Isn't it taking about 2s on prod atm? [00:27] s/prod/qas/ [00:27] total, not sure about the breakdown [00:28] Can you check? [00:28] Expand the in-page query listing. [00:28] Since oops-tools chokes on these oopses. [00:28] i/m sort of in the middle of some coding right atm [00:29] k [00:29] wgrant: wait, what ? [00:29] messing with lp form infrastructure [00:29] lifeless: sqlparse crashes when asked to reindent some of wallyworld's SQL [00:29] aieee win [00:29] lifeless: It doesn't like MIN(CASE [...]) [00:29] wgrant: you've opened a bug ? [00:30] No, was too busy trying not to throw buildbot and rosetta into a fire pit. [00:30] wgrant: i wasn't going to look too closely at the nimbers till the next branch lands [00:31] wallyworld_: I've tried the new primary DISTINCT query -- it takes 8s on DF. [00:31] Rewording it gets it down to 650ms. [00:31] Will see how it is on qas. [00:32] 8s? what does explain say? [00:32] ask again later [00:33] wallyworld_: It does the sort before the unique [00:33] So it's sorting like 140000 people [00:33] well that sucks [00:33] Forcing it to do the distinct first (by moving it into a subquery) works nicely, but it'd be nice if it was smarter. [00:33] you should land that [00:34] distinct will always sort before unique unless the data is being generated in-order for selective skipping [00:34] or the output sort is wholly different to the distinct columns, at which point brains assplode [00:34] Yeah. [00:35] Oh [00:35] It's the extra parens [00:35] >>> sqlparse.format('SELECT CASE (foo) WHEN 0 THEN 1 END', reindent=True) [00:35] u'SELECT CASE (foo)\n WHEN 0 THEN 1\n END' [00:35] >>> sqlparse.format('SELECT CASE(foo) WHEN 0 THEN 1 END', reindent=True) [00:35] Traceback (most recent call last): [00:35] When there's (unncessary) parens after CASE without a space, boom. [00:36] * wgrant lands a workaround to LP [00:36] wgrant: you will file a bug upstream though? [00:36] lifeless: Yeah [00:36] Just confirming that it still exists. [00:37] thanks [00:37] I hsould have had fairh [00:37] orly? [00:37] Oh [00:37] faith [00:38] lifeless: Fixed upstream, it seems. [00:38] >>> sqlparse.format('SELECT CASE(foo) WHEN 0 THEN 1 END', reindent=True) [00:38] u'SELECT CASE(foo)\n WHEN 0 THEN 1\n END' [00:39] Our version's more than a year old. [00:40] But there's only been one release since. [00:41] * wgrant upgrades us to 0.1.3. [00:44] lifeless: Does python-oops-tools do reviews? [00:44] humans do [00:44] Ah, I see there are MPs. [00:44] lp reviewers review them [00:44] or should be [00:45] its in the same group etc etc - /launchpad-project [00:45] e.g. wallyworld as OCR is interruptible [00:45] wgrant: if its a dep bump, self review though [00:45] Sure [00:45] Still wants an MP by policy, though. [00:45] am i needed? [00:45] Nope. [00:46] good :-) [00:46] I can self-review an s/2/3/ :) [00:54] Oh [00:54] It's tarmac [00:54] So I couldn't have committed directly anyway. [02:12] wgrant: Has your -11-4 triggers branch landed? [02:15] Grumble. 917 line branch. Perhaps I will have to split this thing. [02:16] StevenK: No, it was waiting for your information_type NOT NULL branch. [02:16] Which I believe landed this morning. [02:16] It did, yes. [02:16] But we already have two patches in the queue, and it won't clear until Tuesday, so I won't land it yet. [02:16] This code branch depends on it and -12-3 [02:17] So Monday will be FKs, Tuesday will be NOT NULL, Wednesday will probably be my legacy access triggers [02:17] Then what do you have/ [02:17] BugSummary triggers [02:18] Ah [03:16] wallyworld_: Ah, findGranteePermissionsByPolicy still returns oddly sized batches. [03:16] Because it's distinct on (person, policy) [03:16] * wgrant fixes in the performance branch. [03:16] bollocks, thanks [03:17] wgrant: if you fix, can you add a test too? [03:17] wallyworld_: It necessitates a reworking of the return type, so I have to rewrite the tests anyway. [03:17] ok [03:18] (currently it returns 75 (person, policy, permission) rows, whereas it probably wants to return 75 (person, {policy: permission}) [03:27] i like the 3-tuple form better [03:28] Indeed, but it doesn't work for slicing by person. [03:28] wgrant: So why does the langpack export take 22 hours? And no fair if you say because translations is horrible. [03:28] 'cause you'd slice by :75 and get 93 rows. [03:28] StevenK: Because translations is horrible. [03:28] I filed a bug on it a couple of weeks ago. [03:28] wgrant: No fair. [03:29] The bug mentions a specific thing that might be a performance problem. [03:51] 971 line diff :-( [03:59] wallyworld_: Are you going to hate me if my branch that drops private and security_related from CreateBugParams, IBug._private and IBug._security_related is roughly 1,000 lines? [04:00] no [04:00] i hte you anyway [04:00] :-( [04:01] wgrant: Turns out bugsummary *and* calculate_bug_heat has to change. [04:01] :D [04:01] StevenK: i was joking :-P [04:02] 220 database/schema/patch-2209-12-3.sql [04:02] stub is going to hate me too. [04:02] 523 ../bugtaskflat-db/database/schema/patch-2209-16-0.sql [04:04] Haha [04:05] One bug to fix, then I get to re-run -vvm bugs [04:21] Has diff generation been oddly fast or anyone else lately? [04:21] I'm regularly getting diffs within 20 seconds now. [04:22] wallyworld: https://code.launchpad.net/~wgrant/launchpad/sharing-prettier-sql/+merge/98967 [04:22] wallyworld_: ^^ [04:22] underscorefail [04:24] Haha [04:35] wgrant: r=me. will be good to see how it goes on qas [04:35] Marvellously I hope. [04:36] Then we can set the timeout to 1s and declare victory over the universe. [04:36] I want to setup a qdb just for all the fun quotes in #lp-dev [04:37] You'll keep adding branch names. [04:38] I'll just have everything StevenK and wgrant says. [04:39] maybe I should just make it a tumblr. shitlpdevssay.tumblr.com :P [04:39] !! [04:39] http://validator.w3.org/check?uri=https%3A%2F%2Flaunchpad.net&charset=%28detect+automatically%29&doctype=Inline&group=0 [04:39] We are valid! [04:39] Finally. [04:40] * wallyworld_ goes away for a bit - bookclub with kid after school [04:40] With 2 warnings? [04:40] wgrant: So we've gone LIVE with changing over to html5?! [04:41] huwshimi: Yeah, this morning. I tested the site fairly thoroughly in Firefox/Chromium/Opera/Safari/IE8/IE9/IE10, and it looks good. [04:42] wgrant: I've clearly missed the discussion about doing that... [04:42] It was just a doctype change :) [04:42] So the only rendering change is moving from Almost Standards to Standards. [04:46] wgrant: Have you tested in ie6? [04:46] (it's not JUST a doctype change) [04:46] huwshimi: The watermark is slightly broken, but we no longer support IE6. [04:46] wgrant: When was that decided? [04:46] (only difference is that the logo is on a separate line) [04:47] * wgrant finds a reference. [04:47] 06:56 < lifeless> rockstar: we just blew IE6 away [04:47] 06:56 < lifeless> rockstar: so gnar gnar gnar :P [04:48] And various other discussions. [04:48] But the doctype change makes no visible difference in IE6. [04:48] wgrant: Have you check that? [04:49] wgrant: You're going to have to cite something better than that. Last I heard we have significant stakeholders who require IE6. If that's changed it's not been announced publicly. [04:52] huwshimi: That restriction came from OEM a little over two years ago, and is apparently no longer true. https://dev.launchpad.net/GradedBrowserSupport was recently updated to remove any reference to IE. [04:52] And it has been stated on IRC that IE6 is no longer required. [04:52] lifeless: ^^ right? [04:53] Anyway, still works fine on IE6, except for the logo and title being on different lines. [04:53] (and the fact that we use PNG transparency for sprites, which makes everything look pretty hideous, but that's been the case for years) [05:01] wgrant: There needs to at least have been a discussion about migration, ramifications, future implications etc. [05:05] huwshimi: For the doctype change that doesn't change the markup that engineers must write at all, brings the existing HTML5 elements and attributes that we use into validity, and in browsers causes a single rendering change (the removal of the shrinkwrap effect from inline images)? [05:06] It's not as if we're moving from XHTML to HTML rendering. [05:06] There was some discussion on our call, however. [05:08] Right, those are SOME of the implications of changing to HTML5. [05:12] The only change is the doctype, and the only user-visible difference is the inline img shrinkwrap removal, which has already been fixed everywhere that it was used. [05:12] There may be implications of using more HTML5-only features. [05:12] But that wasn't the change here. [05:13] We've always been polyglot HTML/XHTML out of necessity, so there is no markup difference. [05:13] So the implications are remarkably close to 0. [05:17] wgrant: I think you're missing the point. [05:20] huwshimi: Oh? [05:22] wgrant: "16:01:32 huwshimi: wgrant: There needs to at least have been a discussion about migration, ramifications, future implications etc." [05:23] Migration: the shrinkwrapping change. Ramifications: the shrinkwrapping change, and our existing usage of HTML5 elements is no longer invalid. Future implications: nothing new. [05:23] (and by discussion I mean on the mailing list) [05:23] Particularly boring. [05:25] wgrant: huwshimi: we are waiting on a final ack from OEM *but* [05:25] statik has said that us supporting IE6 isn't a good use of time [05:25] and mrevell has said we won't do it - on the stakeholders list [05:26] the final ack we're waiting on is in case someone comes back and says its part of getting X revenue to make it worth while [05:26] Ahh, that's why I couldn't find the discussion. [05:26] There it is, indeed. [05:26] IE6 is now at most best effort [05:27] "Thanks. Let me explain a little more clearly where we are. We no [05:27] longer support IE6 and we won't make any effort to ensure a good [05:27] experience in IE6." [05:27] (from mrevell) [05:28] lifeless: Thanks (clearly I'm not on that list). [05:29] we need to at least communicate that to our users if we do go ahead [05:29] huwshimi: We knowingly released dynamic bug listings when they're completely broken in all versions of IE. [05:29] wgrant: We did!? [05:29] Who knew? [05:31] I'm pretty sure it was knowingly, but regardless it's clear that nobody tried them even though they were clearly using new JS features unlikely to be supported in IE. [05:31] the team explicitly put in a check for IE short circuiting the code, because they hadn't tested it [05:31] Hm? [05:31] It's not short-circuited. [05:31] It runs, and is broken. [05:32] wgrant: there was a new if (...IE) thing you ripped out just this week [05:32] anyhow, I have to run [05:32] Nope. [05:32] Those were all old. [05:32] I have no objection to us announcing that we're not caring for IE6 anymore [05:32] I only ripped out things that work in IE>=8. [05:32] wgrant: ah, my misunderstanding [05:32] OTOH I don't think we need to shout it from the rooftop that we don't support a given browser; most sites just track current releases and make no fanfare about changes [05:33] Exactly. [05:33] And our IE6 and IE7 support has been in a pretty severe state of disrepair since 3.0. [05:33] Anybody using them significantly since then has probably torn their eyes out by now. [05:33] So they wouldn't be able to read the notification anyway :) [05:34] (functionality critical for OEM *worked*, and still does, but it's always been fugly) [05:34] Well the fact that we had (or have) stakeholders that we were maintaining support for means we need to be a little polite [05:36] huwshimi: mrevell asked someone in PES if a polite notification was desired, and received no reply AFAICS. [05:36] This was 6 weeks ago. [05:36] Ah, you should be able to see the ML archive. [05:37] https://lists.launchpad.net/private-canonical-launchpad-stakeholders/msg00658.html [05:50] wgrant: I think I've broken calculate_bug_heat(), can I use 'in' in a plpy block? [05:51] StevenK: In what context? [05:51] if bug['information_type'] in (3, 4): [05:51] heat['privacy'] = BugHeatConstants.PRIVACY [05:52] That should work, but you actually want (3, 4, 5) [05:52] And it's possible it's some magical type that doesn't work like that. [05:52] It's getting pulled out by SELECT [05:53] But I'm lost how to debug it [05:53] Pastebin the whole function [05:54] wgrant: http://pastebin.ubuntu.com/896042/ [05:56] StevenK: wut [05:56] That's prehistoric [05:56] You need to check patches too :) [05:56] database/schema/patch-2209-07-1.sql [05:57] It's a little bit simpler. [05:58] A little? [05:58] wgrant: How do I replace CASE private WHEN true -- CASE information_type IN (3, 4, 5) ? [06:00] StevenK: For now I guess CASE information_type WHEN 1 THEN 0 WHEN 2 THEN 250 WHEN 3 THEN 400 ELSE 150 END [06:00] That will match the current behaviour. [06:01] WHEN 4 THEN 150 [06:01] Oh, ELSE [06:01] Nevermind me [06:04] To catch USERDATA and PROPRIETARY, yes. [06:04] I think it makes sense. [06:09] wgrant: Indeed. It even works. [06:20] wallyworld: Are you still reviewing? [06:31] StevenK: when are you expecting your db patches to land? [06:32] StevenK: yes to your question, i didn;t see it [06:34] wallyworld: https://code.launchpad.net/~stevenk/launchpad/bugs-remove-old-privacy/+merge/98974 [06:35] StevenK: already looking [06:35] StevenK: 69 # Security bugs are always private when filed, but can be disclosed [06:35] i think that comment needs updating [06:35] It [06:35] Sigh [06:35] It's current for the moment, it will change when the UI does. [06:36] hmm. i'd just s/private/embargoed [06:36] i think that's more accurate given the code change just below it [06:37] wallyworld: -12-3 is in review, -11-4 is reviewed but not landed, but we have Monday and Tuesday for FDTs already so if -11-4 and -12-3 land on Tuesday, it gives us time. [06:37] wallyworld: So I'd expect this branch in ec2 next Friday morning [06:37] too bad we can't do more than one patch per FDT [06:37] we have to wait a week to get your branch in ec2 [06:39] wallyworld: I need the patches in devel (otherwise a large amount of tests go bang), and that doesn't happen after it has been applied to prod. [06:40] wallyworld: I'm tempted to just slam the DB patches I need into this branch and toss it at ec2 test on Tuesday just so I can fix all the other failures. [06:41] The DB patch branches should be merged into that one; it depends on them. [06:41] StevenK: you could do that if you run ec2 test [06:41] StevenK: i don't understand the need for the conditional on line 95 [06:41] 95 + if params.information_type is InformationType.PUBLIC: [06:41] 96 + params.information_type = InformationType.USERDATA [06:42] wallyworld: We don't want to clobber EMBARGOEDSECURITY [06:42] Which may be set higher up [06:42] ok, makes sense === almaisan-away is now known as al-maisan [06:53] StevenK: return "Bug.information_type IN (1, 2)", _nocache_bug_decorator [06:53] instead of 1 and 2, should we use InformationType.PUBLIC.value etc [06:53] wallyworld: So, I think that method should be entirely rewritten because it's horrid [06:54] wallyworld: So I did the smallest amount of work to get the method working [06:54] StevenK: ok. i think you could probably also change transitionToInformationType to not return a tuple [06:54] it would only be a few extra loc [06:55] transitionToInformationType doesn't return a tuple :-) [06:55] sorry, setPrivacyAndSecurityRelated [06:55] since the tuple values would always be equal [06:55] Right === al-maisan is now known as almaisan-away [06:57] StevenK: other than that, i think it looks ok. but as with most things lp, i'm sure there will be a few dark corners we have forgotten to look in [06:58] Haha [06:58] Yeah [06:58] let's hope the test coverage is adequate [07:01] Yeah. :-( [07:01] StevenK: r=me but i had a thought. why don't you just delete setPrivacyAndSecurityRelated entirely? [07:01] Because it's bloody exported! [07:02] but there's only a few places left in the code base so i would remove those at least [07:02] eg bugimport [07:02] Isn't it new? [07:02] Didn't we decide it could go away because it's not part of 1.0? [07:02] and yes, i think we did [07:02] Hmmm. [07:03] I could kill it ... [07:03] what's a few extra changes? it's already quite large :-) [07:03] go on, you know you want to [07:04] StevenK: Your confident your code was based off the latest versions of those stored procedures? We unfortunately have versions scattered throughout the DB patches and we broke things once before by accidently using old code as a basis for a change. [07:05] stub: I'm confident about calculate_bug_heat(). Would you mind checking for the other three? [07:05] k. I'll have a trawl too. [07:06] But that might end up after lunch :) [07:07] I generally check \df+ just to be sure. [07:07] yer [07:08] Particularly since this touches bugsummary... [07:09] Hmm... I suspect the best way of doing these changes is to use '\df+' to generate current functions into your db patch. commit. then edit, and we can generate a nice diff. [07:11] BugSummary probably hasn't been touched since the last schema snapshot, so you can likely just pull them straight from launchpad-2209-00-0.sql [07:11] But yeah. [07:11] That might be a good way. [07:12] Currently it's pretty horrible. [07:13] Oh, if it hasn't been touched we don't have to worry about accidentally cargo culting old versions any more. [07:15] Yeah [07:15] I think before the last snapshot production had a different version than dev. [07:15] Due to massive confusion around those emergency fixes. === wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10 [07:19] wallyworld: Dropping setPrivacyAndSecurityRelated means that branch deletes more code than it adds. [08:04] StevenK: What are you using the bugsummary_viewers() function for? You might find a VIEW more suitable. [08:20] StevenK: that's good that we end up with a net code deletion :-) [08:41] good morning === almaisan-away is now known as al-maisan [09:41] stub: I have no idea at all -- it was using private, so I changed it. [09:42] oh, thought that was something new you were adding :) [09:45] stub: Nope, those are 4 triggers that should already being used and called on prod today -- I'm converting their use of bug.private and bug.security_related to bug.information_type [09:46] stub: Thank you for the approval, I'll toss it at ec2 on Monday. [10:00] wallyworld: Bug #962912 :( [10:00] <_mup_> Bug #962912: StormRangeFactory evaluates DecoratedResultSet slices twice < https://launchpad.net/bugs/962912 > [10:01] wgrant: yes, i noted that in my mp [10:01] but didn;t raise a bug [10:01] because there's a reason for it [10:02] so we would need to find a work around [10:06] wallyworld: I think it should be pretty easy. Will look at it next week [10:07] wallyworld: Just needs to use a custom version of __iter__ on DRS that returns (base, decorator(base)) rather than just decorator(base) [10:10] yeah probs. my brain was too full to think about it this week [10:10] and we can fix the other issue too [10:12] WHich other issue? [10:12] I didn't actually read the text of your MP, just the diff. [10:12] * wgrant finds. [10:13] Hm, don't see another issue. [10:17] wgrant: SQL tracing shows that the batching infrastructure executes the core batching query twice due to a decorated result set being used. This is unfortunate. [10:17] https://code.launchpad.net/~wallyworld/launchpad/sharing-view-batching4-957663/+merge/98820 [10:18] That was the first issue, I was looking for the second one that you mentioned. [10:19] wgrant: ah, that the range factory can't handle person_sort_key [10:20] bug 961836 [10:20] <_mup_> Bug #961836: StormRangeFactory should support functional sort keys < https://launchpad.net/bugs/961836 > [10:20] wallyworld: ah, right. [10:20] wallyworld: That's a bit harder. [10:20] yeah [10:20] But similar indeed. [10:20] maybe [11:00] morning === al-maisan is now known as almaisan-away === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugtasks: 4*10 === matsubara-afk is now known as matsubara === almaisan-away is now known as al-maisan [13:13] Morning, all. [13:17] party on === al-maisan is now known as almaisan-away [13:47] deryck: https://code.launchpad.net/~rharding/launchpad/yuixhr_combo/+merge/99023 [14:30] * deryck switches work locations [14:35] are we applying the new LoC maintenance costs experiment to all code, or just the LP tree? my understanding was the latter, but i'm curious. [14:40] hi guys [14:41] jcsackett: hmm, that conversation came up last night. /me checks how that went [15:02] abentley: r=me for the latr.jobrunner mp [15:03] adeuring: Cool. Thanks. [15:06] adeuring: Merged and pushed. [15:07] abentley: cool. but I can't yet see your other MP -- LP is terribly slow for me at the moment... [15:07] adeuring: I haven't made a proposal because I'm still trying to sort out this configuration issue. [15:08] abentley: ah, ok [15:12] adeuring: So with my branch merged, we have my job.fail fix landed without a test. [15:12] abentley: I know but that does not mean that can't test it ;) [15:15] rick_h: ctrlp is pretty hot. :-P [15:15] jcsackett: yea, I'm liking it. Not used to starting in the lib directory, but with multiple tmux sessions going I'm getting over it slowly [15:16] rick_h: i didn't need to start in lib; just added the non-code dirs to the custom filter list. [15:16] bac: can I get this on your list please? https://code.launchpad.net/~rharding/launchpad/yuixhr_combo/+merge/99023 [15:16] were you having problems with that working, or did you not want that globally set? [15:16] jcsackett: yea, but since I do other projects I didn't want to drop some other dirs [15:16] rick_h: dig. [15:16] rick_h: sure [15:16] lib, build, I use on other code projects [15:17] jcsackett: but yea, starting in lib seems like a winner, just have to switch to another tmux window to fire off make/test commands and such [15:17] yeah; it can run a custom filter command..you could probably rig up something nice with sourcing a command from a .ctrlpignore file. [15:17] * jcsackett makes note to do that at some point. [15:17] ah, true. or even just a shortcut to set lpmode or something [15:18] I do get when it keeps reloading the cache more often than I'd expect, but not nailed down why yet [15:19] ssd ftw on that I guess, pretty fast [15:19] * jcsackett nods [15:20] next up I need to get syntastic running vs my pyflakes plugin, maybe this weekend [15:36] "vim: the neverending plugin and configuration rabbit hole" :-P [15:50] * deryck is afk at accountant === deryck is now known as deryck[afk] === matsubara is now known as matsubara-lunch === matsubara-lunch is now known as matsubara === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === deryck[afk] is now known as deryck [18:04] rick_h: done. sorry for the sashimi-induced delay. [18:04] bac: no problems, thanks for the peek [18:08] bac: thanks for the comment catch [18:13] <---------- EOD nn [18:13] have fun czajkowski [18:39] does anybody know if there's a Django app that mirrors Launchpad objects? [18:39] Project/Team/Branch, etc [18:54] bac: do you have time to review https://code.launchpad.net/~sinzui/launchpad/project-notify-4/+merge/99094 [19:00] sinzui: yes [19:00] sinzui: that branch has conflicts, though. would you resolve them first? [19:03] okay [19:06] bac: I pushed the resolution of the import conflicts [19:35] deryck: I am especially free to chat now, as I've just put my branch up for review. [19:40] abentley, I'm not further along enough to articulate ideas yet. unfortunately, distracted by other work. [19:40] deryck: cool. [19:41] abentley, I'll try to knuckle down the rest of the day on it, and then let's chat first thing Monday. [19:42] sinzui: done. neat branch and idea. it's going to be awesome. [19:42] abentley, if that's cool with you. [19:42] deryck: sure thing. [19:42] abentley, thanks, man! [19:42] deryck: np. [19:42] bac, thanks for the encouragement. That branch was very hard. Reading all the other ways lp.registry sends emails really depressed me [19:43] no doubt [19:49] bac assertTrue(1) passes, but it is not a boolean. I used assertIs to avoid coercion. [19:50] sinzui: oh, gotcha. [21:20] bac do you have a few minutes to look at this small branch: https://code.launchpad.net/~sinzui/launchpad/front-page-layout/+merge/99121 [21:20] it has a picture too [21:23] sinzui: i don't. [21:23] okay. thanks bac === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10 [22:20] Yay [22:20] /ubuntu/+sharing down to 1.2s [22:21]