| huwshimi | I have some odd failures that have started appearing in my branches. http://pastebin.ubuntu.com/1085503/ | 01:17 |
|---|---|---|
| StevenK | huwshimi: Merge devel, wgrant fixed them last night. | 01:17 |
| huwshimi | StevenK: Ah, I tried that yesterday afternoon, I guess I was a little too early | 01:23 |
| huwshimi | 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:25 |
| StevenK | huwshimi: ec2 landing one pipe is easier if you run 'ec2 land <MP URL>' | 01:26 |
| huwshimi | StevenK: Ah right, I'll give that a go. Cheers mate. | 01:27 |
| StevenK | wgrant: So, should I look at that bug you assigned me? | 01:31 |
| StevenK | wgrant: teach-rasj-about-branches is landing | 01:31 |
| StevenK | Bah, wallyworld_ got r15600. | 01:32 |
| * StevenK stabs him | 01:32 | |
| wgrant | StevenK: Great | 01:32 |
| wgrant | wallyworld_: Huh, what's with the circular import thing you added to lib/lp/bugs/interfaces/bugtask.py? | 01:32 |
| wgrant | wallyworld_: It's at the top level, so it can't be for circular import avoidance. | 01:32 |
| StevenK | A mail from LP making the MP as merged before I get a success mail from PQM? :-( | 01:35 |
| StevenK | wgrant: Oh, hah. You assigned that bug to me and then closed it. | 01:37 |
| wgrant_ | StevenK: Which bug? I think the freenode node I was on has died. | 01:37 |
| StevenK | wgrant_: bug 1014625 | 01:37 |
| _mup_ | Bug #1014625: pkgme should have one license <pkgme:Fix Released> < https://launchpad.net/bugs/1014625 > | 01:37 |
| StevenK | BAH | 01:37 |
| StevenK | wgrant_: bug 1014624 | 01:37 |
| _mup_ | Bug #1014624: Sharing details page does not show branches <disclosure> <sharing> <ui> <Launchpad itself:Fix Released by stevenk> < https://launchpad.net/bugs/1014624 > | 01:37 |
| === wgrant_ is now known as wgrant | ||
| wgrant | StevenK: Right, what about it? | 01:38 |
| wgrant | Last I saw was: | 01:38 |
| wgrant | 11:32:59 < wgrant> wallyworld_: It's at the top level, so it can't be for circular import avoidance. | 01:38 |
| StevenK | [11:31] < StevenK> wgrant: So, should I look at that bug you assigned me? | 01:38 |
| StevenK | wgrant: There's little point looking at it -- you closed it, I just didn't notice that bit. | 01:38 |
| wallyworld_ | wgrant: if i put it at the top of the file the zcml won't load | 01:38 |
| wgrant | Oh, I got that but missed it. Oops | 01:39 |
| wgrant | wallyworld_: Lies. | 01:39 |
| * wgrant tries. | 01:39 | |
| * StevenK waits for "Hmmmm." | 01:39 | |
| wgrant | Unless it's an import order issue, which we haven't really seen since c.l.i was destroyed. | 01:40 |
| wgrant | But if enums is importing other stuff then enums is buggy. | 01:40 |
| wallyworld_ | the vocab imports stuff | 01:40 |
| wgrant | wallyworld_: But lp.registry.enums doesn't import anything else in LP, so it can't be circular. | 01:41 |
| wgrant | I just moved it to its rightful location and it works. | 01:41 |
| * wgrant lands. | 01:41 | |
| sinzui | +1 | 01:41 |
| wallyworld_ | not sure what happened for me then | 01:41 |
| StevenK | PyCharm caused it | 01:42 |
| wgrant | PyCharm | 01:42 |
| StevenK | Or something | 01:42 |
| wgrant | Because it's written in Java | 01:42 |
| StevenK | Hahahaha | 01:42 |
| wgrant | And Java is Java | 01:42 |
| wallyworld_ | huh? | 01:42 |
| wgrant | :) | 01:42 |
| wallyworld_ | i ran it from command line | 01:42 |
| wallyworld_ | what's pycharm got to do with it? | 01:42 |
| wgrant | Don't you go trying to use logic on us! | 01:42 |
| wgrant | 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:46 |
| wgrant | That would prevent the team from losing control of their branches through unsubscription. | 01:47 |
| wgrant | In a project the maintainer can always regain control. | 01:47 |
| sinzui | I favour the latter | 01:47 |
| wallyworld_ | don't we want to avoid subscribe and visibility conflayion? | 01:47 |
| wgrant | But in the private team case they may not be able to. | 01:47 |
| wgrant | wallyworld_: Unfortunately scope was cut, so it will still be slightly conflated. | 01:47 |
| sinzui | I would like to think sharing will be adapted to teams one day | 01:47 |
| wallyworld_ | the latter works for me too | 01:48 |
| wgrant | The AP model is deliberately flexible to this sort of thing. | 01:48 |
| wgrant | The core bits don't care about information type at all | 01:48 |
| wgrant | This also means we have a well-defined owner for all branches in the system. | 01:48 |
| wgrant | Finally. | 01:48 |
| wgrant | Non-owner owner, that is. | 01:49 |
| StevenK | Non-owner owner? | 01:49 |
| sinzui | no maintainer that co-owns the branch | 01:49 |
| wallyworld_ | registrant vs owner perhaps? | 01:49 |
| wgrant | Well, project maintainers own project branches | 01:49 |
| wgrant | Branch owners don't own their branches | 01:49 |
| wgrant | The project maintainer does. | 01:49 |
| StevenK | Right | 01:49 |
| wgrant | In terms of data ownership | 01:49 |
| StevenK | Branches are hard, let's go shopping. | 01:50 |
| sinzui | 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:50 |
| spm | that's just begging to be quotes paged... | 01:51 |
| wgrant | Agreed | 01:51 |
| StevenK | sinzui: Just a bed? He turns up so often he has a wardrobe and a toothbrush in LP> | 01:51 |
| StevenK | s/>/./ | 01:51 |
| sinzui | StevenK, well noted. we also have given him several email addresses | 01:53 |
| wallyworld_ | 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:53 |
| StevenK | sinzui: Haha | 01:54 |
| sinzui | what? | 01:54 |
| nigelb | spm: Srsly. | 01:54 |
| nigelb | I could scroll though #launchpad-dev.log every day and just find amazing quotes. | 01:55 |
| sinzui | 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:55 | |
| wallyworld_ | sinzui: the the team contact form, a different method is used, validate_new_team_email() | 01:56 |
| wallyworld_ | sinzui: the team creation actually sends an email | 01:56 |
| wallyworld_ | whereas the validate_new_team_email() seems to simple parse the email | 01:57 |
| sinzui | ug | 01:57 |
| sinzui | 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:58 |
| wallyworld_ | ok, thanks. it seems silly that we do it 2 ways | 01:59 |
| wallyworld_ | sinzui: although you could enter an email that parses but is not valid | 01:59 |
| wallyworld_ | so the sendTeamEmailAddressValidationEmail(0 does at least check that bit | 02:00 |
| sinzui | 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:01 | |
| sinzui | 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 |
| sinzui | wallyworld_, I will tell the squad about the email address RE tomorrow. | 02:02 |
| wallyworld_ | sinzui: yes, that's my point. so we would want to keep the sendTeamEmailAddressValidationEmail() method and ditch the RE? | 02:02 |
| sinzui | though the beer in me wants to tell the bogus yarn now | 02:03 |
| wallyworld_ | the RE is used during form submission of the contact address edit form | 02:03 |
| wallyworld_ | the send email and human clicks link is used for team creation | 02:03 |
| wallyworld_ | but we are removing the latter | 02:03 |
| wallyworld_ | so the question is - do we want to augment the RE check with the send email check on the edit contact adress form | 02:04 |
| sinzui | wallyworld_, I think we do want to keep it. | 02:05 |
| sinzui | sendTeamEmailAddressValidationEmail() is the proper method | 02:05 |
| wallyworld_ | ok, thanks. will do that | 02:05 |
| wallyworld_ | confusing that we diverged | 02:05 |
| sinzui | wallyworld_, yes. I just read the code. That is the proper method. The one we send to users would be a lie | 02:06 |
| wallyworld_ | it would be good to know why we only used that method on team creation | 02:07 |
| wallyworld_ | and not when editing the external contact address later | 02:07 |
| wallyworld_ | oh, i lied, we do send it | 02:10 |
| StevenK | sinzui, wgrant: Bug 933935 can be closed now? | 02:13 |
| _mup_ | Bug #933935: Remove bug and branch subscription checks from visibility checks <disclosure> <sharing> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/933935 > | 02:13 |
| sinzui | I don't know, sorry | 02:15 |
| wgrant | StevenK: Indeed, I've closed it | 02:15 |
| wgrant | The last subscription check was removed from production an hour ago :) | 02:15 |
| wgrant | I think that the BVP replacement I'm working on and the release of writable +sharing will close at least 25 bugs. | 02:19 |
| StevenK | wgrant: Can I start on that? I'm looking for something to do. | 02:19 |
| wgrant | StevenK: How much do you know about bug notifications? | 02:20 |
| StevenK | Enough to know that I don't want to know more. | 02:21 |
| StevenK | wgrant: Whyfor? | 02:21 |
| wgrant | 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 <disclosure> <sharing> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/933934 > | 02:21 |
| wgrant | sinzui: ^^ | 02:21 |
| StevenK | Hello minefield, please blow my foot off. | 02:21 |
| wgrant | We need structsub filters by information-type, and we need structsubs to work for private bugs. | 02:22 |
| wgrant | The rules here are very well-defined, fortunately. | 02:22 |
| sinzui | I think that will have to happen when sharing is out of beta | 02:22 |
| sinzui | That will be fun code to cut | 02:22 |
| StevenK | 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 <disclosure> <lp-bugs> <oem-services> <sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/297756 > | 02:22 |
| wgrant | StevenK: Right, that's one of the >20 :) | 02:22 |
| StevenK | sinzui: Why? structsub work seems out of the way | 02:23 |
| wgrant | sinzui: It needs to be done before sharing can be really useful, and it has no dependency on sharing being complete. | 02:23 |
| wgrant | sinzui: We can't remove the default bugsupervisor sub until we've sorted out structural subs | 02:23 |
| wgrant | Otherwise nobody will be notified about new private bugs | 02:23 |
| wgrant | == bad | 02:24 |
| * StevenK tosses a card from Backlog to Deployment-Ready in wgrant's name | 02:24 | |
| wgrant | ITYM Done-Done | 02:24 |
| StevenK | wgrant: I wasn't sure if the NDT was done because it's still Fix Committed | 02:25 |
| wgrant | 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 |
| StevenK | Hahaha | 02:25 |
| sinzui | 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:26 |
| StevenK | sinzui, wgrant: So I will look at making structsubs work with private bugs. | 02:27 |
| StevenK | Or I can do filter by information_type first | 02:27 |
| wgrant | 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:27 |
| wgrant | You can't do the filtering by information_type first, since most of the other information types are private :) | 02:28 |
| sinzui | StevenK, Bug #1008526 and Bug #1008538 roughly describe the forthcoming train wreck that we want to avert | 02:28 |
| wgrant | 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 <bugs> <disclosure> <sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1008526 > | 02:28 |
| _mup_ | Bug #1008538: Bug Supervisors are not notified when the project is not shared <bugs> <disclosure> <sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1008538 > | 02:28 |
| wgrant | sinzui: Bug #1008541 too | 02:28 |
| _mup_ | Bug #1008541: Sharing policies unconfigure existing projects <bugs> <disclosure> <sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1008541 > | 02:28 |
| sinzui | yep | 02:28 |
| StevenK | wgrant: Is there a bug about structsubs on private bugs? | 02:28 |
| wgrant | 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 <disclosure> <lp-bugs> <privacy> <sharing> <story-better-bug-notification> <ubuntu-qa> <Apport:Won't Fix> <Launchpad itself:Triaged> < https://launchpad.net/bugs/376186 > | 02:29 |
| sinzui | StevenK, nothing old that I am aware of. We know that these three bugs assume SS work with privacy | 02:29 |
| StevenK | wgrant: Right | 02:30 |
| sinzui | So I tagged it but could not remember. maybe I need to switch to ice cream | 02:30 |
| wgrant | 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 <bugs> <email> <privacy> <sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901548 > | 02:30 |
| * StevenK looks for a card for that bug | 02:31 | |
| StevenK | Searching Kanban is as bas as searching LP bugs | 02:31 |
| StevenK | So I'm glad it's not just us | 02:31 |
| wgrant | StevenK: I meant to create one yesterday, but then code privacy burnt down. | 02:31 |
| wgrant | I don't think there is one. | 02:31 |
| StevenK | wgrant: But then we teamed up and rebuilt it stronger, faster and better. | 02:32 |
| sinzui | wgrant, I updated https://wiki.canonical.com/InformationInfrastructure/OSA/LP/DeploymentIssues/2012-07-10-revert-NDT | 02:32 |
| wgrant | 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 |
| StevenK | Haha | 02:32 |
| wgrant | sinzui: Thanks, looking. | 02:32 |
| StevenK | sinzui: ArtifactAccessGrants | 02:33 |
| wgrant | AccessArtifactGrants | 02:33 |
| StevenK | Artefact is something much older | 02:33 |
| StevenK | And I don't think it was 2500 branches | 02:33 |
| wgrant | sinzui: If you're still editing, it might be worth noting that 99% of the 2500 were old misconfigured branches. | 02:33 |
| wgrant | StevenK: Slightly under 2400. | 02:33 |
| wgrant | But 2500 is close enough :) | 02:33 |
| StevenK | We only fixed like 140? | 02:34 |
| sinzui | I will add that in another footnote. I don't want to brag about the period were projects were setup correctly | 02:34 |
| wgrant | StevenK: Oh, you must have been busy last night. | 02:34 |
| wgrant | StevenK: There was a secondary disaster after the one sinzui notified us of. | 02:34 |
| StevenK | Yeah, I'm reading it now | 02:34 |
| StevenK | I was off IRC | 02:35 |
| sinzui | ah 2400 | 02:37 |
| StevenK | wgrant: Can I have a starting thread to tug at? | 03:43 |
| wgrant | StevenK: Bug.getBugNotificationRecipients | 03:46 |
| wgrant | And get_also_notified_subscribers | 03:47 |
| wgrant | if bug.private: | 03:47 |
| wgrant | return [] | 03:47 |
| StevenK | I was just laughing at the assertion in getBugNotificationRecipients | 03:47 |
| StevenK | 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 |
| lifeless | shouldn | 04:51 |
| lifeless | bah | 04:51 |
| lifeless | ignore tht | 04:51 |
| wgrant | StevenK: Right | 04:52 |
| StevenK | wgrant: I just hate the idea of looping over get_bug_privacy_filter | 04:52 |
| wgrant | StevenK: There's one significant question that's unanswered. | 04:52 |
| StevenK | wgrant: Private dupes? | 04:53 |
| wgrant | StevenK: We should possibly do the filtering when we're calculating the recipients | 04:53 |
| wgrant | But we don't expand teams at that stage | 04:53 |
| wgrant | We only expand teams when we're sending mail | 04:53 |
| wgrant | Well | 04:54 |
| wgrant | I guess it's not clear that we want to do the filtering at the time of the action. | 04:54 |
| wgrant | lifeless: What do you think? | 04:54 |
| wgrant | You have opinions on this matter | 04:54 |
| StevenK | s/ on this matter// | 04:54 |
| lifeless | I would like to offer some constraints | 04:55 |
| wgrant | They're all wrong. | 04:55 |
| lifeless | don't do something incompatible with a notification service | 04:55 |
| lifeless | which can do team expansion itself, but can't callback for individual visibility rules. | 04:55 |
| wgrant | It's not at all clear that that constraint is necessary or supportable. | 04:56 |
| wgrant | But it might be nice. | 04:56 |
| StevenK | We certainly need it. | 04:56 |
| lifeless | 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:56 |
| lifeless | I'd rather not rework something you're reworking Right Now. | 04:57 |
| lifeless | what else | 04:57 |
| wgrant | I guess team structural subscriptions are evil anyway, so we can probably disregard them. | 04:57 |
| lifeless | uhm, yes, duplicates and notifications are a pain. | 04:57 |
| wgrant | Do the filtering at the time of the action | 04:57 |
| wgrant | So BugNotificationRecipient will continue to have only permissible recipients. | 04:58 |
| lifeless | How would it have others? [were you thinking to check subscriptions without cross referencing grants?] | 04:58 |
| wgrant | 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 |
| wgrant | But team subscriptions are evil and should probably be disallowed, so it's not a major loss to break that. | 05:00 |
| lifeless | wgrant: I'm not clear how team subscriptions would be broken | 05:00 |
| lifeless | wgrant: grants -> subscriptions -> TP -> persons. | 05:01 |
| lifeless | its one query, no ? | 05:01 |
| wgrant | lifeless: I believe BugNotificationRecipient is the un-team-expanded set. | 05:07 |
| wgrant | Yay, bugsummaryrebuild works | 05:09 |
| wgrant | And the result is even correct | 05:10 |
| lifeless | wgrant: I don't see how checking access at the front end prohibits teams working in the backend | 05:12 |
| wgrant | 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 |
| wgrant | The entire team will be mailed, or none of it will. | 05:13 |
| lifeless | wgrant: if you dedup before inserting ? | 05:14 |
| lifeless | wgrant: but that implies you are deduping before checking access | 05:14 |
| lifeless | which is precisely not checking access at the front end of the process | 05:15 |
| wgrant | The current pipeline is: event -> BugNotificationRecipient -> team expansion -> email | 05:15 |
| wgrant | The question is whether we put the access check after event or after team expansion. | 05:16 |
| wgrant | Deduping isn't relevant here | 05:16 |
| lifeless | oh, I see | 05:17 |
| lifeless | you're postulating the following scenario: | 05:17 |
| lifeless | structural subscription for team A | 05:17 |
| lifeless | no grant for team A | 05:17 |
| lifeless | person X, a member of team A, has a grant. | 05:17 |
| wgrant | Right. | 05:17 |
| lifeless | either via team B, or via a direct subscription and a person-X direct grant. | 05:18 |
| lifeless | 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 |
| lifeless | Its confusing and inconsistent to have such metaconfiguration possible. IMNSHO. | 05:19 |
| lifeless | is that a useful opinion ? | 05:19 |
| wgrant | Indeed, it supports my feeling, so it's useful :) | 05:20 |
| wgrant | StevenK: So it's nice and easy | 05:20 |
| StevenK | wgrant: It is? | 05:25 |
| wgrant | 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:28 |
| StevenK | wgrant: As well as get_also_notified_subscribers? | 05:29 |
| wgrant | StevenK: getIndirectSubscribers calls get_also_notified_subscribers | 05:29 |
| wgrant | StevenK: As well as getting dupe subs | 05:29 |
| wgrant | Both of which need to be filtered, I suspect. | 05:29 |
| wgrant | Unless we don't want dupe subs to count at all, but that would seem odd | 05:29 |
| StevenK | 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:30 |
| wgrant | StevenK: Ye of little faith | 05:31 |
| StevenK | wgrant: I know they're storm fragments, so it can't get that bad, but ... | 05:32 |
| wgrant | StevenK: RemoveArtifactSubscriptionsJob.run() | 05:32 |
| wgrant | StevenK: It uses get_bug_privacy_filter_terms manually to do a bulk access check | 05:32 |
| wgrant | In a tasteful fashion. | 05:32 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | StevenK: Making any sense at all? | 06:26 |
| StevenK | gary_poster: I hope you mean 'July 6' | 07:01 |
| adeuring | good morning | 07:42 |
| === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban* (rvba) | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| StevenK | jtv: Hai | 09:01 |
| jtv | Hi StevenK | 09:01 |
| StevenK | jtv: Could I get your opinion on https://code.launchpad.net/~stevenk/launchpad/kill-rpsd/+merge/114300 ? | 09:01 |
| jtv | 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:02 |
| StevenK | jtv: I have no idea, TBH | 09:05 |
| jtv | 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:06 |
| StevenK | benji: ^ Anything light you can shed on that? I *think* it was you that wrote the job. | 09:27 |
| jml | if it's not being run at all, then why does it matter? | 09:53 |
| StevenK | jml: Because the job may end up relying on infrastructure I'm proposing to remove. | 10:57 |
| === al-maisan is now known as almaisan-away | ||
| jml | StevenK: so then you can restore the code if that turns out to be the case. | 10:58 |
| === 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 | ||
| gary_poster | StevenK, heh, whoops, yes :-) | 12:08 |
| === 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 | ||
| czajkowski | gary_poster: did you get your juju mp sorted yet? | 14:59 |
| gary_poster | czajkowski, no, but thank you for mentioning it on G+ :-) We need juju charmers to do the work | 15:02 |
| czajkowski | ok | 15:03 |
| czajkowski | let me go and poke | 15:03 |
| gary_poster | heh, thanks czajkowski | 15:03 |
| === 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 | ||
| czajkowski | bkerensa_: hey | 18:02 |
| bkerensa_ | hi | 18:02 |
| czajkowski | bkerensa_: gary_poster is the one who is looking for juju help | 18:02 |
| === bkerensa_ is now known as bkerensa | ||
| bkerensa | hi gary_poster | 18:03 |
| gary_poster | bkerensa, hi | 18:20 |
| bkerensa | gary_poster: I hear you are running into some issues with your charm? Perhaps I might be of assistance | 18:20 |
| gary_poster | bkerensa, what we need is some packaging help. | 18:20 |
| gary_poster | bkerensa, not exactly | 18:21 |
| bkerensa | packaging? | 18:21 |
| gary_poster | let me get you a mp | 18:21 |
| bkerensa | k | 18:21 |
| gary_poster | it is charm-helpers | 18:21 |
| gary_poster | 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 |
| gary_poster | That depends on packaing python-shelltoolbox | 18:23 |
| bkerensa | gary_poster: Were mark_mims and Spamaps not able to help? They are perhaps the best Juju Hackers :) | 18:23 |
| bkerensa | ahh I see | 18:24 |
| bkerensa | so this is in regards to the juju trunk and not a actual juju charm? | 18:24 |
| bkerensa | charm-tools specifically | 18:24 |
| gary_poster | 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 |
| gary_poster | https://code.launchpad.net/~yellow/charm-tools/trunk/+merge/101554 | 18:25 |
| gary_poster | They have been too busy to help | 18:25 |
| gary_poster | and this has gone on for months and months now | 18:26 |
| gary_poster | and we would like to get this resolved | 18:26 |
| bkerensa | 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 |
| bkerensa | gary_poster: bkerensa: yeah, I really need to just sit down and do this. Perhaps today | 18:27 |
| bkerensa | so it looks like Clint is going to get working on this | 18:27 |
| gary_poster | bkerensa, fantastic, thank you | 18:28 |
| bkerensa | hopefully today but at least very soon | 18:28 |
| gary_poster | cool | 18:28 |
| czajkowski | bkerensa: thanks | 18:28 |
| bkerensa | might wanna join #juju to follow up with him as neccesary or prod him a couple times | 18:28 |
| bkerensa | ;) | 18:28 |
| bkerensa | czajkowski: no problem | 18:28 |
| bac | gary_poster: cool | 18:29 |
| gary_poster | thanks very much czajkowski ! | 18:29 |
| czajkowski | gary_poster: see it pays to blog :) | 18:30 |
| gary_poster | czajkowski, :-) | 18:30 |
| === salgado is now known as salgado-afk | ||
| sinzui | 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 | 22:48 |
| StevenK | wgrant: Total: 120 tests, 3 failures, 0 errors in 2 minutes 17.362 seconds. | 23:03 |
| wgrant | StevenK: Not bad | 23:05 |
| StevenK | wgrant: Those 3 failures are all TestNotificationRecipientsOfPrivateBugs | 23:09 |
| StevenK | wgrant: http://pastebin.ubuntu.com/1087043/ | 23:09 |
| jcsackett | sinzui: Mumble crashed just as you suggested we adjourn. So the tech spirits agreed with you. :-p | 23:15 |
| StevenK | wgrant: I've had to comment out the issuperset assert too | 23:17 |
| wgrant | Indeed | 23:24 |
| StevenK | wgrant: I'm just wondering why that assert is there | 23:43 |
| StevenK | wgrant: Total: 120 tests, 0 failures, 0 errors in 2 minutes 17.914 seconds. | 23:44 |
| StevenK | % bzr damage | 23:44 |
| StevenK | Using submit branch /home/steven/launchpad/lp-branches/devel | 23:44 |
| StevenK | Damage: 0 lines of code | 23:44 |
| wgrant | StevenK: I don't really know | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!