[03:19] python-launchpadlib is not currently installable from launchpad ppa on natty: [03:19] python-launchpadlib : Depends: python-lazr.restfulclient (>= 0.11.2-1) but 0.11.1-1build1 is to be installed [03:19] Depends: python-lazr.uri (>= 1.0.2-4) but 1.0.2-3build1 is to be installed [03:41] cody-somerville: Natty's no longer supported for Launchpad development. [03:41] It hasn't even been a year since Natty was released. [03:42] cody-somerville: its best effort only [03:42] cody-somerville: not deliberately broken, but no effort made to spport it [03:46] Everyone else who has wanted to run Launchpad has been running either Lucid or the latest stable. [03:46] Nobody complained when we proposed not actively maintaining Natty in ppa:launchpad, so we stopped. [03:46] is python-launchpadlib getting backported in another PPA? [03:47] you can use the one in natty itself [03:50] * cody-somerville manually patches his launchpadlib with https://code.launchpad.net/~leonardr/launchpadlib/handle-unknown-token/+merge/51563 [05:37] cody-somerville: Are you subscribed to launchpad-dev? That's where I announced that Maverick was removed from the LP PPA. [05:38] StevenK, I am. I use natty not maverick though. [05:39] I announced that Natty might get shot in the face, though. [05:39] wgrant: I figured out why my rev broke. IBugSet.createBug() calls notify() *then* _setInformationType() [05:40] wgrant: But I'm not sure how to test that. The fix, of course, is to call _setInformationType() right after the bug is created. [05:47] StevenK: Right, that's what I suspected immediately :) [05:47] StevenK: Should be very easy to test. [05:47] StevenK: You just have to create a private bug on a product with a structsub, and check the notification recipients. [05:52] StevenK: And no, the fix is to merge _setInformationType into whatever creates the bug. [05:52] StevenK: private/security_related exist only for compatibility; they should not permeate that far into the model. [05:54] I'm still questioning if they will die completly. [05:55] But yes -- I can bring forward convert_to_information_type() in adapters.bug from the next branch and pass in private, security_related and information_type to the Bug() call. [06:13] Differences (ndiff with -expected +actual): - Time zone: Europe/London (UTC+0000) + Time zone: + Europe/London + (UTC+0100) [06:13] Hah [06:13] I guess that'll affect all builds for the next view months... [06:13] few [06:17] wgrant: Oh sigh [07:20] StevenK: yo can subscribe, create a bug, in your handler check the information type [07:24] But you also need the integration test that I outlined above. [07:24] I tried to write it, it fails either way. [11:18] aloha === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [19:33] 080254 === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [22:36] http://www.soapatterns.org/masterlist_c.php [22:39] lifeless: people still run php! [22:40] very many [22:40] probably generates most pages on the internets [22:40] * bigjools was being tongue-in-cheek [22:41] glad you are thinking about the patterns anyway [22:41] it's nice to see some abstractions written down [22:42] bigjools: boo! [22:42] wallyworld_: enjoy your drag club? [22:42] how's your ticker this morning? [22:42] yes, *very* informative [22:52] wgrant: http://pastebin.ubuntu.com/899767/ is my test complete bong? [22:53] StevenK: Does it work? [22:54] (no, it doesn't -- so yes, complete bong :)) [22:55] StevenK: You need to check the recipients *at creation time*. [22:55] This is well after. [22:55] You could do what lifeless said, or you could create a bug and inspect the BugNotificationRecipient table afterwards, or preferably both. [22:56] I'd rather just one nice test. [22:56] But okay, I need to reach into BugNotificationRecipient with Storm. [22:59] StevenK: You need an integration test. [22:59] But both would be preferable. [23:01] wgrant: I thought the one I pasted was? [23:01] wgrant: StevenK: checking the BNR table afterwards is a test I would delete [23:01] lifeless: Why? [23:01] notificationservice won't have that table [23:01] ............. [23:01] notsureifserious [23:01] totally [23:01] Then you'd change the test to check the notification service? [23:02] use abstractions, don't test across them [23:02] completely [23:02] lifeless: THen mock out the notification service. [23:02] But don't just mock out one of the Zope subscribers and check that single callsite. [23:02] Not for something like this. [23:07] wgrant: Right, and there should be *one* notification to the reporter? [23:08] (Currently, I have two) [23:08] StevenK: And potentially one to the security contact or bug supervisor. [23:10] StevenK: you probably have two due to bug [23:10] lifeless: Yes, I know, thank you. [23:10] bug 132300 [23:10] <_mup_> Bug #132300: mail for new bugs inconsistent with other bug mail (ignores mail-on-my-actions disabled, missing footers, duplicate mail vs structural subscriptions)

< https://launchpad.net/bugs/132300 > [23:11] StevenK: ^ was digging the number up [23:11] lifeless: I have two due to the critical filed on the weekend. [23:11] The one I've been thinking about, and kicking myself for since I found about it. [23:13] StevenK: bug 963539 ? [23:13] lifeless: Yah. [23:14] wgrant: http://pastebin.ubuntu.com/899792/ Given that test (which passes), what other test do I need? [23:14] StevenK: There's no existing API for that? [23:15] Not that I could see. [23:15] And that test fails before the reversion? [23:16] wgrant: Yeah, I resurrected the changes, and the test failed. Applying the diff I wrote in anger on Sunday fixes it. [23:17] wgrant: equally, or better, mock out the existing notification api to check its private. Oh wait, thats what I suggested. [23:18] lifeless: Mocking out the API called by the subscriber, maybe. [23:18] But the subscribers are too muddy now to safely mock out directly. [23:19] Erm [23:19] Who is this Eike character, and why did they readd the crap that you removed from that bug description? :/ [23:19] wgrant: I can reach into BugNotification and pull out the record and then call .recipients() on it, or I can just Join() through to BNR. [23:19] I picked the latter. [23:20] wgrant: i suspect a bug in 'bug-repo-syncer' [23:21] Indeed it is. [23:22] ./bug_repo_syncer/common.py: #Match discovery bug link: "[@[@BUGLINK "bug #123"@trac @]@]" [23:22] <_mup_> Bug #123: There's no direct way to see the project info when translating it < https://launchpad.net/bugs/123 > [23:22] bug 964862 [23:22] <_mup_> Bug #964862: something is damaging the bug description in bug 936502 < https://launchpad.net/bugs/964862 > [23:25] lifeless: So, yes, ideally we'd mock out the notification API, except that LP's "lol what's an abstraction" policy makes that difficult to do reliably without checking the DB tables. [23:26] wgrant: So I've fixed and can put this up for review again, or I need another test? [23:27] StevenK: Is information_type now handled natively? [23:28] wgrant: information_type is now set correctly when the bug is created. [23:29] thats a different question :P [23:29] All three attributes need to be set correctly in the initial INSERT [23:29] And preferably the method only takes information_type [23:30] Calculating private and security_related from that. [23:30] wgrant: All three attributes are set correctly when the bug is created. [23:30] They were last time too. [23:30] What we care about is *in the initial INSERT statement*. [23:31] Sorry, yes, set correctly during the initial INSERT. [23:31] Sounds reviewable :) [23:33] wgrant: http://pastebin.ubuntu.com/899809/ [23:34] Indeed. [23:40] wgrant: https://code.launchpad.net/~stevenk/launchpad/bugs-use-information_type-redux/+merge/99236 if you're offering [23:43] StevenK: Will look in a sec. [23:43] Trying to convince the staging mailbox to function... [23:44] "Downloading message header 1 of 345783" [23:44] Haha [23:44] Hmmmm. Mail. I should read that. [23:47] StevenK: btw, you may have seen that cocoplum scripts are nodowntime now. [23:47] I have, yes. [23:47] StevenK: This means that everywhere that touches the DB is nodowntime. [23:47] So we no longer have to inject cocoplum deployment sequence points. [23:48] For this sort of thing. [23:48] poppy still has a DB connection [23:48] lifeless: Yes, but it doesn't use it. [23:48] So it doesn't matter. [23:48] wouldn't it be a lot safer to remove it [23:48] so that there is no timebom [23:48] Oh yes. [23:48] b [23:48] I actually looked last week at deleting poppy from the tree. [23:48] o\o/ [23:48] Sadly it would require the extraction of the SSH server stuff. [23:49] so ? [23:49] Which is slightly less than trivial, so I didn't JFDI. [23:49] that needs extraction anyhow [23:49] Sure. [23:49] fair enough [23:49] Had it not required that, it would have been an obvious JFDI task. [23:50] StevenK: Can I expect a followup in the near future that makes information_type the native form? [23:51] wgrant: That's in the branch that was reviewed on Friday [23:51] Ah [23:51] Indeed. [23:51] Which depends on two DB patches [23:51] Does not. [23:51] The change I want is purely internal API changes. [23:51] Currently things still pass private/security_related flags around. [23:52] When they should only deal with information_type. [23:52] Right. That's the next branch. [23:52] The Bug model can deal with mapping that to private/security_related. [23:52] StevenK: I think I mentioned this in the last review, but from the diff it looks like bug.private writes were previously permitted by the security policy, but I don't see any ZCML changes in this brnach to prevent that. [23:58] wgrant: wgrant: private/security_related aren't in the ZCML, so I'm not sure how to tell it "forbid anyone setting these"