| 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:19 |
| 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:41 |
| lifeless | cody-somerville: its best effort only | 03:42 |
| lifeless | cody-somerville: not deliberately broken, but no effort made to spport it | 03:42 |
| 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:46 |
| lifeless | you can use the one in natty itself | 03:47 |
| * cody-somerville manually patches his launchpadlib with https://code.launchpad.net/~leonardr/launchpadlib/handle-unknown-token/+merge/51563 | 03:50 | |
| StevenK | cody-somerville: Are you subscribed to launchpad-dev? That's where I announced that Maverick was removed from the LP PPA. | 05:37 |
| cody-somerville | StevenK, I am. I use natty not maverick though. | 05:38 |
| 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:39 |
| 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:40 |
| 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:47 |
| 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:52 |
| StevenK | I'm still questioning if they will die completly. | 05:54 |
| 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. | 05:55 |
| 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:13 |
| StevenK | wgrant: Oh sigh | 06:17 |
| lifeless | StevenK: yo can subscribe, create a bug, in your handler check the information type | 07:20 |
| wgrant | But you also need the integration test that I outlined above. | 07:24 |
| StevenK | I tried to write it, it fails either way. | 07:24 |
| czajkowski | aloha | 11:18 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| rick_h | 080254 | 19:33 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| lifeless | http://www.soapatterns.org/masterlist_c.php | 22:36 |
| bigjools | lifeless: people still run php! | 22:39 |
| lifeless | very many | 22:40 |
| lifeless | probably generates most pages on the internets | 22:40 |
| * bigjools was being tongue-in-cheek | 22:40 | |
| bigjools | glad you are thinking about the patterns anyway | 22:41 |
| bigjools | it's nice to see some abstractions written down | 22:41 |
| 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:42 |
| StevenK | wgrant: http://pastebin.ubuntu.com/899767/ is my test complete bong? | 22:52 |
| wgrant | StevenK: Does it work? | 22:53 |
| wgrant | (no, it doesn't -- so yes, complete bong :)) | 22:54 |
| 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:55 |
| StevenK | I'd rather just one nice test. | 22:56 |
| StevenK | But okay, I need to reach into BugNotificationRecipient with Storm. | 22:56 |
| wgrant | StevenK: You need an integration test. | 22:59 |
| wgrant | But both would be preferable. | 22:59 |
| 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:01 |
| 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:02 |
| StevenK | wgrant: Right, and there should be *one* notification to the reporter? | 23:07 |
| StevenK | (Currently, I have two) | 23:08 |
| wgrant | StevenK: And potentially one to the security contact or bug supervisor. | 23:08 |
| 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:10 |
| 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:11 |
| lifeless | StevenK: bug 963539 ? | 23:13 |
| StevenK | lifeless: Yah. | 23:13 |
| 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:14 |
| StevenK | Not that I could see. | 23:15 |
| wgrant | And that test fails before the reversion? | 23:15 |
| StevenK | wgrant: Yeah, I resurrected the changes, and the test failed. Applying the diff I wrote in anger on Sunday fixes it. | 23:16 |
| lifeless | wgrant: equally, or better, mock out the existing notification api to check its private. Oh wait, thats what I suggested. | 23:17 |
| 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:18 |
| 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:19 |
| lifeless | wgrant: i suspect a bug in 'bug-repo-syncer' | 23:20 |
| wgrant | Indeed it is. | 23:21 |
| 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:22 |
| 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:25 |
| StevenK | wgrant: So I've fixed and can put this up for review again, or I need another test? | 23:26 |
| wgrant | StevenK: Is information_type now handled natively? | 23:27 |
| StevenK | wgrant: information_type is now set correctly when the bug is created. | 23:28 |
| 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:29 |
| 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:30 |
| StevenK | Sorry, yes, set correctly during the initial INSERT. | 23:31 |
| wgrant | Sounds reviewable :) | 23:31 |
| StevenK | wgrant: http://pastebin.ubuntu.com/899809/ | 23:33 |
| wgrant | Indeed. | 23:34 |
| StevenK | wgrant: https://code.launchpad.net/~stevenk/launchpad/bugs-use-information_type-redux/+merge/99236 if you're offering | 23:40 |
| wgrant | StevenK: Will look in a sec. | 23:43 |
| wgrant | Trying to convince the staging mailbox to function... | 23:43 |
| wgrant | "Downloading message header 1 of 345783" | 23:44 |
| StevenK | Haha | 23:44 |
| StevenK | Hmmmm. Mail. I should read that. | 23:44 |
| 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:47 |
| 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:48 |
| 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:49 |
| wgrant | StevenK: Can I expect a followup in the near future that makes information_type the native form? | 23:50 |
| 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:51 |
| 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:52 |
| StevenK | wgrant: wgrant: private/security_related aren't in the ZCML, so I'm not sure how to tell it "forbid anyone setting these" | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!