[00:17] wgrant: StevenK: it seems IBugSet.createBugWithoutTarget() is only used internally by createBug(), it doesn't seem to be exported, there is a doctest for it. i'd like to remove the method from IBugSet. thoughts? [00:18] wgrant: Right. Now if only I can get the last couple of tests passing ... [00:18] cjwatson: What's broken? [00:19] wallyworld_: I believe that used to be used by the email interface, but it's not any more. Destroy. [00:20] wallyworld_: I deliberated avoided removing it last month because the email interface uses it. [00:20] wgrant: yay, will allow me to simplify the AAG branch and fix failing tests [00:20] doctest hatred of some kind in xx-archive and xx-ppa-files. (Not in front of the laptop right now - I'll have another crack at it tomorrow) [00:20] But now you've made me check and it doesn't actually use it any more. [00:20] cjwatson: Ah, right. [00:20] Maybe it was too ambitious to change the default for allow_delayed_copies. [00:20] cjwatson: I imagine the diff should be fairly small? [00:20] Not horrible for what it does. Several layers of tentacles. [00:21] Since the new unembargo option needs to go all the way up to the webservice layer. [00:22] Yeah [01:39] wgrant_: https://code.launchpad.net/~cjwatson/launchpad/change-override-forbid-release-stable/+merge/110942 is that changeOverride bug-fix you asked for [01:40] cjwatson: thanks for the 10GB reply [01:40] cjwatson: the alternative to debdelta is !debsatall, which isn't something we've had much discussion on. [01:41] I confess I've never heard of it. [01:41] No relevant Google hits. [01:42] I think the short answer on debdelta is that it would be done by now if only mvo had any spare time. [01:43] cjwatson: I meant, not using debs, not a specific thing :) Unless of course you got that and ran with it :> [01:43] So sticking somebody reasonably clued on it for a couple of months ought to be enough to get it thrashed out. [01:43] Oh I see. [01:43] debdelta will probably be quicker, and will have widespread benefits if we get it done. [01:44] cjwatson: canUploadToPocket and checkLegalPocket seem pretty similar to cannotModifySuite [01:45] More specifically, they all duplicate the Release-is-immutable-in-stable-series logic. [01:45] cjwatson: sure. I'm a little worried about failure modes like 'user edited a file' [01:46] cjwatson: which something a little more dynamic in nature could deal with rather more gracefully than we can today. [01:47] wgrant_: Yes, I wasn't sure how far I should go in refactoring that swamp [01:47] cjwatson: That's putting it nicely. [01:48] wgrant_: But I take it you want to go a bit further? [01:48] cjwatson: I'd extend canUploadToPocket to do this. But you don't have to if you don't want. [01:49] In particular I wasn't sure whether it would be a good idea to change the behaviour of the publisher to avoid touching anything that canUploadToPocket refuses. [01:49] It's less obvious that it's correct for the publisher to do that. [01:49] I think it probably is correct for changeOverride to use canUploadToPocket, however. [01:49] checkLegalPocket is semantically closer, but has a less near to being helpful interface. [01:50] canUploadToPocket's name is just crap [01:51] checkLegalPocket is a publisher-specific method which should be somewhere else and implemented in terms of canUploadToPocket [01:54] OK. I'm happy to rearrange it in terms of canUploadToPocket. [01:55] But it looks fine apart from that, so if you don't care enough to fix it I will +1 === wgrant_ is now known as wgrant [02:00] Nah, I'd rather get it as right as possible first time [02:17] worth a read - http://shirky.com/writings/group_enemy.html [02:29] lifeless: the middle section makes me think of time [02:29] * daker has quit (Ping timeout: 246 seconds) [02:29] oh ffs, twice today! [02:29] lifeless: http://xkcd.com/1043/ [02:30] mwhudson: LOL [02:31] there is something that's changed in precise (i think inside ff) that really screws up my clipboard experience [02:31] mwhudson: do you have a three button trackpad ? [02:31] or hmm, three button nipple ? [02:32] bigjools: wallyworld_: HUSH. [02:32] lifeless: i do, but i use an external keyboard & mouse almost all of the time [02:32] ok, cause I find the middle button of the three connected to the nipple extremely frustrating to use [02:32] huh? me has said nothing [02:32] (i certainly can't blame either of today's stuffups on the thinkpad) [02:32] wallyworld_: no, but you usually do :P [02:33] nipple is the correct term [02:33] ah, guilty by assumption :-) [02:33] just don't flick your tongue over it [02:33] lol, knew i could proxy to bigjools :-) [02:36] see [02:37] exactly my point [02:38] wallyworld_: Are you sure that new query is good? [02:38] It looks broken to me. [02:38] in what way? the tests pass [02:38] It seem like it'll find people with *any* team participation that doesn't have permission. [02:39] Rather than finding people where *all* team participations don't have permission. [02:39] lifeless: it's an interesting article, i've read it at least once before but that was before "facebook" and "twitter" were words that appeared on the 6pm news... [02:39] wgrant: let me look [02:40] wgrant: Happier with this try? It's rather more verbose, but gets rid of duplicate logic in several places now. [02:41] (E.g. it rephrases checkLegalPocket mostly in terms of canUploadToPocket.) [02:42] wgrant: at first read it looks ok - not(a or b) = not(a) and not(b) [02:42] wallyworld_: Sure, that bit of the logic is fine. [02:42] wallyworld_: But you're joining against TP [02:43] You want to find people where all the teamparticipations match the OTs. [02:43] s/OTs/NOTs/ [02:43] But that query will find people where any of them do. [02:44] yes, that seem true [02:44] eg. if foo is a member of bar and baz, and bar has access but baz does not, the query will say foo doesn't have access. [02:44] so i need a extra constraint [02:47] a GROUP BY with HAVING(COUNT(teamparticipation) = 0) is probably clearest [02:47] But it's horrid [02:47] Which is why I suggested inverting the method and doing the difference in Python [02:47] It's more useful and far simpler. [02:49] but it's python and the results could be large, they may not be, but we can't guarantee that [02:49] wallyworld_: Not really. [02:49] We're passing in a set of people [02:49] The set we get back out will be at most that large. [02:49] And it's probably only a set of ints. [02:49] ok, i can rework it [02:50] cjwatson: Looking, sorry [02:50] wallyworld_: Unless you want to do a set of horrid left joins with group by and having, that's probably best. [02:50] But you can do it all in SQL if you really wanr. [02:54] cjwatson: Should cannotModifySuite be replaced too? [02:54] If you're feeling adventurous, canUploadToPocket would be even better as Archive.canModifySuite [02:56] cjwatson: But that's an excellent improvement, thanks. [03:06] wgrant: cannotModifySuite> Doesn't that go back to the conversation above? [03:06] 02:49 In particular I wasn't sure whether it would be a good idea to change the behaviour of the publisher to avoid touching anything that canUploadToPocket refuses. [03:06] 02:49 It's less obvious that it's correct for the publisher to do that. [03:07] I'll look at refactoring it into Archive.canModifySuite tomorrow [03:09] cjwatson: That's a good point, ignore me. [03:09] * wallyworld_ sighs. i may triggered the branch scanning bug again :-( [03:09] cjwatson: But moving the archive-related stuff onto Archive is a good thing; should have been done during ArchiveRework in 2006 :) [03:09] So please move that if you have a moment. [03:10] wallyworld_: Was an MP involved again? [03:10] yep [03:10] :( [03:10] Missed the first run [03:11] Was hoping we could actually see what was going on there. [03:11] spm: Not at lunch, are you? [03:11] am back now, but about to be exclusively doing stuff [03:11] Ah, k [03:11] Nevermind, then. [03:15] * wallyworld_ taps fingers. branch scanning seems to be taking forever [03:16] wallyworld_: It just retimed out a few seconds ago [03:16] Your new push should process in a sec [03:16] hope so [03:16] It's scanning [03:18] Done [03:18] branch pages doesn't seem to think so [03:19] ah now it does [03:20] Hm [03:20] It's rescanning the original one now, for the third time. [03:20] Did you repush it? [03:21] nope [03:21] wgrant: if you could peek at this, much appreciated https://code.launchpad.net/~wallyworld/launchpad/create-aag-privacy-transitions-followup2/+merge/110945 [03:25] wallyworld_: Looking [03:25] thanks [03:26] wallyworld_: r=me, thanks. [03:26] Although neither the MP nor commit message nor any of the other commit messages actually say what the issue is :) [03:26] wgrant: thanks for spotting the issue [03:28] wgrant: All right, since sleep continues to elude, I've done that move now - and landing, since I see you approved it already (thanks) [03:30] cjwatson: Marvellous. [03:30] Apart from the not sleeping thing. [04:56] * StevenK headdesks. [04:59] ? [05:01] wgrant: I ran make schema and was then going to run the garbo tests again and managed to fat finger make clean && make schema somehow. [05:01] Heh [05:04] TDD on LP really sucks [05:04] Just saying [05:33] wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-branch-ap/+merge/110950 [06:22] EWTF 7878.23s OOPS-ebfdc5eaa4642ee738b09283e0964a82 BranchSet:CollectionResource:#branches [06:24] wgrant: have you looked into https://oops.canonical.com/?oopsid=OOPS-f08635d8a0548f5b1bafb1bb0209c980#repeatedstatements ? [06:30] lifeless: Heh [06:30] I didn't think it would ever get that bad. [07:26] morning [07:50] good morning [07:57] wgrant: and yet... [09:09] Add one query per request, and 5 tests fail. We have some sensitive query counts in there... [09:16] Bump 'em by one, and they will be less sensitive when 1 request ends up being removed from every request in a future landing. [09:26] Make them equality tests rather than maxima? [09:26] dpm, jtv: I'm looking over the Q translations, I'm running into a couple things. The #contributors doesn't match between Q and P, but maybe that is the Garbo job, or maybe just newer stuff? [09:27] I'm getting timeouts trying to load the actual page, but it does eventually load. [09:27] for example this: https://translations.launchpad.net/ubuntu/precise/+source/gfxboot-theme-ubuntu/+pots/bootloader/es/+translate vs https://translations.launchpad.net/ubuntu/quantal/+source/gfxboot-theme-ubuntu/+pots/bootloader/es/+translate [09:27] The checkboxes are also a bit different. [09:27] On P it defaults to 'New translation', but on Q it is marked on "Current Spanish". [09:28] Though aside from the first, the pages seem identical. [09:28] jam: otp [09:28] jtv: np [09:32] so aside from the Contributors stuff, all the pages I've looked at for specific translations have been identical between P and Q [09:33] jam: back. The contributors are updated by the garbo job, right. [09:34] jtv: so on this page: https://translations.launchpad.net/ubuntu/quantal it seems to say there are 237045 untranslated strings for Bosnian, but when I go: https://translations.launchpad.net/ubuntu/quantal/+lang/bs it only lists 37371. Maybe I'm not looking at the right page? [09:35] jam: the checkboxes sound strange… it may be an unanticipated side effect of Quantal translations still being closed. The important thing is that you get identical items between P and Q, both labelled Current Spanish, with the same text. [09:35] The statistics are also updated asynchronously, so don't rely on those.\ [09:35] jtv: yeah, the checkbox seems to be if Firefox puts the cursor inside the text entry box [09:35] * jtv looks at pages [09:35] jtv: how asyncrhonously? Given the copy happened last night [09:35] ! [09:36] jtv: we were able to get the copy to succeed yesterday around 14:00 utc [09:36] Actually I guessed from what you said earlier, but it's nice to have that part be such a non-event. [09:36] How long did it take? [09:36] jtv: well, we had some old 'temp_' tables that required st-ub to fix [09:36] Ah yes. [09:36] but then the copy happenid in about 5 min [09:37] vs the 1.5hrs to get the delete script to run [09:37] There'll be less of that holding-table business. [09:37] (about 3 retries) [09:37] Five minutes! It's hard to express how happy that makes me. [09:37] jtv: I don't have the background to fully appreciate it, but yes, very quick vs what it looks like in the past. [09:37] Do note that please on the wiki page. [09:37] Already been noted [09:38] but it will be highlighted later. === gmb changed the topic of #launchpad-dev to: grahambinns [09:38] Arse [09:38] I'm personally satisfied enough that the copy completed correctly. As you expected, the statistics are all wrong, but the strings all look correct. [09:38] Well… 2007: take Launchpad offline for the copy. 2008: strain the app to its limits for I don't remember how many days as we copy dozens of millions of rows. [09:39] gmb: LOL! === jam changed the topic of #launchpad-dev to: The topic for #launchpad-dev is: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 === gmb changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: gmb | Firefighting: - | Critical bugs: 3.47*10^2 [09:39] * gmb needs to remember that he sucks at IRC. [09:39] meh could in fact be worse [09:39] you in the Fin? [09:39] Also, I need to write a bot for taking ReviewerSchedule and updating the topic (because I do this crap on a regular basis) [09:40] czajkowski, Yep. It's massive! [09:40] I feel tiny [09:40] gmb: And a bot that says “good morning, volunteer!” as you log in on your review day. [09:40] Quite [09:40] jtv: definitely well done [09:41] jam: those Spanish translations look fine to me. I won't say there's no problem anywhere, but it passes the basic sanity test that really matters right now. [09:41] gmb: aye it is nice alright [09:41] jtv: I haven't found a page with translations strings that aren't identical. [09:41] Just "Contributors" for a given entry, etc. [09:41] and the summary of "Untranslated" doesn't quite match. [09:42] but all those are summary statistics stuff. [09:42] The credits should start to fill in, but one of the breakthroughs of this year is that that is now a separate problem. [09:42] jtv: so its says the next step is activating the translation imports. Does it seem reasonable to do so? [09:42] The only numbers you can trust, really, are on the batch navigator for a page — e.g. 1234 items in the “translated items” view. [09:43] jam: I would say so, and I'm sure dpm would be much relieved. Ask him to tell you some stories as well. :) [09:44] * dpm reads scrollback... [09:44] jam: it's useful to note when the imports are started, because that way we can more or less track in the UI whether a full generation of translations has been imported yet. [09:44] Bon dia dpm :) [09:45] jam: and now for a short intermission between self-congratulation sessions… I see Approved items on the import queue for Quantal, but they're not attached to any files to import to. That looks like an omission in the cleanup script. [09:45] If we enable imports, that will break. [09:46] jtv: I don't quite follow your thread, links? [09:46] https://translations.launchpad.net/ubuntu/quantal/+imports [09:46] These are the files awaiting import into Quantal. [09:46] Approval, in translations-import-queue terminology, is a bit of a misnomer. [09:47] It also involves attaching an upload on the queue to a POTemplate or POFile in the database that it's supposed to go into. [09:47] (There must be one; these objects are created as part of the approval process). [09:47] For most files, it's the import queue gardener (rosetta-approve-imports.py) that does this. [09:48] And the importer assumes that any file it's going to import will already have been approved, and so is attached to a POTemplate or POFile. [09:49] So we need something like: [09:49] UPDATE TranslationImportQueueEntry SET status=5 WHERE status=1 AND distroseries = (SELECT id FROM DistroSeries WHERE distribution=1 AND name='quantal'); [09:49] Let me just ask about that on -ops. [09:50] jtv: That's not doable through the API nowadays? [09:50] Hmm… it might be, but I imagine not on a batch basis. [09:51] Certainly not on a batch basis, no [09:52] jtv, jam, having a quick look at P and Q, the translations look ok, but I'm also concerned about the mismatch in the number of contributors. Apparently we got +100 contributors on Q according to LP, which is certainly not the case [09:52] gmb: Oh hello Mr. OCR. There's a question for you in https://code.launchpad.net/~cjwatson/launchpad/export-change-override/+merge/109549 [09:52] sorry, I mean for Catalan [09:52] it might be different for other languages [09:53] dpm: most of the ones I've seen have almost 2x the contributors in P than Q [09:54] cjwatson, Looking now. [09:54] dpm: I'm seeing P having 145 more contributors, how are you getting 100 more in Q? [09:54] dpm, jam: it'll take garbo some time to derive all that contributor information. Try looking at templates whose names start with numbers, or 'a'. [09:55] jtv: the first one is "Abkhazian" which matches (with 0 contributors), but Acehnese is 55 in P vs 18 in Q [09:55] Template names, not languages. [09:55] ah [09:56] mwhudson, do you need me ? [09:56] jam: also, if the daily garbo job was interrupted for this… [09:56] jam, sorry, you're right, I was looking it the other way round -> https://translations.launchpad.net/ubuntu/quantal - Catalan: 216 contributors, https://translations.launchpad.net/ubuntu/precise - Catalan: 318 contributors [09:57] so Q is 102 less contributors [09:57] dpm: well that number just jumped from 20 min ago [09:57] than P [09:57] for Q [09:57] It was 155 just a bit ago [09:57] jtv: it was interupted before the copy, but should be running today. [09:57] dpm: so the number seems to be going in the right direction [09:57] gotcha [09:58] Well, there we go then. :) [09:58] cjwatson, Okay, it looks like copy_field isn't doing what it should. Revert to your earlier solution and add a comment explaining why you're not using copy_field. r=me on everything else. [09:58] jtv: currently OTP, but I want to sort out the import queue things with you in a bit if that's ok. Or are you at EOD [09:58] jam: I'll be here. [09:59] gmb: Fair enough, thanks. (It's blocked on another landing at the moment, but hopefully after that.) [09:59] cjwatson, Okay. [10:05] jtv, jam Are you aware of the poimport errors? [10:05] 2012-06-19 09:46:16 ERROR Entry is approved but has no place to import to. -- 'po/skanlite.pot' (id 6579415) in ubuntu Quantal package skanlite [10:05] Lots of that [10:06] wgrant: I just unchecked the import queue, and we're chatting about it. Still OTP, though. [10:06] That'd be the thing I said would happen. :) [11:10] jtv: back. [11:10] OK [11:46] benji: I've annotated the SSL exception in those two branches you reviewed yesterday. I'd welcome a re-review. [11:48] jml: sure, I'd be glad to [11:48] benji: thanks. [11:50] jml: looks great [11:50] benji: thanks. Do you know what the landing process is for those two projects? [11:50] since the value of "e" is known to be an exception the "% (e,)" bit is superfluous, but it won't hurt anything [11:51] benji: a little paranoia is healthy. [11:51] Just merge to trunk, update NEWS, and make a release... I think there is a document for that, hold on a sec and I'll find it [11:51] benji: you never know when SSLHandshakeError will decide to subclass tuple! [11:52] heh [11:52] that'll be the day Python jumps the shark [11:52] jml: https://dev.launchpad.net/HackingLazrLibraries#landing-your-branches and https://dev.launchpad.net/HackingLazrLibraries#releases look like what you need [11:54] versions :( [11:54] benji: thanks. [11:54] versions.cfg loves you [11:54] benji: SSLHandshakeError isn't in the buildout-depended version. Should I try to match httplib2 behaviour in currently depended version or should I bump the version dependency? [11:55] you can bump it; versions is for development and if development doesn't match reality it can be changed [12:00] benji: I don't have commit access. [12:00] jml: I'll land it for you if you want [12:00] benji: thanks. [12:01] [r=benji] Add environment variable, LP_DISABLE_SSL_CERTIFICATE_VALIDATION, to [12:01] disable SSL certificate checks. Most useful when testing against development [12:01] servers. [12:01] that's my commit message. [12:01] k [12:01] benji: no need for the bump, I just hadn't run buildout in a while. [12:01] cool === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: gmb, rick_h | Firefighting: - | Critical bugs: 3.47*10^2 [12:18] bah, sorry jcsackett wrong channel, reset irssi and my channel numbers get moved on me [12:44] rick_h_: /layout save is your friend :-) [12:45] dpm: according to https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings the next steps are up to you. (steps 8+) [12:45] (Remember to also /save afterward) [12:45] rick_h_: Thanks for r= on https://code.launchpad.net/~cjwatson/lazr.restfulclient/cgi-parse-qs-deprecated/+merge/111001. I don't have commit access; could you land it for me [12:45] ? [12:46] jam, excellent, thanks for your work in getting the copy done. I can now open the translations and set up language packs before the end of the week. [12:50] cjwatson: sorry, my LP env isn't setup yet on the new machine. Can we rope someone else in atm? adeuring can you help land please? ^ [12:51] cjwatson, rick_h_: sure. [12:51] ty adeuring [13:02] jelmer: did you get a chance to re-submit my MP? [13:03] jam: ah, sorry, I misunderstood.. thought you were going to get somebody to run the fancy parallel test script for it [13:03] resubmitting now [13:03] jelmer: I was meaning for the sprint week on that. [13:03] mrevell: "crave the metal" -- ha! [13:04] bac, :) [13:05] mrevell: i think the narrator for The Big Lebowski would add a certain western flair that might be appealing. [13:12] benji: hi. I don't mean to hassle but I haven't seen my MPs get merged. Anything I can do? [13:12] Morning, all. [13:12] jml: I've been on calls. Working on it now. [13:13] benji: np, thanks. [13:14] sinzui: morning [13:14] hello [13:16] bac, I like that idea :) I wonder what he charges [13:43] jml: launchpadlib 1.10.0 released; releasing lazr.restfulclient now [13:45] benji: woot, thanks. [13:51] jml: ok, lazr.restfulclient 0.13.0 is released [13:51] benji: wonderful :) [13:51] this will make local testing of API scripts much easier. [13:52] yep, it's a good addition [14:04] adeuring, ivory -- https://plus.google.com/hangouts/_/4da3cee079179cf73f401a0a94ca9813bedf7ca8?authuser=0&hl=en [14:12] Is someone around that can help me understand: http://people.canonical.com/~wgrant/librarian-pruning.html [14:12] It mentions a few SQL statements to run, but then seems to run them under different circumstances. [14:13] (the very first query says "All SPRs" vs "Expired SPRs", but I don't see how the query is restricted to only Expired SPRs [14:30] rick_h_: ack on the comments, looking through making those changes now. [14:30] jcsackett: cool, hopefully removes some more LoC though the attr docs might bring it back, but at least it's not more code [14:33] rick_h_: yeah. i usually think SLoC rather than just LoC. whitespace and comments really aren't the problem we're trying to curb. === salgado is now known as salgado-afk [14:34] ...well, the suckless version of SLoC. Significant, not Source. [14:34] :) [14:35] jcsackett: let me know if I'm wrong on the event stuff. I kind of saw maybe that method of calling was required due to current scope in event passing [15:50] jtv: I gather from https://code.launchpad.net/~jtv/launchpad/katie-and-gina-are-bad-bad-girls/+merge/75472 that you have some experience running gina into a scratch table on dogfood. Do you know if this is documented anywhere? I have a branch I'd like to land, but I'm not sure how to QA it. [15:50] That's a long time ago. Let me refresh my memory. === salgado-afk is now known as salgado [15:51] cjwatson: ah, I see what you mean now. I just ran it normally, but also selected some data into a scratch table for before/after comparison. [15:52] But I don't really remember any of it. [15:53] Ah, OK. Hmm. [15:54] jtv: what time is it over there ? [15:54] Late:54 [15:54] has the LP team developed a generic YUI3 Model/ModelList sync layer akin to Backbone.Sync? [15:54] $ ls -ld /srv/launchpad.net/gina-mirror/dists/sid/ [15:54] drwxr-xr-x 5 launchpad launchpad 4096 2010-11-25 01:45 /srv/launchpad.net/gina-mirror/dists/sid/ [15:54] Eep, that's old. Probably doesn't have any of the packages I care about in it. [15:55] Maybe I could download one of them into the mirror by hand? [15:56] Oh, main/source/Sources.gz is 2011-09-12. Still. [15:56] ISTR this stuff depends heavily on what happens to be in the local archive on dogfood. Maybe there's ways of injecting individual packages directly… I don't know. [15:57] I bet it'll get confused by the database (hence /debian/+source/*) being substantially newer than the mirror. [15:58] I do need to do some approximation of a full run. I have unit tests for my changes to lib/lp/soyuz/scripts/gina/*, but scripts/gina.py doesn't seem to be meaningfully tested. [16:02] * deryck goes offline for lunch, back in an hour [16:03] cjwatson: I can only recommend waiting for Australia to wake up… [16:03] :-) [16:04] it's an odd timezone to wait for, but given the folks there don't sleep it's not too long a wait either [16:05] gary_poster: you should get your blog on the LP planet, the retrospectives would show up on it [16:06] * cjwatson upgrades mawson while he waits, given that when StevenK last tried that it took three hours [16:07] flacoste: +1 [16:12] flacoste, cool will do. I don't see how to do that on planet.launchpad.net, but looking around more. If you know (or czajkowski?) hints welcome [16:12] gary_poster: you might have to ask mrevell, i don't know the specifics tbh [16:13] ok cool [16:13] gary_poster, I can add you to the planet. It's not especially intuitive. [16:13] * cjwatson notices there's a doctest for gina. Phew, that's slightly less bad than it might have been. [16:14] gary_poster, It's so long since we added one that I can't remember if anyone in the LP team can do it or just a few people. [16:16] mrevell, oh cool thanks. Lemme get you a tagged link... [16:19] mrevell, http://codesinger.blogspot.com/feeds/posts/default/-/launchpad or http://codesinger.blogspot.com/feeds/posts/default/-/canonical . they are the same atm :-) [16:19] thanks gary_poster. [16:19] thank you [16:20] gary_poster: see your blogging of team meetings is going to catch on :) [16:21] czajkowski, heh, we'll see :-) [16:21] rick_h_: took a bit to cycle back, but replies on my MP and code updates. [16:22] jcsackett: loading up now [16:25] gmb, rick_h_: does one of you have time for https://code.launchpad.net/~james-w/python-oops/refactor-publishing/+merge/109428 ? [16:25] james_w: will look in just a sec [16:25] sorry, two snuck into the queue on me while I wasn't looking [16:25] thanks rick_h_ [16:28] jcsackett: r=me, thanks again for taking the time [16:33] rick_h_: thanks for the review and the suggestions. :-) [16:34] jcsackett: fav, when you assign me a review make sure to ping me. I didn't notice it until I loaded the list for OCR today. I totally would have missed it otherwise [16:34] rick_h_: i didn't ping you b/c i knew you were OCR today, and i put it up last night. :-) [16:34] ah, well nvm then. Glad I didn't hold you up too much then [16:34] didn't hold me up in the least. thanks again. :-) [16:49] james_w: so is there a back story here I assume? [16:49] rick_h_, there is, yes [16:49] I guess I should have updated the description, sorry [16:50] rick_h_, the oops stack has a hack where it decides if a report has already been published by seeing if it has an 'id' key [16:50] but it's valid for an app to allocate an id when it generates an oops, e.g. for django to show the id to the user [16:50] ok [16:50] there is a wrapper function in python-oops that publishes to a publisher only if the id isn't set [16:51] ok, so this is trying to build that in with the flag [16:51] ? [16:51] which you want to use for reliable oops delivery (try and publish to amqp, if that fails drop it in a directory and have something else try again when amqp is back) [16:51] so if the app allocates the id then you never get that fallback, and oopses are lost [16:52] so you remove the wrapper and instead duplicate the work as you will always publish to the dir on disk, even if amqp succeeeded [16:52] talking to Rob about it we decided that whether an oops has been published should be remembered by the config, rather than stored in the oops [16:52] ok [16:52] and then publishers would be added to the config declaring if they should only get oopses that are unpublished [16:53] that would be an API break from the current API of appending publishers to a list [16:53] james_w: ok, r=me with a couple of nitpicks, one is just something that maybe is me coming unaware to the conversation [16:53] Rob suggested that instead the "publish to a list of publishers" thing be extracted out and taught all of that stuff [16:53] so I did that, and left the old code in for compatibility [16:54] ok, kind of see it. Now an oops pro, but nothing here looks like it'll go boom! :) [16:54] /now/not [16:55] thanks rick_h_ [16:55] rick_h_, good comments, thanks [16:56] I'll fix all of that up [16:56] I'm not sure about deprecation warnings [16:56] I don't know if there is a policy we can follow without thinking [16:56] yea, not sure either. I've not really seen us do that, but if we're clearly deprecating things in an API seems like we really want to get the word out [16:57] since I know python-oops stuff is used in a few places I believe [16:57] sinzui: any feedback on officially deprecating something like this in a library? python-oops [17:01] rick_h_, I think we want to raise the warning to tell developers we are going to remove the API. We do not know this much since we have do not have a lot of code that is reused. We do rely on the deprecated warning from our libs to tell us to fix code before it breaks [17:02] rick_h_, yeah, a few [17:02] I'm not too keen on warnings immediately when the change is made as that tends to annoy developers [17:02] I'll be trying to shepherd internal users along [17:02] I don't know how many external users we have [17:02]