[00:04] wgrant: mumble? [00:07] lifeless: I thought expiration was 60 days. That bug was commented 33 days ago [00:08] sinzui: I thought bugs went 'eligible for expiry in X days' and then 'marked for epxiry Y days ago' [00:08] sinzui: I may be misunderstanding [00:09] sinzui: https://bugs.launchpad.net/launchpad/+bug/616704 is a better example [00:09] <_mup_> Bug #616704: Security package copy should copy packages to -updates immediately < https://launchpad.net/bugs/616704 > [00:09] lifeless: Yes that should be expired [00:09] sinzui: (not that that should be in this state, because bigjools was just asking a question) [00:09] but it demonstrates the issue well [00:10] lifeless: The days marked is from the moment it qualifies to be expired...incomplete, un assigned, only one task etc... [00:10] sinzui: so its not 60 + count, its 'will expire when count == 60' ? [00:11] oh, did our db merging of projects break expiration for us? [00:11] yes equality [00:11] the phrasing is confusing then [00:17] o/ lifeless, sinzui [00:21] hi poolie [00:21] sinzui: I thought it used to say 'will expire in N days'. [00:21] sinzui: in fact, I'm pretty sure it does. [00:23] lifeless: it does say that [00:24] sinzui: at what point does it switch to 'marked for expiry' ? [00:25] when all the conditions are met when the status incomplete is set [00:26] https://dev.launchpad.net/MaintenanceRotationSchedule === cinerama_ is now known as cinerama [00:28] sinzui: I don't see anything on that page relevant to this [00:28] lifeless: sorry, that was for teal [00:28] ;) [00:32] sinzui: I think the 'marked for X days ago' turns up on the day it can expire [00:32] sinzui: so I think X days ago is last-changed + 60 [00:32] 702022 Once a project is modified you can no longer modify the status 2011-01-14 [00:33] is 91 days ago [00:33] and it shows 'marked 31 days ago' [00:33] so, if its marked X days ago, it should have expired if bug expiry is working [00:33] lifeless: Changed could be ambiguous. I think there is a specific date, like date_incomplete_without_followup [00:33] date_last_updated | timestamp without time zone | not null default timezone('UTC'::text, now()) [00:34] date_made_private | timestamp without time zone | [00:34] who_made_private | integer | [00:34] date_last_message | timestamp without time zone | [00:34] date_last_message is the one used [00:34] but note that adding a message sets date_last_updated [00:34] so date_last_message can only ever be older than date_last_updated [00:41] lifeless: These three methods look like the issues affecting expiration, but I do not see what is a miss yet: http://pastebin.ubuntu.com/593809/ [00:42] Sorry. I was missing the forth method from bgutaskset:http://pastebin.ubuntu.com/593811/ [00:54] days-before-expiration is unset in prod, so default value of 60 [00:57] enable_bug_expiration = BoolCol(dbName='enable_bug_expiration', [00:57] notNull=True, default=False) [00:57] is a simple lookup on product [00:57] no fancy check-group stuff [00:59] sinzui: it may be something simple, like not running the cronjob [00:59] I was thinking the same [01:00] or [01:01] it may be that its running in a very slow loop over one project at a time [01:01] with 20K+ projects that will perform very poorly. [01:01] I see it in loganberry-launchpad to run "17 04 * * * " [01:01] 10,000 projects have nothing in them [01:01] yeah [01:01] but its still 10K lookups [01:01] when the DB knows [01:01] and can do it in one hit. [01:17] sinzui: it must be getting late for you [01:17] sinzui: when did you want to talk ? [01:18] lifeless. Nothing I have nothing conclusive to talk about it seams. I think teal needs to do a better job watching scope of the tasks it undertakes [01:18] lifeless: Are you available tomorrow? [01:20] sinzui: sure am [01:21] I will ping you tommorow then [01:21] cool [01:21] or maybe tomorrow. [01:21] Tomorrow, when the OOPS ended [01:27] lifeless: lol [01:33] lifeless: :( CPU graphs are odd this morning. [01:33] wgrant: oh? [01:33] cinerama: :) [01:34] lifeless: There was a big drop right after the new appserver was activated, but not long later they returned to normal :( [01:34] wgrant: well, thats to be expected [01:34] wgrant: when the new appserver was turned off [01:37] lifeless: Oh, it was turned off? [01:37] Maybe there was another incident I haven't read about yet. [01:37] ~2am your time [01:37] yeah [01:37] Aha. [01:38] linked in -ops [01:38] Yeah, found it. [01:38] It's still down? :/ [01:39] Hmm. [01:39] Odd. [01:39] we should be able to run the smoketest and so on and bring it up [01:42] lifeless: wgrant: mthaddon: was at the EOD when he decided to take the new server offline. He had made changes to give the server access to the internal librarian, but jelmer and I did not see them take affect [01:43] sinzui: Do you know which rules? [01:43] sinzui: yah, it was the right thing to do [01:43] I suspect the restricted ports were forgotten. [01:43] (I wish we had transparency here) [01:44] wgrant: I think the same, but I do not know for certain [01:45] Hopefully we will run out of fires in a few hours and be able to debug. [02:09] lifeless: I'm looking at a bunch bugs related to user profiles. Would it be appropriate to tag these all with "profile" or something? [02:09] huwshimi: if you like [02:09] huwshimi: basically, if its useful to you, do it. [02:10] lifeless: Just in regards to your email, I don't want to add more clutter (I know this is not an official tag). [02:10] huwshimi: folk that are trying to avoid scope creep will often not want to fix clusters of bugs (because the cluster can include a ringer) [02:10] huwshimi: I have no objection to large numbers of tags [02:10] huwshimi: official tags are special because they always show up everywhere, even if not used much (or used so much they are not valuable, like the lp-* ones) [02:11] huwshimi: I hope that helps [02:12] lifeless: Yes, thanks. [02:21] mwhudson: hey [02:21] lifeless: hello [02:21] mwhudson: does the branch rewriter script have a db statement timeout ? [02:21] I suspect it doesn't [02:22] lifeless: i believe not, i think there may be a bug for this already [02:22] there is [02:22] its critical [02:22] I'm proposing to make it 500ms [02:22] how badly will the rewriter handle a timeout exception ? [02:22] as in, will it die [02:22] or shrug and move on? [02:23] lifeless: i don't know, i'd have to look at the code [02:23] mwhudson: it looks like it will be ok to me. [02:23] actually, i'm pretty sure it will shrug [02:44] mwhudson: do you think this needs tests? http://pastebin.com/3HHjiQkL [02:44] mwhudson: [please say no] [03:02] lifeless: i dunno, could you monkey patch _getBranchIdAndTrailingPath and check that there is a request when it's called? [03:03] mwhudson: I could, but it seems like a comment at the call site is as good insulation === almaisan-away is now known as al-maisan [07:47] lifeless: Is that bug about strikethroughs on closed bugs now a duplicate of bug #1924 now that we've changed the description? [07:56] huwshimi: indeed === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews [08:12] Should this bug be unassigned:https://bugs.launchpad.net/launchpad/+bug/58784 ? [08:12] <_mup_> Bug #58784: Spec page refers to non-existent "Specifications in grey"

< https://launchpad.net/bugs/58784 > === Ursinha is now known as Ursinha-afk [08:17] heh [08:17] I suspect so [08:40] wgrant: dunno about you but today was a write off [08:43] I managed to get 1.5 branches done. I was aiming for 2.5 [08:46] lifeless: Yeah, it was pretty hopeless. [08:46] I'll hopefully get some stuff done tonight, though :/ [08:49] StevenK: nice [09:01] Project devel build #638: FAILURE in 5 hr 5 min: https://lpci.wedontsleep.org/job/devel/638/ [09:09] good morning [09:12] Not really. [09:13] wgrant: Everyone's a bundle of laughs tonight :) [09:13] morning === al-maisan is now known as almaisan-away === Ursinha-afk is now known as Ursinha [09:34] huwshimi: hi [09:35] jml: Hey mate [10:36] anyone know a way of making pdb break on a class? [10:38] on definition? [10:38] or construction ? [10:46] lifeless: running any code inside a class [10:46] it seems to want either filename:lineno or a function [10:46] yeah [10:46] the best I can do is put the class in its own file [10:47] probably won't do base classes for you [10:47] which is exactly what I want :/ [11:07] If I have an object that inherits from IHasOwner, I can't seem to use a custom launchpad.Edit security adapter because the EditByOwnersOrAdmins adapter is used - is there a way around that or do we have to just not use lp.Edit? [11:28] jtv: Hi! [11:28] hi [11:28] jtv: I forgot: what is needed to trigger pottery processing on a branch, i.e. automatic template creation? [11:28] jtv: I know the branch needs an intltool setup. What else? === almaisan-away is now known as al-maisan [11:29] jtv: Is that usable for projects? [11:29] henninge: template imports enabled, POTFILES.in present, can't think of anything else right now. [11:29] Also, I'm not here. [11:29] jtv: thanks ;) [11:45] bigjools: sorry, I don't know the answer. perhaps curtis/benji or gary would be good folk to ask [11:46] lifeless: thanks, we can work around it my removing IHasOwner [11:47] bigjools: perhaps justhave a more specific class first ? [11:48] lifeless: yeah it's almost certainly down to ordering, but inherited classes come first it seems, not much you can do === henninge is now known as henninge-lunch [12:18] bigjools: I marked the DSDs-with-identical-versions fix as qa-ok since it's safe to deploy, but haven't done proper Q/A on it. [12:18] Ah. [12:18] jtv: I literally just tested them ok [12:18] There it goes. [12:18] :) [12:18] Thanks. [12:25] Damn I hate it when this happens. Spend hours chasing down a report of a tiny memory leak in libpqxx against one particular postgres version, and it's just valgrind crying foul murder over libnss caching two layers down. :/ [12:25] allenap, hi, are you OCR today? ;) [12:25] danilos: Yep. Whatchagot? [12:26] allenap, a nice little JS branch: https://code.launchpad.net/~danilo/launchpad/bug728370-descriptions/+merge/57656 :) [12:27] danilos: Tip top. [12:27] allenap, thanks :) [12:44] allenap, I'll be logging out and back in, should be back shortly (if xchat keeps working with gnome3 running :) [12:44] danilos: Hehe :) No worries. === jkakar_ is now known as jkakar === henninge-lunch is now known as henninge [13:17] henninge: hi. there's a few translation imports that need reviewing. i'm not sure how to do that. are you or jtv still the best ones to ask? [13:18] wallyworld: probably. and danilos ;) [13:19] henninge: the last time i checked i don't think the required doco on what to do for us noobs had been fully developed? [13:20] wallyworld: I thought jtv had written something up. [13:22] henninge: yes, right you are. i'll take another look through it [13:26] henninge: "For now, if you get a request to review and approve a translations upload, it's still best to forward it to one of the former Translations crowd: Danilo, Henning, and Jeroen". i'll give it a go but be prepared that i may need to as questions :-) [13:41] allenap, hi, having any questions about the branch? [13:42] danilos: None yet; I just had my lunch :) I'm going through it now. [13:42] allenap, ok, thanks [13:45] wallyworld: we can look at a couple of them now if you want but I'll have my stand-up call in 15 min [13:46] henninge: it's ok. i'm reading through all the doc i can find. i'll see how i go and perhaps ask tomorrow if i get stuck. i just don't want to do something dumb [13:47] wallyworld: there are 13 entries in the queue so it should not be too hard [13:48] henninge: yep. and some are not that old so may yet be done by the cron job [13:49] wallyworld: possibly. Let's have a look at it together tomorrow. [13:50] kk [14:05] beuno: did you write up UI guidelines for Launchpad? [14:06] mpt: did you write up UI guidelines for Launchpad? Do they still exist? (I know of UserInterfaceWording only) [14:07] jml, nothing besides: https://dev.launchpad.net/UI/ [14:07] beuno: thanks. === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | https://code.launchpad.net/launchpad-project/+activereviews [14:08] jml, I wrote (sorry, Canonical-only link) in 2008, but didn't have the opportunity to propose them as LP guidelines [14:09] mpt: ok, thanks. [14:09] (Actually, most of that's from 2006) === Ursinha-afk is now known as Ursinha === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett, allenap | https://code.launchpad.net/launchpad-project/+activereviews [14:29] jam: Would you mind reviewing https://code.launchpad.net/~jstpierre/loggerhead/css-changes/+merge/56393? I don't really understand what he's doing :-/ [15:01] allenap, jcsackett: could one of you please review this mp: https://code.launchpad.net/~adeuring/launchpad/bug-746460-productseries/+merge/57685 ? [15:02] adeuring: sure [15:02] jcsackett: thanks! [15:04] jml: can we chat about bug #758857? [15:04] <_mup_> Bug #758857: Linked branch in translations sharing details page shows branch URL without lp:// prefix

< https://launchpad.net/bugs/758857 > [15:07] abentley: sure [15:07] jml: mumble? [15:07] abentley: yep. [15:08] allenap: I'll give it a shot, though if his screenshots are accurate, something is wrong [15:08] jam: Cheers :) === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | https://code.launchpad.net/launchpad-project/+activereviews [15:15] jcsackett: Hi, could you have a look at https://code.launchpad.net/~rvb/launchpad/fix-package-diff-equal-versions/+merge/57686 ? [15:16] rvba: sure, it's next in the queue. :-) [15:16] jcsackett: great. [15:17] abentley: https://launchpad.net/ubuntu/natty/+source/ssss/+edit-packaging [15:18] abentley: https://bugs.launchpad.net/testtools/+subscriptions [15:19] bigjools: do you have any insight into question https://answers.launchpad.net/launchpad/+question/151985 [15:20] looking [15:20] sinzui: I could not reproduce that locally with what I believe to be a broken sudo. [15:20] I may try harder to verify the bad umask. [15:21] it is certainly very coincidental with the broken sudo [15:25] sinzui: since it's happening as far back as lucid, I suspect it's not the broken sudo actually. [15:26] he's probably found a new bug, but my knowledge of recipes is not good enough to help without spending more time on this [15:26] bigjools: I was thinking this permission issue related to the umask problem last week, but lamont believes that is fixed [15:26] sinzui: the umask was done to paper over the sudo problem AFAIK [15:27] and yes it was fixed [15:27] fairly quickly :) [15:27] it was natty only [15:27] bigjools: understood [15:28] adeuring: r=me. [15:28] sorry I can't be of more help [15:31] bigjools: It wasn't natty-only :( [15:31] bigjools: It's the system sudo. [15:31] ah ok, thanks, I misunderstood then [15:32] so it was the sudo outside the chroot? [15:32] Right. [15:32] oh dear [15:32] In the original incident a few weeks ago only natty was majorly affected, because it was the majority of the builds. [15:40] rvba: r=me. [15:41] jcsackett: thanks. === al-maisan is now known as almaisan-away [15:48] allenap, hi, responded to your review :) I'd like to get your comments before I proceed to land this, because I mostly haven't changed anything (did say why not :) [15:49] allenap, also, I just checked, the slide-out/in effects take 0.4s, which is why 0.5 worked for me consistently [15:51] danilos: Cool, I'll take a look. [15:58] allenap, sorry if I missed anything you said, gnome3 crashed with keyboard layout change :/ [15:58] danilos: Hah, no. [15:59] danilos: setup_bug_subscriptions() calls fill_in_bug_subscriptions() which appends to a list that *is* in the page's DOM. [15:59] allenap, right, but it doesn't get called before show_* function is called, and that one is called in 'domready' [15:59] danilos: Oops, I get it. [16:00] allenap, I originally had it inside 'domready' but figured there's no need... perhaps a comment would do :) [16:00] with "would do" == "is a must" ;) [16:03] danilos: Thanks for the response though. I'm still not a fan of using IDs as much as we do, but it's interesting to hear other people's approaches :) [16:04] allenap, heh, yeah I'd love them even more if web page somehow failed to render if you've got duplicate IDs [16:07] gary_poster: do you have time for a pre-imp call? [16:08] adeuring: yes, in...15 min or so? Is that ok? [16:08] danilos: You said that there's no way for a browser to use a selector, except when a browser has the Selectors API. Can they not fall back to XPath? I assumed that's what YUI, jQuery, et al did. [16:08] gary_poster: sure, thanks! [16:08] np, talk to you then [16:09] danilos: Perhaps I should code up a cheeky checkers that does a document.write("

Boom!

") when duplicate IDs are found ;) [16:09] allenap, yeah, selectors API is the querySelector* stuff; I assume that gets much easier for the platform when you narrow the scope because it's not just IDs it has to go through [16:09] allenap, heh, I wouldn't mind :) [16:10] allenap, anyway, I personally feel better asking in a more constrained set, perhaps it's totally irrelevant, but please don't make me do it in the entire document scope! pleaaaseee! ;) [16:11] allenap, also, doing it on a node is a sanity check at the same time: you haven't moved the element someplace else [16:12] danilos: I agree, always start from the narrower scope. Although I suspect that query by ID might be quicker in document scope (because the browser may optimize for that case), I think the difference is going to be minimal. [16:13] allenap, yeah, but there's also getElementById on the DOM node, so that should be even faster :) [16:15] allenap, btw, I've added a comment explaining the sequence of events, and now I am going to ec2 land the branch :) thanks again for the review! [16:15] danilos: Cool, and you're welcome :) [16:16] adeuring, actually I'm ready now. I was overestimating for once, it seems. :-) I'm on Skype (garyposter) and mumble. mumble is sometimes weird for me, but sometimes its fine, so either is worth a try. :-) [16:16] gary_poster: cool. shall we mumble? [16:16] sure [16:17] I'm in Yellow: 1-on-1. Join me or drag me somewhere [16:26] benji: ping. [16:38] does anyone know how to restrict version when exporting a webservice collection? i know you can use as_of when exporting an entry, but that's not supported for collection. [17:00] sinzui: can you chat for a few minutes? [17:00] yes [17:08] jcsackett: Do you mean a resource type? Or an attribute of an object that is a collection? [17:08] abentley: the former, i think. e.g. exporting IQuestionSet using "export_as_webservice_collection" [17:09] jcsackett: It's a known issue that there is no way to restrict that to a particular version. [17:09] abentley: dig. thanks. [17:12] abentley: is there a bug already filed for it, do you know? i can't seem to find one for on lazr.restful [17:13] jcsackett: don't know. [17:13] abentley: okay, thanks. i'll dig around a bit. === salgado is now known as salgado-lunch [17:31] sinzui: i have put up the MP and requested you as reviewer. https://code.launchpad.net/~jcsackett/launchpad/api-wants-questionset/+merge/57723 [17:31] jcsackett: thanks === beuno is now known as beuno-lunch [17:51] jcsackett: another small fix ... could you have a look? https://code.launchpad.net/~rvb/launchpad/fix-packagediff-request-link/+merge/57727 [17:52] rvba: sure [17:59] rbva: r=me. i mention in my comment there's an alternative way to do some of your testing, but it's just a suggestion, not block to landing. [17:59] jcsackett: thanks, I'll have a look right now. [18:01] jcsackett: it's a nice suggestion ... I think I'll keep it this way because I've factored the 2 asserts in a method that does a little bit more than just testing ... but I'll definitely do it next time. [18:02] rvba: dig. [18:30] Project windmill build #174: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/174/ === Ursinha is now known as Ursinha-afk === beuno-lunch is now known as beuno [19:01] gary_poster: about the canAccess(), canWrite() methods we discussed: Any suggestions for an exception that should be raised if the number of participations is wrong? [19:01] gary_poster: ValueError sounds quite generic to me... but I have no better idea [19:06] adeuring: if the number of participations in the current interaction is wrong, that is a NotImplementedError from the perspective of what we discussed before [19:06] Because if you make your own interaction, you can get the answer irrespective of the current one. [19:06] So there is a fix for this [19:06] gary_poster: ah right, seems that it is too late here to ask such questions ;) [19:07] We just are not bothering with it for now. [19:07] :-) np at all === salgado-lunch is now known as salgado [19:52] jcsackett: do you have a moment to mumble? [19:52] i do. [19:54] morning [20:02] abentley: lp:~adeuring/launchpad/api-query-permissions-on-object (not yet submitted for review; will do that tomorrow -- it's alread 9pm for me) [20:03] adeuring: cool. [20:06] sinzui: http://paste.ubuntu.com/594169/ [20:32] Project windmill build #175: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/175/ [20:37] flacoste: hi [20:38] hi lifeless [20:39] so, major outage [20:39] I think we should talk about this on the blog [20:44] lifeless: the switch thing? sure, care to write something? otherwise, we could ask mrevell, but he will need guidance [20:44] I'll write something in mail and send it to a couple of internal lists for commentary [21:21] sinzui: changes pushed to the review branch. [21:21] i've also started in on the launchpadlib thing. [21:24] jcsackett: thanks [22:02] morning [22:24] jcsackett: r=me [22:28] jcsackett, the questionset api might be good to mention on the blog as a new feature [22:32] poolie: indeed. but first, finishing it. :-P [22:33] sinzui: thanks for the review. :-) [22:35] poolie: We cannot do anything with the questions, nor can you search for them. It is only useful for hiding a comment on a question you know exists :(. I hope to hack on the seaarch and workflow methods of the next two weekends to make something I can personally use [22:38] heh, ok [22:38] you can't even look at them if you know the number? [22:39] poolie: let me check. I think we can do that in prod right now [22:40] it looks like you can, if you guess the url [22:40] (which is not so hard) [22:41] yep [22:41] I want to get the questions for a project or a group of distribution source packages [22:43] that would be useful [22:43] Indeed. I cannot see all the open questions for all the things I am an answer contact for [22:45] sinzui: do you know how the ProductWithLicense SQL expands to? [22:45] iow, how to i get the related rows as an array column in the main query [22:46] I do not know [22:46] flacoste: I think I want to make that query obsolete. [22:46] ok [22:46] flacoste: more graphs? [22:46] lifeless: yep :-) [22:46] flacoste: oh, and did you have a chance to look at the uncommitted changes stub removed ? [22:46] from the PPR tree [22:47] lifeless: not yet, but i'll get to it [22:47] flacoste: no rush :) [22:47] I am sitting on data that provides the missing licenses for about 800 projects. I then want to set the remaining projects to have I_DONT_KNOW [22:47] i think it's fine [22:47] monday hopefully we can change the timeout again [22:47] since i recall commiting it at some point [22:48] i want to show # of unreviewed projects [22:48] and track the 'special' licenses one separately from the regular ones [22:48] flacoste: I remember what I wanted to ask you [22:48] flacoste: bug count aggregates, what were your thoughts [22:49] lifeless: ideally, i think exact below 50 is desireable [22:50] above that it can be fuzzy [22:50] i liked the render fuzzy, get exact number async [22:50] approach [22:50] but i'm also fine with fuzzy only [22:51] I think there are a few ways we can be really precise [22:51] I think its not worth it in the short term [22:51] - the polls are pretty seriously weighted towards speed [22:52] - precision will definitely still have a cost === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews [22:54] lifeless, will the system know if the number is fuzzy? [22:54] james_w: in principle yes [22:55] so the rendering could include that information? I think that would help alleviate some concerns [22:55] "3 bugs" vs "about 500 bugs" [22:55] yes, thats one way to handle it [22:55] I agree its not ideal to present a wrong count as fact; however... [22:56] note that /all/ our counts are usually wrong by the time someone clicks through. [22:56] still doesn't help if you want to know the exact number, but avoids confusion if you click what looks like a precise number to find a different number of results [22:56] well [22:56] on some projects [22:56] james_w: we have broken memcached rules [22:56] james_w: before you guess at the cause. [22:56] james_w: we cache private results as publically visible, and anonymous likewise. [22:57] james_w: for these portlets specifically. [22:57] We noticed last week. [22:57] Its been like that for ... some time. [22:57] ok [22:57] james_w: I'm trying to separate out: [22:57] - things we can do to make it better than it is now [22:57] - things we must to do to increase performance [22:58] So while I accept and agree that putting tasteful caveats around the place, (?) popups and so on are all good things [22:58] I am not convinced that they are necessary to make switching to precalculated aggregates a net win. [22:59] And if something is a net win, I think we should take an iterative approach rather than biting off more than needed. [22:59] drive velocity up and get out of the 200+ critical bug zone. [23:00] bac: around? bug 753965 needs qa [23:00] <_mup_> Bug #753965: An IStructuralSubscriptionTarget that does not use LP for bug tracking should not present a subscription link < https://launchpad.net/bugs/753965 > [23:00] abentley: likewise - Fixes: Bug:702477 [23:03] http://pastebin.ubuntu.com/594235/ is what i came with [23:03] any other suggestions [23:03] ? === salgado is now known as salgado-afk [23:13] flacoste: looking [23:13] Project devel build #639: STILL FAILING in 5 hr 35 min: https://lpci.wedontsleep.org/job/devel/639/ [23:14] flacoste: seems reasonable to me [23:15] mtaylor: poolie mentioned a jenkins issue you're having? [23:15] lifeless: yeah- I can't remember what it was right now [23:15] he showed me a java log [23:16] looks like slave reuse race condition to me, not a bzr plugin issue [23:16] IMBW [23:26] Project windmill build #176: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill/176/ [23:36] lifeless: i was going to test "recipe request daily build script triggers OOPS on disabled archive" but getting the make_daily_builds script to be run on qas and check the log. you don't think this is needed? [23:36] wallyworld_: I think its fine not to - I looked at the change [23:36]