[00:00] poolie_: whats the link you added to creatingnewprojects for ? [00:00] lifeless: i think people will google 'create launchpad project' end up there and be confused [00:01] ok, I think it needs refinement though [00:01] sure [00:01] just wanted to give people a chance to understand it is not rules about launchpad as a whole [00:01] typical quoting problem === poolie_ is now known as poolie === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 232 - 0:[######=_]:256 [00:35] Where did the 15 new bugs come from? :/ [02:12] Erm [02:13] http://blog.launchpad.net/cool-new-stuff/better-bug-subscriptions was published yesterday, but it shows the UI from when the feature was released, which is completely different from the current one :/ [02:14] Should we unpublish until it's fixed? [02:14] Oh, it's at least not frontpaged. [02:18] eyeballs requested: https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess [02:21] lifeless: Have we analysed recent patches to see how many of them are doable without simultaenous changes? [02:22] wgrant: not rigorously, but we haven't been trying to do it either, so what we've done isn't a baseline [02:22] wgrant: we know that all the ha services out there manage [02:24] lifeless: I think we should before we go much further, so we don't get ourselves into trouble. [02:24] Since we're throwing away read-only (which I still find fairly unwise) [02:25] lifeless: about your document ^^^: in the Deploying Patches section, "After successful QA on a patch, ...". I take it that is for hot patches. Cold patches are deployed once a month during out downtime deployment. Shoudl that text say "After QA on a hot patch, ..."? [02:25] wallyworld_: not any more [02:25] wallyworld_: you might want to read yesterdays performance tuesday mail ;) [02:26] wgrant: Do you think the removal of the bazaar-experts celebrity is QA-able? [02:26] lifeless: i read it but it clearly has gone in one ear and straight out the other :-( [02:26] StevenK: Check that you have branch access, possibly check that LOSAs do. [02:27] wgrant: I can change the details of an owned branch, good enough? [02:28] StevenK: Indeed. [02:29] wallyworld_: there are now no scheduled monthly patch windows [02:29] wallyworld_: over the next 4 weeks we'll be bringing up the process for doing short downtime multiple times a week [02:29] wallyworld_: (short => less than 300 seconds) [02:29] wallyworld_: and all patches landing from here on in need to be compatible with that process [02:30] lifeless: ah, right. thanks. for that 300 seconds, lp will be in ro mode? [02:30] this will be a fantasic change [02:31] no, just db connections refused [02:31] going into readonly mode and out again takes an hour [02:31] lifeless: In the current implementation. [02:31] There is nothing that requires that.l [02:31] wgrant: sure, and if someone wants to work on that they can [02:32] Even in the current model, where we have to rebuild the slave because slony is crap. [02:32] Touch file, detach slave, upgrade, remove file, rebuild slave. [02:32] No slower than blocking connections. [02:32] so no [02:32] we're not detaching slaves or rebuilding them. [02:32] Why not? [02:32] thats a cause of about 90% of our downtime delays. [02:32] We can easily do this without downtime... [02:33] I don't object to a great implementation of readonly mode. But readonly mode must not make the downtime longer or riskier. [02:33] Currently it does. [02:33] if db connections are refused for 5 minutes, the users will see page timeouts? [02:33] And its not at all clear to me that that can be fixed on slony. [02:33] Can we tell SSO to GTFO of our DB and move to a sensible replication strategy? [02:34] wgrant: not in the same timeframe as this project ;) [02:34] wallyworld_: they will see a horrible mess in the very first cut, but we'll iterate. [02:34] cool, just checking :-) [02:34] lifeless: "a horrible mess" meaning a maintenance page? [02:34] like, the appservers can show a fail-UFO page when they can't connect to the DB eventually [02:34] * wallyworld_ was also wondering that [02:35] Unlike slony, reloading apache isn't risky. [02:35] wgrant: according to losas it is. [02:35] They are wrong :) [02:35] wgrant: they are the ones dealing with our apaches not restarting cleanly today. [02:35] wgrant: so, I beg to differ. [02:35] We have had a lot of rollout problems, and that is not one of them that I've ever heard of. [02:35] So we have rollout problems that are hidden from us? Yay. [02:35] wgrant: we don't restart apache during our rollouts. [02:36] minor correction. we graceful apache on crowberry. [02:36] ah, one. [02:36] We can't just leave the appservers silently broken for 5 minutes. [02:36] branch rewriter thingybobby [02:37] wgrant: 5 minutes is not the target; its the absolute outer limit [02:37] Perfect is the enemy of good, but terrible is the enemy of not looking like we are useless. [02:37] wgrant: the target is 10-20 seconds [02:38] wgrant: look, if you want to jump in and make the error condition look nice, that would be awesome. [02:38] wgrant: I was clear about what I was proposing on -stakeholders [02:38] wait [02:38] what? [02:38] what's the problem with reloading apache? [02:38] That's what I said. [02:38] How do I get (and reset) the OOPS count in a test? self.getOopsCount() or so? [02:38] re*starting* apache can be problematic [02:38] but reloading is just fine [02:38] we do it *all the time* [02:38] If we can't reload Apache, we have pretty serious problems. [02:39] elmo: spm was telling me a month or so back that our ones don't go cleanly occasionally [02:39] elmo: I didn't get details [02:39] lifeless: restart yes - reload no [02:39] and we wouldn't need a restart to put a maintenance page in place [02:39] ok, good to know. Can a script running on wildcherry drive such a change ? [02:39] So I may not be insane. This is good. [02:40] lifeless: it could, sure [02:40] ok, cool. [02:41] lifeless: I suspect you're mixing problems there. we have a known issue where a reload won't clear a certain problem; necessitating a restart. but that's a different beastie. [02:44] spm: it wasn't, but its beside the point - I'm entirely happy for us to do something you guys consider low-risk-of-fail [02:45] spm: my criteria are: the core script must not block on niceties (because once downtime starts, users are indisposed regardless); and the script must not be able to be made unreliable due to non-core-tasks. [02:47] nod [03:55] wgrant: O hai, can haz review? [04:05] StevenK: Which? [04:09] wgrant: https://code.launchpad.net/~stevenk/launchpad/daily-build-oops/+merge/67915 [04:20] wgrant: Danke [05:08] spiv, your patch failed again the same way [05:09] has anyone else seen "ImportError: No module named html5browser" inside importfascist? [05:09] ah i see the mail [05:10] nm [05:10] spiv i think i can fix it [05:10] Ah good :) [05:22] lifeless: O hai, Mr OCR. Can haz review? [05:42] of whut === almaisan-away is now known as al-maisan [06:17] StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-419534/+merge/67918 [06:35] lifeless: Sorry. https://code.launchpad.net/~stevenk/launchpad/uploaded-packages-wrong-link/+merge/67916 [06:37] wgrant: r=me === al-maisan is now known as almaisan-away [07:50] stub: hiya [07:50] stub: after this cutover, can we do our weekly catchup ? [07:50] morning [07:51] o/~ [07:52] good morning [07:54] lifeless: sure [07:57] Hallo === jtv is now known as jtv-brb === jtv-brb is now known as jtv === almaisan-away is now known as al-maisan [08:56] Anyone mind if I update dogfood? allenap, bigjools, StevenK, wgrant? [08:56] jfdi [08:56] * jtv jfdis [09:19] Any one up for reviewing https://code.launchpad.net/~stevenk/launchpad/queue-no-changes ? [09:19] Bah, branch URL. [09:21] https://code.launchpad.net/~stevenk/launchpad/queue-no-changes/+merge/67913 [09:25] StevenK: where's the bug for that? [09:48] bigjools: I don't think there is one. [09:48] StevenK: then what are you fixing? [09:48] bigjools: Happy to file a High bug for it. [09:48] just want to know more about it, 'tis all [09:49] bigjools: Right. When I was working with the LOSAs to reject an ACCEPTED binary upload on germanium, the queue tool didn't work. That branch should sort it. [09:50] ah ok [09:51] file bug :) === jtv is now known as jtv-eat [10:43] release the hounds - /me just made a branch that allows people to use the API to request uploads to ubuntu by copying packages from PPAs. [10:48] Project devel build #888: FAILURE in 2 hr 5 min: https://lpci.wedontsleep.org/job/devel/888/ === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | Critical bugs: 232 - 0:[######=_]:256 [10:51] allenap: incoming branch from me if you don't mind? [10:53] bigjools: Cool. [10:57] tar === henninge is now known as henninge-lunch [10:58] bigjools: Can you have another look at my MP? [10:58] 2 hours?! [10:58] yarp [10:58] * StevenK peers at Jenkins [10:58] allenap: Hi! If you could have a look at my branch while I am away, that would be great. [10:58] https://code.launchpad.net/~henninge/launchpad/bug-740208-ws-regression/+merge/67937 [10:59] Sigh, the slave died [10:59] StevenK: that's an odd test [10:59] bigjools: It tests that exact code path [10:59] Which is what you wanted [10:59] StevenK: by inspecting the logger? [10:59] shouldn't it check no email is sent? [11:00] How else do I determine it did *nothing*? :-) [11:00] It doesn't even get that far, it bails out extremly early [11:00] so checking that no email is sent will be fine, right? [11:00] StevenK: So it's going to reject it silently? [11:00] That's bad. [11:01] wgrant: There's no changes file and no blamer [11:01] if there's no changes file what else can be done? [11:01] Ah, true. [11:01] Delayed copies must die. [11:01] nearly there! [11:01] my branch today does some of the PCJ attachment to API copies [11:06] * StevenK prods bigjools :-P [11:07] StevenK: fix the test to check for no email, examining the debug log is gross === al-maisan is now known as almaisan-away [11:08] that is the intention of the change, right? To not blow up by attempting to send email with corrupt data (no PU) [11:13] bigjools: Done. [11:13] StevenK: I approved you already [11:13] bigjools: Danke [11:13] bitte [11:14] Bring on longpoll [11:17] StevenK: how long do we have to wait [11:18] it's been two weeks since I saw a working demo [11:18] blame lifeless, he wants all this deployment gubbins done :) [11:18] I'm so tempted to reply with 'Oh noes' [11:19] bigjools: what sort of deployment gubbins? [11:20] it will be the first time we've done something with the new SOA, so the longpoll server needs its own deployment story. We also need better metrics on it and Rabbit [11:20] we'll probably look at it agan when DDs are done. [11:20] and when I say "better", I mean "some" :) [11:21] bigjools: quite a lot of stuff then [11:21] bigjools: it'd be nice to be able to see how an external contributor could help. [11:22] jml: the best place would be to help us get metrics since the rest of it's internal [11:23] bigjools: got a list of the things you need & the format you need them in? [11:23] that's a better question for lifeless [11:23] let me dig up some bugs though [11:24] hmm no bugs [11:24] jml: the bugs are all linked from the LEP [11:25] there we go [11:25] lifeless: ok, thanks. [11:40] Project db-devel build #720: FAILURE in 5 hr 13 min: https://lpci.wedontsleep.org/job/db-devel/720/ [11:43] is https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess active as of now? should I be refactoring my multiarch-translations branch to separate out the schema patch? [11:49] cjwatson: yes [11:49] lifeless says yes, but I doubt it. [11:49] But for yours it can't hurt. [11:49] wgrant: you also doubted making LP faster ;) [11:49] lifeless: Yeah, but that didn't go from 0 to implemented in three weeks :) [11:49] wgrant: indeed, it was faster :P [11:50] wgrant: I want a consult with you wearing your tz-friendly soyuz-internals-specialist about the buildmaster + db resets tomorrow, if you have time [11:51] lifeless: Ewww, but maybe. [11:51] wgrant: seeing as I don't really want to wait for Aug 12 :-) [11:52] cjwatson: oh, for clarity [11:52] cjwatson: we need *patches* to abide by that now. [11:52] cjwatson: we're not live on the *deployment* side of it yet, but we're aiming to be doing that rather than a 90 minute downtime in august [11:52] lifeless: FWIW I don't think the buildmaster has any issues, when I was writing it I often killed it mid-cycle and there's lots of code to recover from Bad Stuff. [11:53] bigjools: thats a great comfort [11:53] bigjools: did you try taking the db out from under it ? [11:53] bigjools: There are a couple of consistency issues that are just about impossible to track down. === almaisan-away is now known as al-maisan [11:53] But they are rare. [11:53] bigjools: I figure we'll need some reconnection glue [11:53] lifeless: I didn't test that. [11:53] OK; if, for the sake of argument, I posted the db part of that patch separately, might I expect it to be deployed before Aug 12? [11:53] all our daemons will need reconnection glue I expect [11:53] cjwatson: expect no. Pleasantly surprised, I hope so. [11:53] (and how are you tracking dependencies between the separated-out db-devel and devel targeted branches?) [11:54] bigjools: https://bugs.launchpad.net/launchpad/+bugs?field.tag=fastdowntime [11:54] yes :) [11:54] cjwatson: for your branch, you'll need to land both components on db-devel (because we're not live on the incremental deploy steps yet) [11:54] cjwatson: but you need to land them in separate landings so we know the schema change doesn't break existing code. [11:55] ok, makes sense [11:56] I think I am in love with bzr switch [11:56] how can I break this to my wife [11:56] bigjools: offer her preferred-courtesan status [11:56] bigjools: 'same job, better perks' [11:57] "cour·te·san (kôr t -z n, k r -). n. A woman prostitute" [11:57] she'll love that [11:58] We desperately need an Ubuntu quotes db. [11:58] :) [11:59] perhaps some bzr-backed wiki? *cough* === matsubara-afk is now known as matsubara [12:13] nigelb: No, we *don't*. === henninge-lunch is now known as hennigne === hennigne is now known as henninge [12:19] StevenK: heh [12:19] StevenK: Why not? :-) [12:19] Because quotes pages are dangerous. [12:20] And productivity sinks. Ubuntu has enough of those. :-) [12:20] Hah [12:26] StevenK: that should go on the quotes page === jtv-eat is now known as jtv === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | Critical bugs: 232 - 0:[######=_]:256 [13:44] henninge: ping. [13:54] jcsackett: Hi! ;) [13:54] henninge: hi, i'm looking at https://code.launchpad.net/~henninge/launchpad/bug-740208-ws-regression/+merge/67937, and had one question. [13:54] jcsackett: ask away [13:54] is this just you addressing a wart in the code you found, or was this Text/Diff thing responsible for an issue found in qa? [13:55] It was causing an oops [13:55] henninge: ok, then is it possible to create a test showing the oops doesn't happen anymore as part of this branch, to prove it's the fix? [13:55] jcsackett: Sorry, I just realized I forgot to mention more context. [13:56] henninge: no worries. just leads to me bugging you on IRC. :-) [13:56] jcsackett: I could try but it is a test for a corner case. [13:57] henninge: how "corner" are we talking? major pain to set up the testcase? [13:58] jcsackett: I am not sure. There are tests that don't trigger the error so I think something is still missing to create the same situation as in production. [13:58] jcsackett: But I am happy to give it a try. [14:00] jcsackett: did you claim the review? deryck had offered to review it. Just to avoid double work. [14:01] henninge: i was just looking it over. i claimed it, but can abstain in a comment and assign it to deryck, if he has more context to look at it with. :-) [14:01] * deryck doesn't mind jcsackett taking it, but is happy to do it, too [14:01] deryck, henninge: I'm OCR today, so i may as well finish it up. :-) [14:01] jcsackett, henninge -- works for me. :) [14:02] jcsackett: go ahead ;) [14:02] Fresh eyes are nice as well. [14:02] yup [14:04] bigjools: i need to QA https://bugs.launchpad.net/bugs/805634 [14:04] bigjools: what do you suggest? I ask a losa to run populate-archive on qastaging and check the builds priority? [14:05] flacoste: yes, that should work [14:05] flacoste: or staging [14:08] bigjools: any easy way to look at an archives builds from the UI? or should I use API, or poke the DB? [14:08] flacoste: yes it'll appear in the UI [14:08] flacoste: /+archives [14:09] and you can examine the builds [14:11] deryck: chat? [14:13] henninge: given the corner-case issue, i think this looks fine. esp as the actual diff is fairly trivial. r=me. [14:13] jcsackett: thank you! ;) [14:14] abentley, sure. let me fire up mumble. === al-maisan is now known as almaisan-away [15:09] danilos: can you update the description of bug 775691 to clearly describe the low-priority corner case that it is? please [15:10] gmb: i think i have the solution to your problem, and it's netierh #1, #2, or #3 [15:10] gmb: i'm confirming my hunch and writing a reply [15:13] flacoste: Cool, thanks. [15:19] deryck: is there a way of testing whether an object is an lp.client.Entry? [15:20] deryck: I would have thought you could do prototype === prototype, but I get false positives. [15:21] abentley, instanceof will work. [15:21] abentley, x instanceof y [15:21] I don't know if yui 3 has some wrapper around this to make it nicer. [15:23] abentley, so a docs search shows me Assert.isInstanceOf and Y.instanceOf [15:23] deryck: cool. [15:31] gmb: hunch failed... writing reply :-( [15:34] flacoste: Boo. Oh well. [15:47] I'm regularly getting logged out of Launchpad... is that a temporary issue or was some change made to make this happen? [15:48] jkakar, temporary. dbs were flipped around. [15:49] danilos, jtv, neither of you are here, but if you had a better idea on triaging https://bugs.launchpad.net/launchpad/+bug/810309 that would be great [15:49] <_mup_> Bug #810309: Translator credits appear duplicated < https://launchpad.net/bugs/810309 > [15:49] gary_poster: I am here. [15:50] jtv, why for goodness sake? :-) [15:50] gary_poster: I'm in Europe, where it's still more or less working-day hours. [15:50] oh, ok, didn't know jtv [15:51] This bug looks like some kind of nasty loop behaviour between imports and exports. [15:52] gary_poster: Cool, thanks. [15:52] oh, hi jkakar! [15:53] jtv: Hi! :) === salgado is now known as salgado-lunch === beuno is now known as beuno-lunch === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 232 - 0:[######=_]:256 === beuno-lunch is now known as beuno [16:34] * deryck goes offline for lunch, back online in an hour [16:44] * bigjools waves at jcsackett [16:48] heya, bigjools. [16:48] howdy jcsackett. May I push a review in your direction please? [16:48] certainly. [16:48] https://code.launchpad.net/~julian-edwards/launchpad/async-copying-part-2/+merge/67989 [16:49] thanks [17:00] bigjools: r=me. [17:01] jcsackett: thanking you sir === salgado-lunch is now known as salgado [17:11] Yippie, build fixed! [17:11] Project devel build #889: FIXED in 5 hr 59 min: https://lpci.wedontsleep.org/job/devel/889/ [17:19] Yippie, build fixed! [17:19] Project db-devel build #721: FIXED in 5 hr 39 min: https://lpci.wedontsleep.org/job/db-devel/721/ === matsubara is now known as matsubara-lunch [18:04] deryck, gary_poster: a new escalated bug by ISD: https://bugs.launchpad.net/launchpad/+bug/810626 [18:04] <_mup_> Bug #810626: launchpad should mark required sreg attributes as required < https://launchpad.net/bugs/810626 > [18:04] should be fairly shallow [18:04] flacoste, cool, thanks. [18:04] flacoste, cool, yeah, we were asking you about that one on ops [18:04] but it blocks them deploying their new version as it's a potential source of problems for us [18:05] cool [18:05] gary_poster, what will it be? orange or yellow? rock, paper, scissors, lizard, Spock for it? [18:05] i've only marked the one about making the fields required Critical [18:06] since the other one, is only relevant when we handle multiple OPs [18:06] so I marked it Low [18:06] deryck, whoever gets to first :-) we've got a couple of escalated in progress already [18:06] * flacoste thinks Orange should contribute to the escalated effort ;-) [18:06] indeed we can :) [18:07] Yellow has 3 potential fixes for the week [18:07] * deryck didn't realize yellow had escalated bugs already [18:07] yellow hears "escalated" and comes running! It might be...fun, or something?! [18:08] :-) [18:08] flacoste, gary_poster -- we've got a card on orange next lane now for it. [18:09] cool [18:34] bac: because your getnewcache is based on my json-serialisation, merging from devel creates criss-cross merges and screws up the diffs between my branch and yours. Could you please refrain from that in the future? [18:35] bac: And could you please pull my ~abentley/launchpad/getnewcache, where I've fixed the criss-cross? [18:39] deryck: a closer look at the update_cache code shows it's correctly updating the plain json objects, rather than replacing them with Entry objects. [18:41] abentley, ok, thanks for the update. [18:55] Is there an API call I can do to get this list: https://code.launchpad.net/principia/oneiric === matsubara-lunch is now known as matsubara [19:34] SpamapS: Yes: getBranches [19:35] SpamapS: Actually, that's on DistroSourcePackage, not DistroSeries. [19:37] abentley: you got me all excited.. ;-) [19:37] SpamapS: It probably exists as a method, just not exported yet. [19:43] sinzui, I'm about to file a bug about the send-person-notifications script not logging errors to the filesystem. Am I right, or did I simply miss it? AFAIK, one can only get the error reports from the launchpad-error-reports list, which I think is bad. [19:43] gary_poster, I did not find the log. report the bug [19:43] thanks sinzui [19:51] gary_poster: well it should be oopsing [19:51] gary_poster: have you looked for an OOPS yet ? [19:51] gary_poster: changing from stderr to a log file is an RT generally, if its a Launchpad*Script [19:52] lifeless, looked for OOPS: how and where would I do so? I am only aware of a "if you know the OOPS id then you are in luck" interface [19:52] they all get rsynced to carob === matsubara is now known as matsubara-afk [21:23] flacoste: on bug 810623 [21:23] <_mup_> Bug #810623: launchpad oopses when no sreg attributes are returned by SSO < https://launchpad.net/bugs/810623 > [21:24] flacoste: I think we should keep to the oops->critical, but do a real simple fix - make it a UFD or BadRequest [21:24] flacoste: or [21:24] flacoste: close it invalid [21:52] hi all [21:59] lifeless: might want to leave a comment [21:59] deryck's squad can sort it out when they work on the main one [22:00] flacoste: I will, wanted to discuss with you first ;) [22:00] flacoste: so we didn't get in a bidding war [22:00] flacoste: I favour the first case [22:01] lifeless: i'm easy today, so whatever :-) [22:01] heh, ok [22:01] re https://bugs.launchpad.net/launchpad/+bug/807383 in theory it ought to be possible to work out which oops a particular user hit, shouldn't it? [22:01] s//oughtn't it? [22:02] or is it just a case of, if they don't work hard enough to report it we don't have a special bug for it? [22:04] its not easy to find the right one (we log oops *files* for things we don't count as OOPS. [thats a bug]). [22:04] also, we're still swamped, so its not like we're at the point [yet] of picking up the 3 or 4 unique oopses from the daily report and driving them to zero. [22:18] poolie_: actually, another way to put it is: we track all oopses and well get them all eventually; if soneone wants to jump queue - manually filing a bug for us, thats fine, but then the onus is on them to help us out [22:26] right [22:26] that's pretty much what i though [22:26] t [22:35] oh wow [22:35] sinzui: why ? [22:35] New member: [22:35] (Choose…) [22:35] You can't add a team that doesn't have any active members. [22:35] sinzui: adding ~canonical-launchpad-emeritus to https://launchpad.net/~launchpad-emeritus/+addmember [22:36] The most recent 90 minute downtime was the last ever. [22:36] would be nice [22:47] Project devel build #890: FAILURE in 5 hr 36 min: https://lpci.wedontsleep.org/job/devel/890/ [23:00] lifeless, I have never seen that issue show up. I do not know why Lp wont let you [23:00] m [23:01] Project db-devel build #722: FAILURE in 5 hr 41 min: https://lpci.wedontsleep.org/job/db-devel/722/ [23:04] StevenK, mumble? [23:13] sinzui: I think its a mistake, because a team can be emptied after including in another team [23:13] sinzui: any objection to a jfdi fix ? [23:15] please jfdi [23:22] win 24 [23:23] fail? :) [23:23] * StevenK kicks nigelb :-P [23:24] * nigelb has had a sleepless night :/ [23:25] lifeless: When do you want to talk? [23:25] when I get off the phone with allison :) [23:26] 15? [23:29] Sure [23:29] Attack of the TAs? [23:29] :P [23:29] lol [23:30] wallyworld_: What time do you EOD? [23:30] nigelb: i've only just started my day === wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | Critical bugs: 232 - 0:[######=_]:256 [23:30] wallyworld_: I'm about to head to bed on a /very/ late night thanks to work. [23:31] nigelb: do you want to ping me later? [23:31] wallyworld_: Yeah, that's why I was trying to figure out what's your usual EOD to plan that. [23:32] nigelb: ah, right. i'll be here for another 8-9 hours, plus i can be online tonight. there'll be a few hours in the even when i have soccer [23:33] s/even/evening [23:33] wallyworld_: In that case, I think I can figure out something today. I'll keep my devel up-to-date [23:34] nigelb: ok. i'll wait to hear from you [23:35] aaarrghhh. did qastaging just die? [23:39] wallyworld_: Looks fine to me. Maybe it just updated. [23:40] Shouldn't have, though. [23:40] wgrant: it just came back now [23:41] wgrant: could you do me a favour to help me qa? could you subscribe someone (not you or me) to a branch you own and then change the owner to launchpad and let me know which branch? [23:41] lifeless: Do you still only do Skype? [23:43] wallyworld_: https://code.qastaging.launchpad.net/~launchpad/launchpad/db-devel-merge-fix [23:43] wgrant: awesome thanks [23:44] * wallyworld_ marks his bug as qa-ok [23:44] Thanks! [23:44] s/bug/branch [23:45] * wgrant goes to use canonicaladmin for a while, to acclimatise himself to crap software before using Skype. [23:45] lol [23:46] skype isn't that bad. it has pretty good echo cancellation [23:46] seems to work better than mumble often times [23:46] The echo cancellation is the only thing that is not crap. [23:46] Well, and the NAT traversal. [23:46] they're pretty important features, no? [23:47] Yes, but the software itself is crap. [23:47] Crashy, slow, ugly. [23:48] wgrant: its easiest in a bunch of ways, if you don't mind significant feedback I can do voip [23:48] I have Skype not crashing now. [23:48] So we can use it. [23:48] \o/ [23:59] Hi there. I'd like to import the GDB 7.3 release branch into Launchpad. They use CVS and have a GIT mirror. Who should I ask? (mwhudson is away)