[01:17] <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:23] <huwshimi> StevenK: Ah, I tried that yesterday afternoon, I guess I was a little too early
[01:25] <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:26] <StevenK> huwshimi: ec2 landing one pipe is easier if you run 'ec2 land <MP URL>'
[01:27] <huwshimi> StevenK: Ah right, I'll give that a go. Cheers mate.
[01:31] <StevenK> wgrant: So, should I look at that bug you assigned me?
[01:31] <StevenK> wgrant: teach-rasj-about-branches is landing
[01:32] <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:35] <StevenK> A mail from LP making the MP as merged before I get a success mail from PQM? :-(
[01:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:53] <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:54] <StevenK> sinzui: Haha
[01:54] <sinzui> what?
[01:54] <nigelb> spm: Srsly.
[01:55] <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:56] <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:57] <wallyworld_> whereas the validate_new_team_email() seems to simple parse the email
[01:57] <sinzui> ug
[01:58] <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:59] <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
[02:00] <wallyworld_> so the sendTeamEmailAddressValidationEmail(0 does at least check that bit
[02:01] <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:02] <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:03] <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:04] <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:05] <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:06] <sinzui> wallyworld_, yes. I just read the code. That is the proper method. The one we send to users would be a lie
[02:07] <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:10] <wallyworld_> oh, i lied, we do send it
[02:13] <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:15] <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:19] <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:20] <wgrant> StevenK: How much do you know about bug notifications?
[02:21] <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:22] <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:23] <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:24] <wgrant> == bad
[02:24]  * StevenK tosses a card from Backlog to Deployment-Ready in wgrant's name
[02:24] <wgrant> ITYM Done-Done
[02:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31]  * 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:32] <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:33] <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:34] <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:35] <StevenK> I was off IRC
[02:37] <sinzui> ah 2400
[03:43] <StevenK> wgrant: Can I have a starting thread to tug at?
[03:46] <wgrant> StevenK: Bug.getBugNotificationRecipients
[03:47] <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
[04:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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?]
[05:00] <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:01] <lifeless> wgrant: grants -> subscriptions -> TP -> persons.
[05:01] <lifeless> its one query, no ?
[05:07] <wgrant> lifeless: I believe BugNotificationRecipient is the un-team-expanded set.
[05:09] <wgrant> Yay, bugsummaryrebuild works
[05:10] <wgrant> And the result is even correct
[05:12] <lifeless> wgrant: I don't see how checking access at the front end prohibits teams working in the backend
[05:13] <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:14] <lifeless> wgrant: if you dedup before inserting ?
[05:14] <lifeless> wgrant: but that implies you are deduping before checking access
[05:15] <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:16] <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:17] <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:18] <lifeless> either via team B, or via a direct subscription and a person-X direct grant.
[05:19] <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:20] <wgrant> Indeed, it supports my feeling, so it's useful :)
[05:20] <wgrant> StevenK: So it's nice and easy
[05:25] <StevenK> wgrant: It is?
[05:28] <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:29] <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:30] <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:31] <wgrant> StevenK: Ye of little faith
[05:32] <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.
[06:26] <wgrant> StevenK: Making any sense at all?
[07:01] <StevenK> gary_poster: I hope you mean 'July 6'
[07:42] <adeuring> good morning
[09:01] <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:02] <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:05] <StevenK> jtv: I have no idea, TBH
[09:06] <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:27] <StevenK> benji: ^ Anything light you can shed on that? I *think* it was you that wrote the job.
[09:53] <jml> if it's not being run at all, then why does it matter?
[10:57] <StevenK> jml: Because the job may end up relying on infrastructure I'm proposing to remove.
[10:58] <jml> StevenK: so then you can restore the code if that turns out to be the case.
[12:08] <gary_poster> StevenK, heh, whoops, yes :-)
[14:59] <czajkowski> gary_poster: did you get your juju mp sorted yet?
[15:02] <gary_poster> czajkowski, no, but thank you for mentioning it on G+ :-) We need juju charmers to do the work
[15:03] <czajkowski> ok
[15:03] <czajkowski> let me go and poke
[15:03] <gary_poster> heh, thanks czajkowski
[18:02] <czajkowski> bkerensa_: hey
[18:02] <bkerensa_> hi
[18:02] <czajkowski> bkerensa_: gary_poster is the one who is looking for juju help
[18:03] <bkerensa> hi gary_poster
[18:20] <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:21] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <bac> gary_poster: cool
[18:29] <gary_poster> thanks very much czajkowski !
[18:30] <czajkowski> gary_poster: see it pays to blog :)
[18:30] <gary_poster> czajkowski, :-)
[22:48] <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
[23:03] <StevenK> wgrant: Total: 120 tests, 3 failures, 0 errors in 2 minutes 17.362 seconds.
[23:05] <wgrant> StevenK: Not bad
[23:09] <StevenK> wgrant: Those 3 failures are all TestNotificationRecipientsOfPrivateBugs
[23:09] <StevenK> wgrant: http://pastebin.ubuntu.com/1087043/
[23:15] <jcsackett> sinzui: Mumble crashed just as you suggested we adjourn. So the tech spirits agreed with you. :-p
[23:17] <StevenK> wgrant: I've had to comment out the issuperset assert too
[23:24] <wgrant> Indeed
[23:43] <StevenK> wgrant: I'm just wondering why that assert is there
[23:44] <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:45] <wgrant> StevenK: I don't really know