[00:02]  * NCommander feels like this entire system is pretty much an undocumented blackbox
[00:04] <wgrant> It's undocumented, but not really a blackbox :)
[00:04] <NCommander> I'm trying to figure out where the files returned from gatherResults() go
[00:06] <wgrant> NCommander: That's on the slave, right?
[00:08] <NCommander> Yeah
[00:09] <NCommander> sourcepackagerecipe is easy, it generates a _sources.changes and uploads it normally. I'm at a loss on how translation-templates does its magic
[00:11]  * NCommander has kinda figured out where in LP the translations build magic is, but is still trying to grok is
[00:11] <NCommander> *it
[00:14] <NCommander> currently my code managed to install livecd-rootfs, build the image, bombs on gatherResults() and goes to chrootFail() :-)
[00:14] <rick_h_> huwshimi: yea, give me a sec, just got to the coffeeshop
[00:15] <huwshimi> rick_h_: It's ok if this is a bad time. I can even annotate your mockups if that's easier.
[00:16] <rick_h_> huwshimi: https://plus.google.com/hangouts/_/5b5b820d6987551f9545ee30c79ed37cd5c3e30a?authuser=0&hl=en-US#
[00:36] <StevenK> wgrant: Do I need to rip out part of IBug.transitionToInformationType()?
[00:36] <wgrant> StevenK: For the bug supervisor stuff? Not yet.
[00:37] <StevenK> wgrant: So it's just what is listed in the bug? That's +1/-45, and from what I can see, only 1 failed test.
[00:37] <wgrant> StevenK: Did you also remove the helper methods on the notificationrecipientset>?
[00:38] <StevenK> wgrant: Yah, and dropped it from the ZCML
[00:38] <wgrant> Great.
[00:38] <StevenK> Just waiting on test -vvm bugs
[00:39] <StevenK> Oh, now to find the code that gives the bug supervisor a structural subscription
[00:39] <NCommander> Ok, good, my code now executes all the way through without crashing anything
[00:39] <NCommander> Now to figure out how t get files to go somewhere
[00:41] <StevenK> wgrant: Right, I guess the self.addBugSubscription(bug_supervisor, user) can die too
[00:42] <wgrant> StevenK: That's a second branch, but yeah
[00:42] <wgrant> StevenK: Once that dies, the limitation on setting the value can die
[00:42] <StevenK> In the second branch?
[00:42] <wgrant> Since it will just convey privilege, not INFINITE SPAMMAGE
[00:42] <wgrant> Right.
[00:42] <StevenK> Right, I'll not worry about that bit yet.
[00:48] <StevenK> wgrant: .... No failed tests
[00:49] <wgrant> StevenK: Heh
[00:57]  * NCommander finally found a translations buildjob (https://launchpad.net/~vcs-imports/nautilus/master-git/+translation-templates-build/24952), but still can't tell what it uploaded
[00:59] <wgrant> NCommander: The job's gatherResults implementation calls slave.addWaitingFile, which causes it to be returned when buildd-manager asks what files are waiting.
[00:59] <NCommander> Right, that part I got
[00:59]  * NCommander is trying to work out the interface for BuildFarmJob, and where in LP said jobs are scheduled; its not in buildmaster according to grep
[01:00] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/no-more-add-bug-supervisor/+merge/119818
[01:03] <wgrant> NCommander: The buildfarm infrastructure requires three classes from you on the master side: an IBuildFarmJob (eg. BinaryPackageBuild), an IBuildFarmJob (eg. BuildPackageJob -- as the name suggests, it's deprecated but still required), and an IBuildFarmJobBehaviour (eg. BinaryPackageBuildBehaviour)
[01:03] <NCommander> right
[01:05] <NCommander> I can see that
[01:05]  * NCommander is *slowly* beginning to wrap his head around the monster
[01:05] <NCommander> Its actually not that bad once you know where all the pieces are I suppose
[01:07] <StevenK> wallyworld_: Since wgrant is such a bad person, can you review https://code.launchpad.net/~stevenk/launchpad/no-more-add-bug-supervisor/+merge/119818 ? Should be incredibly difficult.
[01:07] <NCommander> so I need to implement the correct classes (I'm guessing in soyuz/model unless you can think of a better place), and then pin out to launchpadlib so I can trigger said builds
[01:08] <NCommander> wgrant: am I roughly on the right gametrack?
[01:08] <wgrant> NCommander: Yup
[01:08] <wallyworld_> StevenK: ok
[01:08] <NCommander> wgrant: seems relatively straightforward. What's the catch? :-)
[01:08] <wgrant> NCommander: You have to touch our code :)
[01:08] <StevenK> Hahah
[01:08] <NCommander> as long as I don't need to deal with the UI bits, I'll live
[01:09] <NCommander> Soyuz isn't as bad as other code bases I dealt with
[01:09] <NCommander> (i.e. dak (before I destructively rewrote it a large chunk of it)
[01:10]  * NCommander is wondering how hard adding a new launchpadlib API will be ...
[01:11] <wgrant> Not very
[01:11] <wallyworld_> StevenK: done
[01:11] <StevenK> Depends where you want to staple it in
[01:11] <wgrant> Not just less code -- less email :)
[01:12] <NCommander> email?
[01:12] <wgrant> Talking about StevenK's branch
[01:12] <StevenK> NCommander: My branch, not your stuff
[01:12] <NCommander> oh
[01:12]  * NCommander wonders if someone has already ripped out the old bounty code
[01:12] <StevenK> NCommander: https://code.launchpad.net/~stevenk/launchpad/no-more-add-bug-supervisor/+merge/119818 if you want to celebrate
[01:12] <StevenK> The bounty tables are long dead, wgrant and I killed them last year
[01:12] <NCommander> StevenK: I would, except LP just timed out on me :-/
[01:13] <NCommander> Or my browser did, not sure which
[01:14] <StevenK> NCommander: Diff against target: 98 lines (+2/-48) 3 files modified
[01:14] <NCommander> Net -46 LoC, woo
[01:14]  * NCommander can't even remember if the old bounty system was ever actually used
[01:15] <StevenK> I now have 4 branches in ec2.
[01:16] <StevenK> +54, +9, +1, and now -46.
[01:16] <StevenK> I get to rip a little more out
[01:18] <NCommander> what's the handy-dandy bzr command to see how many LoC lines have changed?
[01:18] <StevenK> bzr di | diffstat -s
[01:18] <StevenK> Or bzr damage, which is an addon
[01:18] <NCommander> mcasadevall@perdition:~/src/launchpad-buildd$ bzr di | diffstat -s 3 files changed, 168 insertions(+)
[01:19] <NCommander> And that's just for a bare minimium implementation
[01:19]  * NCommander groans
[01:19] <StevenK> That doesn't really count, it's in -buildd
[01:19] <NCommander> oh
[01:20] <NCommander> Thought it was still considered for part of the LoC cost to LP
[01:34]  * NCommander decides its now a good time to take a break from banging my head on a wall
[01:35] <StevenK> wgrant: I can't figure out where the code that restricts setting bug supervisor is
[01:37] <wgrant> StevenK: It's possible that I was misremembering, and the problem was that there was no restriction.
[01:38] <wgrant> Ahhh
[01:38] <wgrant> It's in the view
[01:39] <wgrant> BugRoleMixin.validateBugSupervisor
[01:39] <StevenK> I thought it was in the view, but ProductEditView is sort of ... empty
[01:43] <StevenK> Right, another +3/-61
[01:56] <NCommander> when was the neutral LoC policy put in place anyway?
[02:03]  * NCommander returns
[02:19] <wgrant> wallyworld_: Heh, bug #1037364
[02:19] <wgrant> I thought there'd be some stupid-long titles :)
[02:22] <wallyworld_> wgrant: examples work for me, but i have a wide monitor. sigh 2012 and people still use narrow screen resolutions
[02:22] <wallyworld_> i can make the number of lines before truncation 3 or 4
[02:22] <wallyworld_> just for bug titles
[02:34] <StevenK> Sigh, ec2 needs a timeout for connecting to an instance
[02:38] <wgrant> StevenK: It does
[02:53] <StevenK> wgrant: I guess most or all of TestBugSupervisorEditView can die
[02:54] <wgrant> StevenK: I haven't looked, but probably.
[02:54] <wgrant> StevenK: It becomes a thoroughly thoroughly boring edit view.
[02:55] <StevenK> wgrant: So we need to test it works, but the oddball tests of "You can't set that team" just die.
[02:55] <wgrant> Right
[03:41] <StevenK> wgrant: less-sourcedeps == 17481 tests run in 4:12:31.684115, 0 failures, 0 errors
[03:43] <wgrant> StevenK: Nice.
[03:44] <StevenK> wgrant: So, how do I run the bzr-svn tests?
[03:45] <wgrant> StevenK: Not sure.
[03:46] <StevenK> Oh my god, can I delete lib/lp/bugs/tests/has-bug-supervisor.txt for being hideous.
[03:47] <wgrant> Yeah
[03:47] <wgrant> The only thing that still looks relevant is the ForbiddenAttribute
[03:47] <wgrant> Well, and I guess setBugSupervisor might not be tested elsewhere
[03:48] <StevenK> setBugSupervisor just sets the attribute, what the heck is to test?
[04:14] <StevenK> wgrant: self.assertRaises(
[04:14] <StevenK> Sigh
[04:14] <StevenK>         self.assertRaises(
[04:14] <StevenK>             ForbiddenAttribute, setattr(self.target.bugsupervisor, None))
[04:15] <StevenK> That doesn't work, but ForbiddenAttribute is thrown
[04:15] <wgrant> StevenK: self.assertRaises(ForbiddenAttribute, setattr, self.target.bugsupervisor, None)
[04:16] <StevenK> wgrant: http://pastebin.ubuntu.com/1150046/
[04:16] <StevenK> wgrant: It run the tests for the mixin :-(
[04:17] <wgrant> StevenK: Stop the mixin from inheriting TestCase
[04:24] <StevenK> wgrant: Right, I think I have mostly everything passing, but ec2 can pick that out.
[04:24] <wallyworld_> wgrant: does this look ok for adding InfoType embargoed? https://pastebin.canonical.com/72290/ it needs a mechanism to decide which projects are allowed to be configured to use it, not sure what the rules should be for that
[04:25] <wgrant> wallyworld_: The proposed mechanism is that we just don't show Embargoed sharing_policies in the UI unless they're selected
[04:25] <wgrant> The PES setup script will set it through the API
[04:26] <wallyworld_> wgrant: ok, so i just remove the entry from POLICY_ALLOWED_TYPES and it's ok then?
[04:26] <wgrant> wallyworld_: No, you need that.
[04:27] <wgrant> And you need POLICY_DEFAULT_TYPE for that too
[04:27] <wgrant> Those two dicts define what the model will allow branches to be if that setting is selected
[04:27] <wgrant> Not which branch_sharing_policies are shown in the UI
[04:28] <wallyworld_> what about POLICY_REQUIRED_GRANTS
[04:29] <wgrant> Default should be Embargoed, required should probably be Proprietary, I think
[04:29] <wgrant> It's possible required should be Proprietary OR Embargoed, but that's easy to change later if we need to
[04:30] <wallyworld_> that's what i was wondering
[04:30] <wallyworld_> i'll start with just proprietary
[04:30] <wgrant> Yeah
[04:31] <wallyworld_> and i fixed getInformationTypesToShow so that it doesn't show up in the ui, removed embargoed from shown_types
[04:31] <wgrant> wallyworld_: I think Embargoed should be in shown_types
[04:32] <wgrant> Whenever it's available
[04:32] <wgrant> Just like Proprietary
[04:32] <wallyworld_> yes, but that is done near the botton of the method
[04:32] <wgrant> The only difference between the two should be that one of the sharing_policies isn't shown in the UI
[04:32] <wallyworld_> the current product policy is added in
[04:32] <wgrant> That doesn't sound like getInformationTypesToShow
[04:33] <wgrant> You mean the thing to get the sharing policies to show?
[04:33] <wallyworld_> it's in BranchEditFormView
[04:33] <wallyworld_> yes
[04:33] <wgrant> Right
[04:33] <wallyworld_>     def getInformationTypesToShow(self):
[04:33] <wallyworld_>         """Get the information types to display on the edit form
[04:33] <wgrant> That sounds sensible
[04:34] <wgrant> What's the change you've made?
[04:34] <wallyworld_> cool, i'll add some tests and do a mp, thanks
[04:34] <wgrant> 14:31:19 < wallyworld_> and i fixed getInformationTypesToShow so that it doesn't show up in the ui, removed embargoed from shown_types
[04:34] <wgrant> That's the wrong way around
[04:34] <wgrant> It should be in shown_types, just like Proprietary is
[04:35] <wgrant> shown_types defines what the options are in the UI, assuming that the branch is able to have those types
[04:35] <wgrant> if a project has Embargoed enabled, Embargoed should be shown on Branch:+edit
[04:36] <wallyworld_> ah, getting myself confused jumping between irc and code. i know what i need to do
[04:36] <StevenK> Switch to vim?
[04:37] <wallyworld_> how would that help anything?
[04:38] <StevenK> It surely would. Both wgrant and I can agree on that.
[04:38] <wgrant> Definitely.
[04:38] <wgrant> Vim solves world hunger
[04:38] <wgrant> Vim even stops the boats.
[04:39] <wallyworld_> a sensible refugee policy would stop the boats
[04:39] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/no-structsub-for-bug-supervisor/+merge/119831
[04:40] <wgrant> wallyworld_: Now you're getting it. Therefore vim is a sensible refugee policy.
[04:40] <wgrant> StevenK: +55? What is this?
[04:40] <StevenK> wallyworld_: Well, they don't travel to the US, because they know that all the US is going to do is ship them right back. We just detain them for a while.
[04:40] <wallyworld_> maybe if we forced refugees to use it they might not want to come over
[04:41] <wgrant> StevenK: What sort of notifications do other similar edit forms show?
[04:41] <wallyworld_> we detain them and give them big ass tvs and mobile phones and health benefits
[04:41] <wgrant> StevenK: I wonder if we can drop these ones.
[04:41] <StevenK> Just drop the notifications entirely?
[04:41] <StevenK> Trying to think what we have like it.
[04:43] <wgrant> StevenK: Also, since it's probably not exposed, you might be able to remove setBugSupervisor entirely
[04:43] <StevenK> It is
[04:43] <wgrant> Since the new implementation is pretty boring
[04:44] <wgrant> Is it exposed as setBugSupervisor?
[04:44] <wgrant> it's probably a mutator
[04:44] <StevenK> @mutator_for(bug_supervisor)
[04:44] <wgrant> Yeah
[04:44] <wgrant> So it can be removed.
[04:45] <StevenK> Should I do that in this branch?
[04:45] <wgrant> Might as well
[04:45] <StevenK> Lots of places call setBugSupervisor
[04:45] <wgrant> Will mitigate the tests you added.
[04:45] <wgrant> (by rendering them redundant)
[04:45] <wgrant> (and failing)
[04:45] <StevenK> Both of them, in fact
[04:45] <wgrant> (and removable)
[04:48] <StevenK> 15 files changed, 17 insertions(+), 359 deletions(-)
[04:49] <StevenK> Now to delete every setBugSupervisor call ever
[04:51] <wgrant> :)
[04:51] <StevenK> wgrant: Hmmm, how does the ZCML change?
[04:52] <StevenK> setBugSupervisor is listed seperately
[04:53] <wgrant> StevenK: setBugSupervisor is probably in the launchpad.Edit attributes= section. Replace it with bug_supvisor in set_attributes
[04:53] <wgrant> Obviously spelt with enough letters
[04:56] <StevenK> wgrant: Like so? http://pastebin.ubuntu.com/1150072/
[04:56] <wgrant> StevenK: That's the one.
[04:58] <StevenK> Er, what
[04:58] <StevenK>     def _create_scenario(self, user):
[04:58] <StevenK>         with person_logged_in(user):
[04:58] <StevenK>             logged_in_user = getUtility(ILaunchBag).user
[04:58] <StevenK> ...
[04:58] <StevenK>                 user=logged_in_user)
[04:59] <StevenK> wgrant: Is it just me, or that just pointless and user=user would be fine?
[05:00] <wgrant> StevenK: LaunchBag.user may not always be the logged in user.
[05:00] <StevenK> Twitch
[05:00]  * StevenK leaves it alone for being magical
[05:00] <wgrant> It should be the same, but I suspect it isn't always
[05:16] <StevenK>  39 files changed, 84 insertions(+), 477 deletions(-)
[05:21] <StevenK> wallyworld_: :-(
[05:21] <wallyworld_> huh?
[05:22] <StevenK> wallyworld_: I was seeing if we could go a full day with only me landing branches and you wrecked it.
[05:23] <wallyworld_> oh, i thought i had broken the build or something
[05:23] <wallyworld_> you just made me load buildbot
[05:23] <StevenK> Hahahaha
[05:23] <wallyworld_> bastard!
[05:24] <wallyworld_> StevenK: my branch in bb now is a diff of one character :-P
[05:24] <StevenK> Heh
[05:25] <wallyworld_> my other ones had a merge conflict in ec2 i didn't notice :-(
[05:30] <StevenK> Come on, diff!
[05:30] <StevenK> Damn it
[05:36] <StevenK> wgrant: If you're done watching *redacted* for the moment, that diff is updated.
[05:37] <wgrant> StevenK: Thanks, looking
[05:38] <wgrant> wallyworld_: I think you're overstating your work a bit.
[05:38] <wgrant> wallyworld_: It was a single *bit* of diff :)
[05:38] <wallyworld_> yes, so it was :-D lol
[05:38] <StevenK> Really?
[05:38] <StevenK> 3-6 is not one bit
[05:38] <wallyworld_> 2 became 6
[05:39] <StevenK> 010 goes to 110
[05:39] <StevenK> Oh, so it is
[05:40] <StevenK> I thought it was 3, bleh.
[05:46] <wgrant> StevenK: Did you look at the notifications?
[05:47] <StevenK> wgrant: I did not -- what do you think?
[05:50] <wgrant> I forget what other forms do
[05:50] <wgrant> I suspect that a lot of them don't notify.
[05:54] <StevenK> wgrant: Kill it or leave it for sinzui?
[05:55] <wgrant> We can always remove it later :)
[05:55] <wgrant> Sorry, looking at your MP again now
[05:55] <wgrant> Distractions abound
[05:57] <StevenK> It's you, so duh. :-)
[06:17] <wgrant> wallyworld_: Hm, actually, Embargoed's addition will also need a small DB patch (since we hardcode (3, 4, 5) in a couple of places), though it can be applied live whenever so it isn't blocked by the current fdt embargo
[06:17] <wallyworld_> wgrant: i can land the branch first i think
[06:18] <wgrant> Yeah
[06:18] <wgrant> Embargoed branches just won't be visible to anyone but admins in searches
[06:18] <wgrant> And if any exist on production we'll need to poke them with a stick after the patch to make them work.
[06:18] <StevenK> wgrant: No review?
[06:18] <wgrant> StevenK: pgkillactive ate my homework
[06:18] <StevenK> Sure sure
[06:19] <wallyworld_> in that case  i might do the db patch first
[06:20] <wgrant> wallyworld_: No need. Embargoed can't be set unless the sharing_policy allows it, and only commercial admins can set sharing_policy
[06:21] <wgrant> So unless One of Us™ does bad things, Embargoed can't exist on prod yet
[06:21] <wallyworld_> ok. it should be a very simple db patch, so hopefully can be done soon
[06:21] <wgrant> Yeah
[06:21] <wgrant> Just need to find things that hardcode (3, 4, 5) and replace them with (3, 4, 5, 6)
[06:22] <StevenK> wallyworld_: Change the comments too
[06:22] <wgrant> I suspect we'll eventually keep a private flag around to eliminate that, but we don't have such a flag atm.
[06:22] <wallyworld_> in the db patch, sure?
[06:23] <wgrant> BAH
[06:23] <wgrant> Firefox
[06:23] <wgrant> stop crashing
[06:24] <wgrant> Oh
[06:24] <wgrant> I reenabled Firebug
[06:24] <wgrant> That's right
[06:24] <StevenK> Haha
[06:31] <StevenK> wgrant: Still no review?
[06:31] <wgrant> StevenK: r=me, but you should be able to delete a bit more
[06:31] <wgrant> Heh
[06:37] <StevenK> Heh, there's another +7/-41
[06:38] <wgrant> StevenK: What'd you do?
[06:38] <wgrant> makeProduct?
[06:38] <StevenK> And dropped the two tests you suggested.
[06:40] <StevenK> wgrant: http://pastebin.ubuntu.com/1150152/
[06:41] <wgrant> StevenK: Great.
[07:04] <StevenK> wgrant: Oh, is there a bug for this bug supervisor mess?
[07:08] <wgrant> StevenK: Bug #483521, bug #595933, bug #688956, bug #855121, bug #1029724, bug #113825 are possibly relevant
[07:08] <wgrant> You've fixed at least some of them
[07:11] <StevenK> wgrant: Indeed, let me link some of them
[07:26] <adeuring> good morning
[11:15] <cjwatson> oww, landing Launchpad branches in an environment that disallows outgoing ssh is an unpleasant experience
[11:15]  * cjwatson tries to cobble together something with paraproxy before giving up and sorting out an all-out VPN
[12:45] <czajkowski> gary_poster: what is a stretch goal, longer than a week ?
[12:47] <gary_poster> czajkowski, officially, it means that we don't expect to get it done this week, but it's possible we could get to it if we do particularly well--if we stretch ourselves.  unofficially, it means that I set the goal before I realized how little staff availability we had this week, and adjusted the goals after the fact as I was writing the blog post. ;-)
[12:48] <czajkowski> gary_poster: ahh :)
[12:48] <czajkowski> sounds good to me
[12:48] <gary_poster> :-)
[12:49] <czajkowski> gary_poster: shall me telling mrevell this in future :)
[12:49] <gary_poster> czajkowski lol
[12:49] <mrevell> :)
[13:05] <deryck> Morning, all.
[13:05] <czajkowski> deryck: ello
[13:09] <rick_h_> morning
[13:41] <cjwatson> stub,lifeless: it's wound up being unclear in +activereviews due to benji's null code approval, but https://code.launchpad.net/~cjwatson/launchpad/db-process-accepted-bugs-job/+merge/119320 is pending a db review
[13:41] <benji> cjwatson: sorry if I messed that up a little by doing that
[13:43] <cjwatson> I don't know either way - just occurred to me that the DB reviewers might be skimming over it
[13:45] <stub> Nah, I just have a crap filing system.
[13:45] <wgrant> 3
[13:45] <wgrant> bah
[13:47] <stub> I guess we want the id column purely because we share code with existing job stuff
[13:54] <cjwatson> That may actually have been inertia/cargo-culting on my part
[13:55] <cjwatson> But AFAICS all other job tables have id
[13:56] <cjwatson> Do you want me to try removing it?
[13:57] <deryck> adeuring, rick_h_ -- will have to be offline for 25 minutes here shortly, to catch ride with Wendy into the shop.
[13:57] <adeuring> deryck: ack
[13:58] <rick_h_> deryck: rgr
[14:58] <cjwatson> NCommander: FWIW I don't think it will make sense to put all of cdimage in LP even in the long term.  I think the right long-term approach is a web service to control image build scheduling (perhaps offspring) that uses LP for auth and for livefs builds.  The rest of it wouldn't gain much in the way of benefit from being in LP; we'll be more agile outside it.
[14:59] <cjwatson> NCommander: (Also, you may not be aware that we've had quite a few discussions about this recently in UE; and furthermore that I'm in the process of rewriting cdimage in Python for related-to-this and other reasons.)
[15:25] <cjwatson> stub: OK.  Does http://bazaar.launchpad.net/~cjwatson/launchpad/db-process-accepted-bugs-job/revision/11832 look OK on top of your previous review?  My SQL is way weaker than it should be, but this passes tests.
[15:28] <stub> cjwatson: That looks fine to me. You ran all the tests?
[15:28] <stub> cjwatson: I'm happy for you to land either version.
[15:31] <cjwatson> I ran the tests in my code branch that'll go with that DB branch
[15:31] <cjwatson> Well, the ones that were added/changed
[15:32] <cjwatson> But nothing else should be referencing that new table so that should be good enough
[15:32] <stub> Yeah, I don't think we have any code discovering job tables and doing stuff with them.
[15:32] <cjwatson> ... I hope
[15:34] <cjwatson> If there is something insane, EC2'll catch it anyway
[15:34] <mgz> you hope :)
[15:35] <jml> is the 'merge queue' stuff on branches ever used by anyone?
[15:36] <mgz> I don't think so.
[15:40] <jml> in launchpadlib, is there a way to get the underlying dict of the object?
[15:42] <jml> x._wadl_resource.representation seems to do the trick
[15:58] <sinzui> jml: that is exactly what I do in my python that feeds my js scripts
[15:59] <jml> yeah
[16:00] <cgoldberg> jcsackett, got any time for a review ?   I have an MP to lp-dev-utils
[16:00] <cgoldberg> I have an update to lp-dev-utils that allows page-performance-reports.py (PRR) to parse Apache Access logs.  I'm trying to get it deployed this week for some account services apps.
[16:03] <jml> sinzui: I was just sitting here thinking, wouldn't it be great if launchpadlib were just about dicts and functions
[16:04] <sinzui> +1
[16:05] <jcsackett> cgoldberg: sure. link?
[16:13] <jcsackett> cgoldberg: nm, found the MP.
[16:13] <cgoldberg> jcsackett, thanks.  https://code.launchpad.net/~coreygoldberg/lp-dev-utils/ppr-access-parser/+merge/119409
[16:13] <cgoldberg> jcsackett, back in a few mins if you wanna discuss anything
[16:39] <jcsackett> cgoldberg: ping.
[16:39] <cgoldberg> jcsackett, pong
[16:39] <jcsackett> cgoldberg: so, if i'm understanding this correct, you're adding this functionality to get performance reports from entirely different services? it seems like it might be cleaner to just create a new script.
[16:41] <cgoldberg> jcsackett, my thoughts at first also.. but lifeless thought it should just be integrated with a new [parser] option... 90% of the script is the aggregation and stats logic..
[16:42] <jcsackett> cgoldberg: fair enough. in that case, i'm writing up some notes i'll post to your MP.
[16:42] <cgoldberg> jcsackett, great thanks!
[16:50] <jcsackett> cgoldberg: comments on your MP. needs a bit of fixing, but nothing major.
[16:50] <cgoldberg> jcsackett, k.. will look and fix up
[17:24] <cgoldberg> jcsackett, regarding MP comments.  the create_request_class function was done for exactly what you described
[17:25] <cgoldberg> the servers this will run on will not have launchpad  or dependent code installed.. so importing from zc isn't really possible
[17:39] <jcsackett> cgoldberg: that seems like another really strong reason to not use lp-dev-utils.
[17:41] <cgoldberg> jcsackett, i don't disagree :)  I'll talk to lifeless
[17:42] <jcsackett> cgoldberg: i don't want to block you longer on this; if lifeless has already indicated this should be part of lp-dev-utils, i would say just fix the other import issue i highlighted and leave an XXX comment on create_request_class indicating it needs to exist for the zc import reasons but could be cleaned up if we separated these functions out, ok? (XXX comment style can be found here: https://dev.launchpad.net/PolicyandProcess/XXXPolicy)
[17:43] <cgoldberg> jcsackett, thanks much.. that sounds good.
[17:43] <cgoldberg> i'll add comment and re-push
[17:43] <jcsackett> cgoldberg: yw. ping me when you've done that and i'll mark as approved. also: you can skip the bug part, since there's not a clear bug to my mind, it's just a non-ideal setup.
[17:44] <jcsackett> (the bug=nnn bit in the comment)
[17:44] <cgoldberg> gotcha
[18:18] <jml> I am a horrible person: http://paste.ubuntu.com/1151164/
[18:18] <jml> sinzui: ^^
[18:20] <sinzui> jml: I think that style is easier for most developers to adopt.
[18:21] <jml> sinzui: if I did it right, the number of HTTP requests would be deadly obvious, or at least easily discoverable.
[18:22] <sinzui> jml: the sharing service we wrote ignore the model. It focuses on your intent and lets you perform bulk actions on collections. Our js just pulls dicts from urls
[18:22] <jml> sinzui: "sharing service"?
[18:25] <sinzui> The API service we wrote to share information types with people. Visit the +sharing page of any of you projects. The page doesn't have data in it. The js pulls what it needs to get just what it needs quickly
[18:25] <jml> sinzui: oh cool.
[18:25] <jml> sinzui: I was secretly hoping it was actually a separate service
[18:27] <jml> I guess lifeless would say that my API should probably also specify which scalar values I want
[18:27] <jml> from previous conversations about DB querying
[18:30] <sinzui> Maybe. We wrote our methods to return the dicts we knew were needed. The service is not arbitrary. Your does not need to be arbitrary, and maybe it should not expand everything given API my change and your script will slow down
[18:57] <deryck> jcsackett, hi there.  I have a branch for review if you have time.
[19:57] <lifeless> jml: mail me about your API, if you want an eyeball cast on it
[20:07] <jml> lifeless: ok.
[20:27] <lifeless> flacoste: http://bmfiddle.com/
[20:29] <sinzui> That must be an American company. "Fiddle Now!"
[20:29] <sinzui> jcsackett: do you have time to review https://code.launchpad.net/~sinzui/launchpad/change_branch-info-type/+merge/120011
[20:30] <jcsackett> sinzui: yes.
[20:31] <jcsackett> deryck: btw, missed your earlier ping, but your branch is r=me.
[20:31] <jcsackett> sinzui: looking at yours now.
[20:35] <deryck> jcsackett, thanks!
[20:36] <jcsackett> sinzui: r=me.
[20:36] <sinzui> thank you jcsackett
[23:12] <NCommander> cjwatson: I was aware of the efforts to rewrite cdimage in python, and I knew that having LP doing livefs builds were discussed (as far back as a few years ago).
[23:20] <NCommander> cjwatson: generally when it comes to web-based infrastructure I like to have as few different tools as possible. Launchpad is responsible for packages (and soon livefs building), I rather not split it out into another tool that has to existed in a void. Launchpad is the proper place for it, if anything offspring should be merged into LP for an intergrated experience