[03:19] <cody-somerville> python-launchpadlib is not currently installable from launchpad ppa on natty:
[03:19] <cody-somerville>  python-launchpadlib : Depends: python-lazr.restfulclient (>= 0.11.2-1) but 0.11.1-1build1 is to be installed
[03:19] <cody-somerville>                        Depends: python-lazr.uri (>= 1.0.2-4) but 1.0.2-3build1 is to be installed
[03:41] <wgrant> cody-somerville: Natty's no longer supported for Launchpad development.
[03:41] <cody-somerville> It hasn't even been a year since Natty was released.
[03:42] <lifeless> cody-somerville: its best effort only
[03:42] <lifeless> cody-somerville: not deliberately broken, but no effort made to spport it
[03:46] <wgrant> Everyone else who has wanted to run Launchpad has been running either Lucid or the latest stable.
[03:46] <wgrant> Nobody complained when we proposed not actively maintaining Natty in ppa:launchpad, so we stopped.
[03:46] <cody-somerville> is python-launchpadlib getting backported in another PPA?
[03:47] <lifeless> 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] <StevenK> cody-somerville: Are you subscribed to launchpad-dev? That's where I announced that Maverick was removed from the LP PPA.
[05:38] <cody-somerville> StevenK, I am. I use natty not maverick though.
[05:39] <StevenK> I announced that Natty might get shot in the face, though.
[05:39] <StevenK> wgrant: I figured out why my rev broke. IBugSet.createBug() calls notify() *then* _setInformationType()
[05:40] <StevenK> 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] <wgrant> StevenK: Right, that's what I suspected immediately :)
[05:47] <wgrant> StevenK: Should be very easy to test.
[05:47] <wgrant> StevenK: You just have to create a private bug on a product with a structsub, and check the notification recipients.
[05:52] <wgrant> StevenK: And no, the fix is to merge _setInformationType into whatever creates the bug.
[05:52] <wgrant> StevenK: private/security_related exist only for compatibility; they should not permeate that far into the model.
[05:54] <StevenK> I'm still questioning if they will die completly.
[05:55] <StevenK> 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] <wgrant> Differences (ndiff with -expected +actual): - Time zone: Europe/London (UTC+0000) + Time zone: + Europe/London + (UTC+0100)
[06:13] <wgrant> Hah
[06:13] <wgrant> I guess that'll affect all builds for the next view months...
[06:13] <wgrant> few
[06:17] <StevenK> wgrant: Oh sigh
[07:20] <lifeless> StevenK: yo can subscribe, create a bug, in your handler check the information type
[07:24] <wgrant> But you also need the integration test that I outlined above.
[07:24] <StevenK> I tried to write it, it fails either way.
[11:18] <czajkowski> aloha
[19:33] <rick_h> 080254
[22:36] <lifeless> http://www.soapatterns.org/masterlist_c.php
[22:39] <bigjools> lifeless: people still run php!
[22:40] <lifeless> very many
[22:40] <lifeless> probably generates most pages on the internets
[22:40]  * bigjools was being tongue-in-cheek
[22:41] <bigjools> glad you are thinking about the patterns anyway
[22:41] <bigjools> it's nice to see some abstractions written down
[22:42] <wallyworld_> bigjools: boo!
[22:42] <bigjools> wallyworld_: enjoy your drag club?
[22:42] <wallyworld_> how's your ticker this morning?
[22:42] <wallyworld_> yes, *very* informative
[22:52] <StevenK> wgrant: http://pastebin.ubuntu.com/899767/  is my test complete bong?
[22:53] <wgrant> StevenK: Does it work?
[22:54] <wgrant> (no, it doesn't -- so yes, complete bong :))
[22:55] <wgrant> StevenK: You need to check the recipients *at creation time*.
[22:55] <wgrant> This is well after.
[22:55] <wgrant> You could do what lifeless said, or you could create a bug and inspect the BugNotificationRecipient table afterwards, or preferably both.
[22:56] <StevenK> I'd rather just one nice test.
[22:56] <StevenK> But okay, I need to reach into BugNotificationRecipient with Storm.
[22:59] <wgrant> StevenK: You need an integration test.
[22:59] <wgrant> But both would be preferable.
[23:01] <StevenK> wgrant: I thought the one I pasted was?
[23:01] <lifeless> wgrant: StevenK: checking the BNR table afterwards is a test I would delete
[23:01] <wgrant> lifeless: Why?
[23:01] <lifeless> notificationservice won't have that table
[23:01] <wgrant> .............
[23:01] <wgrant> notsureifserious
[23:01] <lifeless> totally
[23:01] <wgrant> Then you'd change the test to check the notification service?
[23:02] <lifeless> use abstractions, don't test across them
[23:02] <bigjools> completely
[23:02] <wgrant> lifeless: THen mock out the notification service.
[23:02] <wgrant> But don't just mock out one of the Zope subscribers and check that single callsite.
[23:02] <wgrant> Not for something like this.
[23:07] <StevenK> wgrant: Right, and there should be *one* notification to the reporter?
[23:08] <StevenK> (Currently, I have two)
[23:08] <wgrant> StevenK: And potentially one to the security contact or bug supervisor.
[23:10] <lifeless> StevenK: you probably have two due to bug
[23:10] <StevenK> lifeless: Yes, I know, thank you.
[23:10] <lifeless> 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) <email> <lp-bugs> <notifications> <Launchpad itself:Triaged> < https://launchpad.net/bugs/132300 >
[23:11] <lifeless> StevenK: ^ was digging the number up
[23:11] <StevenK> lifeless: I have two due to the critical filed on the weekend.
[23:11] <StevenK> The one I've been thinking about, and kicking myself for since I found about it.
[23:13] <lifeless> StevenK: bug 963539 ?
[23:13] <StevenK> lifeless: Yah.
[23:14] <StevenK> wgrant: http://pastebin.ubuntu.com/899792/  Given that test (which passes), what other test do I need?
[23:14] <wgrant> StevenK: There's no existing API for that?
[23:15] <StevenK> Not that I could see.
[23:15] <wgrant> And that test fails before the reversion?
[23:16] <StevenK> wgrant: Yeah, I resurrected the changes, and the test failed. Applying the diff I wrote in anger on Sunday fixes it.
[23:17] <lifeless> wgrant: equally, or better, mock out the existing notification api to check its private. Oh wait, thats what I suggested.
[23:18] <wgrant> lifeless: Mocking out the API called by the subscriber, maybe.
[23:18] <wgrant> But the subscribers are too muddy now to safely mock out directly.
[23:19] <wgrant> Erm
[23:19] <wgrant> Who is this Eike character, and why did they readd the crap that you removed from that bug description? :/
[23:19] <StevenK> 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] <StevenK> I picked the latter.
[23:20] <lifeless> wgrant: i suspect a bug in 'bug-repo-syncer'
[23:21] <wgrant> Indeed it is.
[23:22] <wgrant> ./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 <lp-translations> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/123 >
[23:22] <lifeless> bug 964862
[23:22] <_mup_> Bug #964862: something is damaging the bug description in bug 936502 <bug-repo-syncer:New> < https://launchpad.net/bugs/964862 >
[23:25] <wgrant> 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] <StevenK> wgrant: So I've fixed and can put this up for review again, or I need another test?
[23:27] <wgrant> StevenK: Is information_type now handled natively?
[23:28] <StevenK> wgrant: information_type is now set correctly when the bug is created.
[23:29] <lifeless> thats a different question :P
[23:29] <wgrant> All three attributes need to be set correctly in the initial INSERT
[23:29] <wgrant> And preferably the method only takes information_type
[23:30] <wgrant> Calculating private and security_related from that.
[23:30] <StevenK> wgrant: All three attributes are set correctly when the bug is created.
[23:30] <wgrant> They were last time too.
[23:30] <wgrant> What we care about is *in the initial INSERT statement*.
[23:31] <StevenK> Sorry, yes, set correctly during the initial INSERT.
[23:31] <wgrant> Sounds reviewable :)
[23:33] <StevenK> wgrant: http://pastebin.ubuntu.com/899809/
[23:34] <wgrant> Indeed.
[23:40] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/bugs-use-information_type-redux/+merge/99236 if you're offering
[23:43] <wgrant> StevenK: Will look in a sec.
[23:43] <wgrant> Trying to convince the staging mailbox to function...
[23:44] <wgrant> "Downloading message header 1 of 345783"
[23:44] <StevenK> Haha
[23:44] <StevenK> Hmmmm. Mail. I should read that.
[23:47] <wgrant> StevenK: btw, you may have seen that cocoplum scripts are nodowntime now.
[23:47] <StevenK> I have, yes.
[23:47] <wgrant> StevenK: This means that everywhere that touches the DB is nodowntime.
[23:47] <wgrant> So we no longer have to inject cocoplum deployment sequence points.
[23:48] <wgrant> For this sort of thing.
[23:48] <lifeless> poppy still has a DB connection
[23:48] <wgrant> lifeless: Yes, but it doesn't use it.
[23:48] <wgrant> So it doesn't matter.
[23:48] <lifeless> wouldn't it be a lot safer to remove it
[23:48] <lifeless> so that there is no timebom
[23:48] <wgrant> Oh yes.
[23:48] <lifeless> b
[23:48] <wgrant> I actually looked last week at deleting poppy from the tree.
[23:48] <lifeless> o\o/
[23:48] <wgrant> Sadly it would require the extraction of the SSH server stuff.
[23:49] <lifeless> so ?
[23:49] <wgrant> Which is slightly less than trivial, so I didn't JFDI.
[23:49] <lifeless> that needs extraction anyhow
[23:49] <wgrant> Sure.
[23:49] <lifeless> fair enough
[23:49] <wgrant> Had it not required that, it would have been an obvious JFDI task.
[23:50] <wgrant> StevenK: Can I expect a followup in the near future that makes information_type the native form?
[23:51] <StevenK> wgrant: That's in the branch that was reviewed on Friday
[23:51] <wgrant> Ah
[23:51] <wgrant> Indeed.
[23:51] <StevenK> Which depends on two DB patches
[23:51] <wgrant> Does not.
[23:51] <wgrant> The change I want is purely internal API changes.
[23:51] <wgrant> Currently things still pass private/security_related flags around.
[23:52] <wgrant> When they should only deal with information_type.
[23:52] <StevenK> Right. That's the next branch.
[23:52] <wgrant> The Bug model can deal with mapping that to private/security_related.
[23:52] <wgrant> 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] <StevenK> wgrant: wgrant: private/security_related aren't in the ZCML, so I'm not sure how to tell it "forbid anyone setting these"