[01:17] I have some odd failures that have started appearing in my branches. http://pastebin.ubuntu.com/1085503/ [01:17] huwshimi: Merge devel, wgrant fixed them last night. [01:23] StevenK: Ah, I tried that yesterday afternoon, I guess I was a little too early [01:25] Also, if I have a bzr pipe do I need to do anything special to 'ec2 land' that pipe. I'm sure I used to just make sure I had switched to the pipe and submit, but it doesn't seem to be working anymore [01:26] huwshimi: ec2 landing one pipe is easier if you run 'ec2 land ' [01:27] StevenK: Ah right, I'll give that a go. Cheers mate. [01:31] wgrant: So, should I look at that bug you assigned me? [01:31] wgrant: teach-rasj-about-branches is landing [01:32] Bah, wallyworld_ got r15600. [01:32] * StevenK stabs him [01:32] StevenK: Great [01:32] wallyworld_: Huh, what's with the circular import thing you added to lib/lp/bugs/interfaces/bugtask.py? [01:32] wallyworld_: It's at the top level, so it can't be for circular import avoidance. [01:35] A mail from LP making the MP as merged before I get a success mail from PQM? :-( [01:37] wgrant: Oh, hah. You assigned that bug to me and then closed it. [01:37] StevenK: Which bug? I think the freenode node I was on has died. [01:37] wgrant_: bug 1014625 [01:37] <_mup_> Bug #1014625: pkgme should have one license < https://launchpad.net/bugs/1014625 > [01:37] BAH [01:37] wgrant_: bug 1014624 [01:37] <_mup_> Bug #1014624: Sharing details page does not show branches < https://launchpad.net/bugs/1014624 > === wgrant_ is now known as wgrant [01:38] StevenK: Right, what about it? [01:38] Last I saw was: [01:38] 11:32:59 < wgrant> wallyworld_: It's at the top level, so it can't be for circular import avoidance. [01:38] [11:31] < StevenK> wgrant: So, should I look at that bug you assigned me? [01:38] wgrant: There's little point looking at it -- you closed it, I just didn't notice that bit. [01:38] wgrant: if i put it at the top of the file the zcml won't load [01:39] Oh, I got that but missed it. Oops [01:39] wallyworld_: Lies. [01:39] * wgrant tries. [01:39] * StevenK waits for "Hmmmm." [01:40] Unless it's an import order issue, which we haven't really seen since c.l.i was destroyed. [01:40] But if enums is importing other stuff then enums is buggy. [01:40] the vocab imports stuff [01:41] wallyworld_: But lp.registry.enums doesn't import anything else in LP, so it can't be circular. [01:41] I just moved it to its rightful location and it works. [01:41] * wgrant lands. [01:41] +1 [01:41] not sure what happened for me then [01:42] PyCharm caused it [01:42] PyCharm [01:42] Or something [01:42] Because it's written in Java [01:42] Hahahaha [01:42] And Java is Java [01:42] huh? [01:42] :) [01:42] i ran it from command line [01:42] what's pycharm got to do with it? [01:42] Don't you go trying to use logic on us! [01:46] sinzui, wallyworld_: I'm wondering about private team junk branches... we could subscribe the team, or we could create an immutable non-pillar access policy with a single grant for the team and make the branches use that. [01:47] That would prevent the team from losing control of their branches through unsubscription. [01:47] In a project the maintainer can always regain control. [01:47] I favour the latter [01:47] don't we want to avoid subscribe and visibility conflayion? [01:47] But in the private team case they may not be able to. [01:47] wallyworld_: Unfortunately scope was cut, so it will still be slightly conflated. [01:47] I would like to think sharing will be adapted to teams one day [01:48] the latter works for me too [01:48] The AP model is deliberately flexible to this sort of thing. [01:48] The core bits don't care about information type at all [01:48] This also means we have a well-defined owner for all branches in the system. [01:48] Finally. [01:49] Non-owner owner, that is. [01:49] Non-owner owner? [01:49] no maintainer that co-owns the branch [01:49] registrant vs owner perhaps? [01:49] Well, project maintainers own project branches [01:49] Branch owners don't own their branches [01:49] The project maintainer does. [01:49] Right [01:49] In terms of data ownership [01:50] Branches are hard, let's go shopping. [01:50] Well the registrant is another cock-up by Lp. Lp is not a home for Mr Cock-up, but we seem to have prepared a bed for him [01:51] that's just begging to be quotes paged... [01:51] Agreed [01:51] sinzui: Just a bed? He turns up so often he has a wardrobe and a toothbrush in LP> [01:51] s/>/./ [01:53] StevenK, well noted. we also have given him several email addresses [01:53] sinzui: there's a sendTeamEmailAddressValidationEmail() method that's only called if contact email is entered when creating a team. it doesn't seem to be called from the team contact address view. should it be? [01:54] sinzui: Haha [01:54] what? [01:54] spm: Srsly. [01:55] I could scroll though #launchpad-dev.log every day and just find amazing quotes. [01:55] wallyworld_, all email addresses have to be validated. Maybe Lp is using the user email confirmation process by mistake [01:55] * sinzui welcomes the deletion on unused code though [01:56] sinzui: the the team contact form, a different method is used, validate_new_team_email() [01:56] sinzui: the team creation actually sends an email [01:57] whereas the validate_new_team_email() seems to simple parse the email [01:57] ug [01:58] wallyworld_, I have more faith is the validate_new_team_email() method. I expect barry's work it be 'canonical' approach. You can remove code I think. [01:59] ok, thanks. it seems silly that we do it 2 ways [01:59] sinzui: although you could enter an email that parses but is not valid [02:00] so the sendTeamEmailAddressValidationEmail(0 does at least check that bit [02:01] wallyworld_, an email address validation RE is more than 1024 chars long and will topple Lp trying to use in pages [02:01] * sinzui remembers that sad incident [02:02] wallyworld_, So we care about the email being sent to the the address, and a human being using the link to confirm to Lp that the address is owned. [02:02] wallyworld_, I will tell the squad about the email address RE tomorrow. [02:02] sinzui: yes, that's my point. so we would want to keep the sendTeamEmailAddressValidationEmail() method and ditch the RE? [02:03] though the beer in me wants to tell the bogus yarn now [02:03] the RE is used during form submission of the contact address edit form [02:03] the send email and human clicks link is used for team creation [02:03] but we are removing the latter [02:04] so the question is - do we want to augment the RE check with the send email check on the edit contact adress form [02:05] wallyworld_, I think we do want to keep it. [02:05] sendTeamEmailAddressValidationEmail() is the proper method [02:05] ok, thanks. will do that [02:05] confusing that we diverged [02:06] wallyworld_, yes. I just read the code. That is the proper method. The one we send to users would be a lie [02:07] it would be good to know why we only used that method on team creation [02:07] and not when editing the external contact address later [02:10] oh, i lied, we do send it [02:13] sinzui, wgrant: Bug 933935 can be closed now? [02:13] <_mup_> Bug #933935: Remove bug and branch subscription checks from visibility checks

< https://launchpad.net/bugs/933935 > [02:15] I don't know, sorry [02:15] StevenK: Indeed, I've closed it [02:15] The last subscription check was removed from production an hour ago :) [02:19] I think that the BVP replacement I'm working on and the release of writable +sharing will close at least 25 bugs. [02:19] wgrant: Can I start on that? I'm looking for something to do. [02:20] StevenK: How much do you know about bug notifications? [02:21] Enough to know that I don't want to know more. [02:21] wgrant: Whyfor? [02:21] Bug #933934 is a blocker with a significant amount of remaining work. [02:21] <_mup_> Bug #933934: Remove the bug supervisor/security contact subscriptions rules

< https://launchpad.net/bugs/933934 > [02:21] sinzui: ^^ [02:21] Hello minefield, please blow my foot off. [02:22] We need structsub filters by information-type, and we need structsubs to work for private bugs. [02:22] The rules here are very well-defined, fortunately. [02:22] I think that will have to happen when sharing is out of beta [02:22] That will be fun code to cut [02:22] wgrant: bug 297756 is close to being closeable, too [02:22] <_mup_> Bug #297756: Cannot manage access to a project's private bugs and branches

< https://launchpad.net/bugs/297756 > [02:22] StevenK: Right, that's one of the >20 :) [02:23] sinzui: Why? structsub work seems out of the way [02:23] sinzui: It needs to be done before sharing can be really useful, and it has no dependency on sharing being complete. [02:23] sinzui: We can't remove the default bugsupervisor sub until we've sorted out structural subs [02:23] Otherwise nobody will be notified about new private bugs [02:24] == bad [02:24] * StevenK tosses a card from Backlog to Deployment-Ready in wgrant's name [02:24] ITYM Done-Done [02:25] wgrant: I wasn't sure if the NDT was done because it's still Fix Committed [02:25] It's been on all the appservers for more than an hour. I think hloeung just hasn't noticed it's finished yet. [02:25] Hahaha [02:26] wgrant, okay, I think we have a card for that. I think there is a bug suggesting that we create structural subscriptions for security contacts and bug supervisors when we enter beta so that there is no apparent change in behaviour [02:27] sinzui, wgrant: So I will look at making structsubs work with private bugs. [02:27] Or I can do filter by information_type first [02:27] StevenK: Right. There's two largely separate pieces of work: firstly, structsubs have to work for private bugs. Secondly, they have to be able to filter by information type [02:28] You can't do the filtering by information_type first, since most of the other information types are private :) [02:28] StevenK, Bug #1008526 and Bug #1008538 roughly describe the forthcoming train wreck that we want to avert [02:28] So it's going to be a bit hard to test [02:28] <_mup_> Bug #1008526: Security contacts are not notified when the project is not shared < https://launchpad.net/bugs/1008526 > [02:28] <_mup_> Bug #1008538: Bug Supervisors are not notified when the project is not shared < https://launchpad.net/bugs/1008538 > [02:28] sinzui: Bug #1008541 too [02:28] <_mup_> Bug #1008541: Sharing policies unconfigure existing projects < https://launchpad.net/bugs/1008541 > [02:28] yep [02:28] wgrant: Is there a bug about structsubs on private bugs? [02:29] StevenK: Bug #376186 is the main bug for that [02:29] <_mup_> Bug #376186: implicit (e.g.structural) subscriptions to private bugs don't work even when the subscriber has visibility on the bug

< https://launchpad.net/bugs/376186 > [02:29] StevenK, nothing old that I am aware of. We know that these three bugs assume SS work with privacy [02:30] wgrant: Right [02:30] So I tagged it but could not remember. maybe I need to switch to ice cream [02:30] StevenK: Bug #901548 should be fixed implicitly by that, but it's something to keep in mind. [02:30] <_mup_> Bug #901548: launchpad does not send emails to the assignee of private bugs < https://launchpad.net/bugs/901548 > [02:31] * StevenK looks for a card for that bug [02:31] Searching Kanban is as bas as searching LP bugs [02:31] So I'm glad it's not just us [02:31] StevenK: I meant to create one yesterday, but then code privacy burnt down. [02:31] I don't think there is one. [02:32] wgrant: But then we teamed up and rebuilt it stronger, faster and better. [02:32] wgrant, I updated https://wiki.canonical.com/InformationInfrastructure/OSA/LP/DeploymentIssues/2012-07-10-revert-NDT [02:32] StevenK: I hope this series of tasks is a bit less fraught with inclarity and terror than your last one with branch privacy... [02:32] Haha [02:32] sinzui: Thanks, looking. [02:33] sinzui: ArtifactAccessGrants [02:33] AccessArtifactGrants [02:33] Artefact is something much older [02:33] And I don't think it was 2500 branches [02:33] sinzui: If you're still editing, it might be worth noting that 99% of the 2500 were old misconfigured branches. [02:33] StevenK: Slightly under 2400. [02:33] But 2500 is close enough :) [02:34] We only fixed like 140? [02:34] I will add that in another footnote. I don't want to brag about the period were projects were setup correctly [02:34] StevenK: Oh, you must have been busy last night. [02:34] StevenK: There was a secondary disaster after the one sinzui notified us of. [02:34] Yeah, I'm reading it now [02:35] I was off IRC [02:37] ah 2400 [03:43] wgrant: Can I have a starting thread to tug at? [03:46] StevenK: Bug.getBugNotificationRecipients [03:47] And get_also_notified_subscribers [03:47] if bug.private: [03:47] return [] [03:47] I was just laughing at the assertion in getBugNotificationRecipients [04:51] wgrant: So I guess the plan would be to have the functions do the usual things (rather than bugging out early for private bugs) and then filtering the results against get_bug_privacy_filter or something like it? [04:51] shouldn [04:51] bah [04:51] ignore tht [04:52] StevenK: Right [04:52] wgrant: I just hate the idea of looping over get_bug_privacy_filter [04:52] StevenK: There's one significant question that's unanswered. [04:53] wgrant: Private dupes? [04:53] StevenK: We should possibly do the filtering when we're calculating the recipients [04:53] But we don't expand teams at that stage [04:53] We only expand teams when we're sending mail [04:54] Well [04:54] I guess it's not clear that we want to do the filtering at the time of the action. [04:54] lifeless: What do you think? [04:54] You have opinions on this matter [04:54] s/ on this matter// [04:55] I would like to offer some constraints [04:55] They're all wrong. [04:55] don't do something incompatible with a notification service [04:55] which can do team expansion itself, but can't callback for individual visibility rules. [04:56] It's not at all clear that that constraint is necessary or supportable. [04:56] But it might be nice. [04:56] We certainly need it. [04:56] I have every intention of landing my stuff at some point; if its incompatible with that constraint, it will get dropped/redefined/changed to be compatible at that time,. [04:57] I'd rather not rework something you're reworking Right Now. [04:57] what else [04:57] I guess team structural subscriptions are evil anyway, so we can probably disregard them. [04:57] uhm, yes, duplicates and notifications are a pain. [04:57] Do the filtering at the time of the action [04:58] So BugNotificationRecipient will continue to have only permissible recipients. [04:58] How would it have others? [were you thinking to check subscriptions without cross referencing grants?] [05:00] lifeless: Well, the other option is to insert everything into BugNotificationRecipient and filter after team expansion in the sending cronscript. That would mean members could get mail through a team subscription as long as they had a grant, even if the team did not. [05:00] But team subscriptions are evil and should probably be disallowed, so it's not a major loss to break that. [05:00] wgrant: I'm not clear how team subscriptions would be broken [05:01] wgrant: grants -> subscriptions -> TP -> persons. [05:01] its one query, no ? [05:07] lifeless: I believe BugNotificationRecipient is the un-team-expanded set. [05:09] Yay, bugsummaryrebuild works [05:10] And the result is even correct [05:12] wgrant: I don't see how checking access at the front end prohibits teams working in the backend [05:13] lifeless: If we only insert into BugNotificationRecipient those Persons that have access, then team members that have access won't get email if their team doesn't have access. [05:13] The entire team will be mailed, or none of it will. [05:14] wgrant: if you dedup before inserting ? [05:14] wgrant: but that implies you are deduping before checking access [05:15] which is precisely not checking access at the front end of the process [05:15] The current pipeline is: event -> BugNotificationRecipient -> team expansion -> email [05:16] The question is whether we put the access check after event or after team expansion. [05:16] Deduping isn't relevant here [05:17] oh, I see [05:17] you're postulating the following scenario: [05:17] structural subscription for team A [05:17] no grant for team A [05:17] person X, a member of team A, has a grant. [05:17] Right. [05:18] either via team B, or via a direct subscription and a person-X direct grant. [05:19] given that we filter such teams from the list of who will be notified today, I would say that X should not expect a notification, except and unless A is given a grant. [05:19] Its confusing and inconsistent to have such metaconfiguration possible. IMNSHO. [05:19] is that a useful opinion ? [05:20] Indeed, it supports my feeling, so it's useful :) [05:20] StevenK: So it's nice and easy [05:25] wgrant: It is? [05:28] StevenK: Yeah, I think you can just remove the special-case which excludes indirect subscriptions, and add a filter on the end of getIndirectSubscribers to only return those people who satsify get_bug_privacy_filter [05:29] wgrant: As well as get_also_notified_subscribers? [05:29] StevenK: getIndirectSubscribers calls get_also_notified_subscribers [05:29] StevenK: As well as getting dupe subs [05:29] Both of which need to be filtered, I suspect. [05:29] Unless we don't want dupe subs to count at all, but that would seem odd [05:30] wgrant: Right, so now I'm concerned about how to do the filtering. Since get_bug_privacy_filter only takes one user, I don't want to loop over it. [05:31] StevenK: Ye of little faith [05:32] wgrant: I know they're storm fragments, so it can't get that bad, but ... [05:32] StevenK: RemoveArtifactSubscriptionsJob.run() [05:32] StevenK: It uses get_bug_privacy_filter_terms manually to do a bulk access check [05:32] In a tasteful fashion. === almaisan-away is now known as al-maisan [06:26] StevenK: Making any sense at all? [07:01] gary_poster: I hope you mean 'July 6' [07:42] good morning === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban* (rvba) | Firefighting: - | Critical bugs: 4.0*10^2 [09:01] jtv: Hai [09:01] Hi StevenK [09:01] jtv: Could I get your opinion on https://code.launchpad.net/~stevenk/launchpad/kill-rpsd/+merge/114300 ? [09:02] StevenK: people keep saying that it's been replaced by a job, but every time I check we're not quite there yet. Where does that stand? [09:05] jtv: I have no idea, TBH [09:06] That might be worth checking. The bit that was always missing was a background scrubber that fires off jobs for all POFiles, not just ones that we know need their stats updated. [09:27] benji: ^ Anything light you can shed on that? I *think* it was you that wrote the job. [09:53] if it's not being run at all, then why does it matter? [10:57] jml: Because the job may end up relying on infrastructure I'm proposing to remove. === al-maisan is now known as almaisan-away [10:58] StevenK: so then you can restore the code if that turns out to be the case. === matsubara is now known as matsubara-afk === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [12:08] StevenK, heh, whoops, yes :-) === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban* (rvba), abentley | Firefighting: - | Critical bugs: 4.0*10^2 === salgado is now known as salgado-brb === salgado-brb is now known as salgado === al-maisan is now known as almaisan-away [14:59] gary_poster: did you get your juju mp sorted yet? [15:02] czajkowski, no, but thank you for mentioning it on G+ :-) We need juju charmers to do the work [15:03] ok [15:03] let me go and poke [15:03] heh, thanks czajkowski === mpt_ is now known as mpt === matsubara-afk is now known as matsubara === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: 4.0*10^2 === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado [18:02] bkerensa_: hey [18:02] hi [18:02] bkerensa_: gary_poster is the one who is looking for juju help === bkerensa_ is now known as bkerensa [18:03] hi gary_poster [18:20] bkerensa, hi [18:20] gary_poster: I hear you are running into some issues with your charm? Perhaps I might be of assistance [18:20] bkerensa, what we need is some packaging help. [18:21] bkerensa, not exactly [18:21] packaging? [18:21] let me get you a mp [18:21] k [18:21] it is charm-helpers [18:23] bkerensa, we've talked to mark_mims and SpamapS about this before; we're just hoping to get it resolved sooner rather than later. Here's one MP... https://code.launchpad.net/~gmb/charm-tools/add-charm-helpers/+merge/96204 [18:23] That depends on packaing python-shelltoolbox [18:23] gary_poster: Were mark_mims and Spamaps not able to help? They are perhaps the best Juju Hackers :) [18:24] ahh I see [18:24] so this is in regards to the juju trunk and not a actual juju charm? [18:24] charm-tools specifically [18:25] bkerensa, they want to help. we just haven't been able to get their help. Here is the most recent branch/MP, actualy. [18:25] https://code.launchpad.net/~yellow/charm-tools/trunk/+merge/101554 [18:25] They have been too busy to help [18:26] and this has gone on for months and months now [18:26] and we would like to get this resolved [18:27] ahh well I'm unfortunately not the right person... I just author charms and do not work on the juju or charm-tools branches at all.... I will ping mark and Spaamaps but also have you perhaps talked to jcastro since he is the Cloud Liason? [18:27] gary_poster: bkerensa: yeah, I really need to just sit down and do this. Perhaps today [18:27] so it looks like Clint is going to get working on this [18:28] bkerensa, fantastic, thank you [18:28] hopefully today but at least very soon [18:28] cool [18:28] bkerensa: thanks [18:28] might wanna join #juju to follow up with him as neccesary or prod him a couple times [18:28] ;) [18:28] czajkowski: no problem [18:29] gary_poster: cool [18:29] thanks very much czajkowski ! [18:30] gary_poster: see it pays to blog :) [18:30] czajkowski, :-) === salgado is now known as salgado-afk [22:48] jcsackett, wgrant, wallyworld_, StevenK, This is my draft of a report stating what we have been doing over 13 months: http://people.canonical.com/~curtis/lp-milestone/report.html [23:03] wgrant: Total: 120 tests, 3 failures, 0 errors in 2 minutes 17.362 seconds. [23:05] StevenK: Not bad [23:09] wgrant: Those 3 failures are all TestNotificationRecipientsOfPrivateBugs [23:09] wgrant: http://pastebin.ubuntu.com/1087043/ [23:15] sinzui: Mumble crashed just as you suggested we adjourn. So the tech spirits agreed with you. :-p [23:17] wgrant: I've had to comment out the issuperset assert too [23:24] Indeed [23:43] wgrant: I'm just wondering why that assert is there [23:44] wgrant: Total: 120 tests, 0 failures, 0 errors in 2 minutes 17.914 seconds. [23:44] % bzr damage [23:44] Using submit branch /home/steven/launchpad/lp-branches/devel [23:44] Damage: 0 lines of code [23:45] StevenK: I don't really know