[01:15]  * mwhudson stares at a pqm regex failure mail
[01:16] <wgrant> mwhudson: Um, not choking on self-signed certs is a feature?
[01:16] <mwhudson> wgrant: for svn imports, yes
[01:18]  * mwhudson sighs
[01:18] <mwhudson> release-criticial=flacoste
[01:33] <james_w> has edge still not rolled out with my task_age fix?
[01:34] <maxb> It would be really quite nice if someone could get around to making xx-resetpassword-of-sso-account.txt not be an unavoidable test failure for non-Canonicalites :-/
[01:54] <lifeless> hey, who would be a good person to chat to about tweaking the CoC signing workflow
[02:55] <mwhudson> rockstar: you there?
[02:55] <rockstar> mwhudson, yes.
[02:55] <mwhudson> rockstar: can you triage https://bugs.edge.launchpad.net/launchpad-code/+bug/497603 ?
[02:55] <mup> Bug #497603: Y.codereview.connect_links creates a new picker every time the link is clicked <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/497603>
[02:57] <mwhudson> hm
[02:57] <mwhudson> i haven't had any email from launchpad for a few minutes
[03:41] <mwhudson> where's my patch -> branch feature
[03:52] <kfogel> mwhudson: whoo hoo!  That branch we were ec2-ing earlier has passed all tests and, it seems, landed.  *relief*
[03:53] <kfogel> matsubara: thanks for marking all that stuff Fix Committed.
[04:13] <devmod> hello
[04:14] <devmod> So, im trying to install launchpad and im running the script and it gets stuck in "[#########\          ]  61430KB   163KB/s | Fetching revisions:Inserting stream" been sitting there for like 15 mins and no progress has been made... wondering if that is normal
[04:14] <kfogel> devmod: what version of bzr?
[04:16] <devmod> Bazaar (bzr) 2.0.2
[04:18] <kfogel> devmod: hunh.  That doesn't sound normal to me.  All I can suggest is upgrading bzr, to bleeding edge if necessary.
[04:19] <devmod> its the same version I have on my other ubuntu karmic machine
[04:21] <kfogel> devmod: temporary network error?
[04:22] <devmod> happened twice
[04:22] <kfogel> devmod: (I'd stick around to debug more, but it's 11:30pm where I am; I'm just here to get a couple of things done and then zzzzz.  Sorry not to get more engaged :-(  ).
[04:22] <devmod> that is ok thanks
[04:23] <kfogel> spm: is there anything we can do to ensure that db-devel (in particular, the recently-landed http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8961) gets deployed to staging "soon"?  I'm not sure if that's an automatic process that just happens to take ~1day, or if there is prodding I'm supposed to do.
[04:24] <spm> kfogel: it's automatic; and if there's DB changes, hastening it is a Really Bad Idea™
[04:24] <kfogel> devmod: Don't know what TZ you're in, but there should be more people in a few hours.
[04:24] <kfogel> devmod: UK time morning, you see
[04:24] <devmod> oh yeah EST here
[04:27] <kfogel> spm: there are DB changes, and I don't particularly need to hasten it, I just want to know that it will be available for Jorge Castro to use by EOD Thursday (he's giving a talk Friday morning, demo'ing against staging if he can).  I can't remember what TZ he is in right now -- I think US West Coast?
[04:28] <elmo> yes, US west coast
[04:29] <kfogel> elmo: thx
[04:30] <spm> kfogel: hmmm. that may be cutting it fine. fwiw: https://staging.launchpad.net/successful-updates.txt
[04:30] <kfogel> spm: hunh..  So every half hour it does... something?  What's it waiting for?
[04:31] <spm> updates it can apply; but if you have db updates; it (still does?) a full DB rewhatsit. which is ... slow.
[04:32] <spm> kfogel: as in a full staging restore takes something like 20 hours.
[04:32] <kfogel> spm: and how can we tell when that's started?
[04:33] <spm> kfogel: ps fuxww | grep restore. :-)
[04:33]  * kfogel growls
[04:33] <spm> one kicked off yesterday... trying to find the exact time
[04:35] <spm> kfogel: what revno are you waiting on?
[04:35] <spm> if 8955, that's currently doing an update to the DB as well; if > than that...
[04:35] <kfogel> spm: the one above
[04:35] <kfogel> spm: let me grab it
[04:36] <kfogel> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8961
[04:36] <kfogel> so, 8961
[04:37] <spm> hmmm. I may be able to break this and kick off a new restore.
[04:37] <devmod> I manually did "bzr branch lp:~launchpad-pqm/launchpad/devel lp-branches/devel/" and it got stuck on the same exact place "[#########|          ]  61430KB     0KB/s | Fetching revisions:Inserting stream" wth?
[04:37] <spm> devmod: any network activity still happening?
[04:38] <spm> kfogel: to verify. this one: Implement a "+patches" view on packages, products, project groups, series, persons, and teams.
[04:41] <kfogel> spm: right
[04:44] <devmod> what port would bzr branch lp: use?
[04:44] <spm> kfogel: oki, first problem - that hasn't landed on db-devel yet; is still in Buildbot.
[04:44] <spm> has ~ another 3.5 hours ETA
[04:49] <spm> devmod: 22, ssh. or also look for host 91.189.90.11
[04:50] <kfogel> spm: oh, that rev has to go through buildbot?
[04:50] <kfogel> first, I mean?
[04:50] <spm> kfogel: yup
[04:51] <kfogel> spm: wait, I'm confused.  I've updated db-devel here, and that rev is definitely present.
[04:51] <kfogel> I mean, it's in my branch here, which is just a branch of db-devel.
[04:51] <spm> staging is db-stable
[04:52] <spm> kfogel: https://dev.launchpad.net/Trunk (pretty diagrams :-) )
[04:52] <kfogel> spm: so it moves from db-devel to db-stable after it's been through buildbot?
[04:52] <spm> right
[04:53] <kfogel> spm: diagram is very helpful, thanks
[04:53] <spm> the idea was to get *a* landing is fast; get an approved and tested landing; happens; and gets a bunch of other merges in one hit; but only after testing is it applied to staging; and hence makes for a 4 step process diagram.
[04:53] <spm> 4 branch - process/diagra
[04:59] <devmod> 04:59:04.674042 IP crowberry.canonical.com.www > 192.168.75.132.52521: Flags [R], seq 3835263603:3835263606, win 0, length 3
[04:59] <devmod> gets stuck there
[04:59] <devmod> win 0 ?
[04:59] <kfogel> spm: so basically, we shouldn't count on this being live on staging by Friday morning US west coast time, though it *might* happen, right?
[05:01] <spm> kfogel: the only way it's even got a chance is if I stop the existing restore; and hold pending that landing getting thru buildbot; and even then... yeah, cutting it fine.
[05:02] <kfogel> spm: urgk.  Well, I don't know how often these things come up.  Jorge wants to use it in a plenary talk on Friday.
[05:03] <spm> kfogel: is the DB side critical? as in the other changes as part of the set should be on edge; or soon will be?
[05:03] <kfogel> spm: the db changes are a critical part of the overall change, yes
[05:04] <kfogel> spm: this stuff hasn't landed on devel, afaik, since it needs its db changes.  It's only in db-devel.  So I'm not expecting to see it on edge right away.
[05:05] <spm> kfogel: oki; I'll see what I can do, but zero promises unf. these restores are not fast.
[05:06] <kfogel> spm: thank you.  I'm composing a mail to lp-dev; I'll make it clear that no promises are being made.
[05:45] <kfogel> spm: g'night
[05:45] <kfogel> well, g'afternoon
[05:45] <kfogel> zzz
[05:45] <spm> kfogel: likewise!
[05:45] <spm> heh
[08:41] <thekorn> hi, bug 515761 is about not being able to get collections correctly when using this anonymous API feature,
[08:42] <mup> Bug #515761: Not able to access collections anonymously <launchpadlib :Confirmed> <https://launchpad.net/bugs/515761>
[08:42] <thekorn> what is the correct bug target for this, launchpadlib looks wrong to me
[08:52] <wgrant> thekorn: launchpad-registry.
[08:52] <wgrant> Or is it all collections?
[08:52] <bigjools> hello hackers
[08:53] <thekorn> wgrant, looks like all collection, maybe it's lazr.restful?
[08:53] <wgrant> It could be.
[08:53]  * wgrant looks.
[08:56] <bigjools> al-maisan: morning.  Did you get far with bug 516922?
[08:56] <mup> Bug #516922: process-pending-packagediffs breaking <Soyuz:Triaged> <https://launchpad.net/bugs/516922>
[08:56] <wgrant> thekorn: It's not all collections. I am digging further.
[08:56] <al-maisan> bigjools: I did not start on it yet, looking at yesterday's bug.
[08:57] <al-maisan> bigjools: should I get going on Bug #516922?
[08:57] <mup> Bug #516922: process-pending-packagediffs breaking <Soyuz:Triaged> <https://launchpad.net/bugs/516922>
[08:57] <bigjools> al-maisan: yes this one is more important
[08:57] <al-maisan> bigjools: ack
[08:57] <bigjools> al-maisan: thank you
[08:57] <thekorn> wgrant, oh, so it seems like I had bad luck only picking collections where something goes wrong
[08:57] <al-maisan> bigjools: de nada
[08:58] <wgrant> thekorn: eg. bug.bug_tasks works.
[09:06] <thekorn> wgrant, hmm, right
[09:10] <mrevell> Morning
[09:11] <wgrant> thekorn: Ahem.
[09:11] <wgrant> thekorn: I found the cause for product.series.
[09:12] <wgrant>     permision = 'launchpad.View'
[09:12] <wgrant> somebody cannot spell.
[09:12] <wgrant> thekorn: What other cases are there?
[09:12] <thekorn> wgrant, bug.messages and bug.subscriptions
[09:14] <wgrant> thekorn: Yeah, I see why this is all happening.
[09:15] <thekorn> wgrant, super, great, thanks a lot
[09:15] <wgrant> Basically, lazr.restful returns an object if you hold launchpad.View on it.
[09:15] <wgrant> Objects like messages and bugsubscriptions have no security adapters, so it falls to the root one.
[09:15] <asabil> hi all
[09:15] <wgrant> Which, in this case, is ('launchpad.View', Interface) -> ViewByLoggedInUser, which only allows authenticated users.
[09:15] <asabil> is it normal that the xmlrpc service is handled by codebrowse ?
[09:18] <wgrant> (I had actually wondered from the start how it knew to hide objects, given that I saw no way for it to happen reliably. I was right.)
[09:31] <thekorn> wgrant, so will the solution for this be to write security adapters for all affected collection, or might there be a more general solution?
[09:32] <wgrant> thekorn: I think ViewByLoggedInUser is probably a bug.
[09:32] <wgrant> thekorn: It should probably just be View.
[09:33] <wgrant> There may be a couple of places that it makes sense, but not many.
[09:33] <wgrant> It shouldn't be the default security adapter.
[09:47] <thekorn> wgrant, I think even if the typo is fixed IProductRelease will need a security adapter for launchpad.View in order to get a working product.releases, but this is just a minor side note ;)
[09:49] <wgrant> thekorn: Yes, the underlying issue needs to be fixed oto.
[11:24] <jml> thumper, time.mktime(date_time.timetuple())
[11:25] <jml> thumper, but! it fucks up timezones
[11:27] <jml> thumper, it doesn't actually, utctimetuple would
[12:05] <asabil> can someone help me with this: http://pastebin.com/d68e0056c ?
[12:06] <asabil> I am setting up launchpad manually to learn about things
[12:09] <asabil> anyone ?
[14:41] <mars> hmm, our "The Server is Down" page probably shouldn't try to load it's CSS from a file on self-said server...
[14:50] <mthaddon> mars: it's hosted statically so it doesn't matter
[14:53] <mars> mthaddon, ok, thanks.  Then the styling is just plain messed up.
[14:53] <mthaddon> could be, yeah
[15:12] <henninge> salgado-lunch: Hi, ping me when you get back, please.
[15:54] <thekorn> allenap, thanks for your review, looking at it now
[15:57] <matsubara> Chex, rockstar, bigjools, Ursinha, sinzui, allenap: LP production meeting in 3 min @ #launchpad-meeting
[15:58] <al-maisan> matsubara: bigjools is sprinting .. I'll stand in for him.
[15:58] <matsubara> henninge, ^
[15:58] <matsubara> thanks al-maisan
[15:59] <salgado> hi henninge
[15:59] <henninge> salgado: Hi! ;)
[16:00] <henninge> salgado: I have some ideas about the LP security system and wanted to ask you if you know of any plans to work on it?
[16:00] <sinzui> EdwinGrubbs: can you attend the production #launchpad-meeting
[16:01] <salgado> henninge, if I have plans to work on it or if there's any work planned on that area at all?
[16:02] <henninge> salgado: in general. I am talking to you because I thought that this falls into your team's expertise.
[16:03] <henninge> salgado: I could just put my ideas out on the mailing list or a wiki page or a blueprint but thought I'd checked if any work in that direction is already planned.
[16:03] <salgado> henninge, it does, yes, but I'm not aware of any planned work on that area
[16:04] <henninge> salgado: do you use blueprints, bugs or wiki pages to collect plans/ideas?
[16:04] <henninge> Or should I start with an RFD on the ML?
[16:05] <salgado> henninge, bugs, mostly, but I guess a RFD on the ML would be good in this case
[16:05] <henninge> salgado: cool, will do that. Thanks.
[16:38] <jml> intellectronica, great link!
[16:38] <jml> sinzui, http://www.runleiarun.com/lebowski/
[16:41] <intellectronica> oh, it's amzing
[16:41] <intellectronica> it's this kind of stuff that restores my faith in the internet
[16:47] <jml> intellectronica, well put :)
[17:20] <jtv> good night, folks!
[17:53] <jml> you guys
[17:53] <jml> your coding standard is basically stupid
[17:53] <jml> how come functions and methods are differently formatted?
[17:53] <jml> is there a thing that makes them different?
[17:57] <intellectronica> jml: one you can have in java and the other you can't
[17:57] <intellectronica> we're industry standard like that
[18:07] <didrocks> hey, I can't remove some token from my authorized applicatoin list today (from production or edge server): https://edge.launchpad.net/~didrocks/+oauth-tokens
[18:08] <didrocks> I got a "Sorry, you don't have permission to access this page. You are logged in as Didier Roche."
[18:08] <didrocks> when trying to revoke an authorization
[18:17] <maxb> didrocks: It got broken in the last rollout. Let me find the bug number....
[18:18] <maxb> bug 511567
[18:18] <mup> Bug #511567: Can't remove authorised oauth tokens <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/511567>
[18:18] <didrocks> maxb: thanks, I'll follow it
[18:24] <didrocks> btw, do someone have any clue about the crash I got trying to install LP locally to extend Launchpad API? (http://pastebin.com/f5426fbab)
[18:37] <jamalta> would you guys care if i make the community-contributions script merge the 3 version of me? ... i kinda ruined the count there, heh
[18:40] <EdwinGrubbs> salgado: ping
[18:42] <intellectronica> didrocks: did you use rocketfuel-setup to install?
[18:42] <salgado> hi EdwinGrubbs
[18:44] <EdwinGrubbs> salgado: are you the person to ask questions about adding a launchpad-dependency and a package to the PPA? I saw the wiki page, but it didn't really have any guidelines.
[18:45] <salgado> EdwinGrubbs, I used to be responsible for that, but since we moved to a PPA I'm not.  I might be able to answer any questions you have, though
[18:46] <jamalta> also, could i get some input for bug #515761?
[18:46] <mup> Bug #515761: Anonymous API access to some collections returns nothing <Launchpad Foundations:Confirmed> <https://launchpad.net/bugs/515761>
[18:47] <EdwinGrubbs> salgado: I was just going to have PIL 1.1.7, which is already in Lucid, rebuilt for Karmic in the PPA and add that to the launchpad-developer-dependencies. Do I need to get any review of that work?
[18:48] <maxb> We lack defined process for this
[18:49] <maxb> I don't think there's been a case of needing a backported version of a python library in the PPA before
[18:50] <salgado> we had a backported python-apt, IIRC
[18:50] <maxb> You'd have to also backport to hardy and jaunty (or first get jaunty de-supported and deleted from the PPA)
[18:51] <maxb> The closest recent occurrence would be a backported dpkg
[18:52] <maxb> If there was a backported python-apt, I think it must have been pre-opensourcing
[18:57] <salgado> it was
[18:58] <salgado> EdwinGrubbs, so, as maxb pointed out, there are a few extra steps you might have to take.  although we don't require a formal review, it's probably a good idea to email the list about it
[19:01] <EdwinGrubbs> salgado: ok, thanks
[19:17] <mwhudson> good morning
[19:32] <didrocks> intellectronica: right (sorry for the delay). But it failed because of wrong bzr base version on one of your LP branch. james_w fixed it locally for me and opened a bug. Then, I tried to continue the process and run the command I pastebin
[19:34] <james_w> didrocks: try a ./utilities/rocketfuel-get
[19:48] <lifeless> abentley: what does 'xvfb-run xdypinfo' do for you?
[19:49] <abentley> lifeless, /usr/bin/xvfb-run: 180: xdypinfo: not found
[19:51] <lifeless> bah
[19:51] <lifeless> dpy :)
[19:52] <lifeless> I don't care about the particular output, just whether it errors or not
[19:53] <abentley> lifeless, http://pastebin.ubuntu.com/369066/
[19:53] <abentley> lifeless, no error if I run xdpyinfo
[19:53] <lifeless> ok so the base server seems to be happy
[20:10] <didrocks> wgrant: do you know about something special to do for installing LP on lucid? it seems it can't import bzrlib as python2.5 is in my path in the devel/lib/devscripts/sourcecode.py and not 2.6?
[20:14] <jamalta> i have to close firefox to run bin/test, haha
[20:18] <maxb> didrocks: ah, yes. update-sourcecode is a special case
[20:18] <didrocks> maxb: any hint about changing that? adding python2.6 in the path in the script?
[20:19] <didrocks> be back in a minute
[20:19] <maxb> didrocks: I think it should work if you just change the shebang in update-sourcecode to be /usr/bin/python
[20:22] <didrocks> maxb: oh right, let's try this
[20:27] <didrocks> maxb: apparently, it didn't crash (yet :)) and I'm getting more branch back. Thanks a lot!
[21:21] <EdwinGrubbs> mars: ping
[21:22] <mars> hi EdwinGrubbs
[21:25] <EdwinGrubbs> mars: I'm sorry to pester you again. Did you want to take a look at my sprite implementation? I have something that will work, so I could just get it ready for review, but you seemed interested in the design.
[21:26] <mars> EdwinGrubbs, I did read it.  Reviewing it again now...
[21:27] <mars> EdwinGrubbs, why do the makefile targets not depend on the files they output?
[21:28] <mars> I could ask the same for combine-css
[21:28] <EdwinGrubbs> mars: because I'm not finished with the branch yet.
[21:28] <mars> lol
[21:29] <EdwinGrubbs> mars: I think someone else is working on combine_css so I should check that I don't conflict with their changes.
[21:30] <mars> I don't think anyone has touched that yet.
[21:30] <mars> funny, I thought it would be a big deal to fix the combine_css step
[21:31] <mars> turns out you just have to rewrite the Makefile target to Do The Right Thing (that being, depend on the generated file)
[21:31] <EdwinGrubbs> mars: now that I think about it some more, I believe rockstar was going to work on that when he becomes chr, so he probably hasn't started on it.
[21:31] <rockstar> mars, I'm already working on that.
[21:32] <rockstar> mars, I said in our meeting on Monday that I'd be working on that.
[21:32] <rockstar> So shame on you for not listening...  :)
[21:32] <mars> rockstar, yep!  I remember.  So does EdwinGrubbs
[21:33] <mars> rockstar, but if you haven't fixed it, maybe Edwin can, as he will probably be rewrite and testing his Makefile targets in the exact same way.
[21:33] <EdwinGrubbs> rockstar: out of curiosity, is your fix going to be smart enough to regenerate combo.css if any of the twenty odd individual css files are updated?
[21:34] <rockstar> EdwinGrubbs, it doesn't in its current form in my branch, but I need to look into why, because make is supposed to figure out that when those files change, it has to re-create the target.
[21:34] <rockstar> EdwinGrubbs, basically, we're doing something with the Makefile that is against nature.
[21:34] <mars> hehe
[21:35] <mars> EdwinGrubbs, I liked the "PIL as a developer dependency" bit
[21:35] <mars> that part makes sense
[21:36] <maxb> I have two changes to update-sourcecode to submit: (1) Make it not break if you have bzr-git installed. (2) Make it not pull sourcecode branches if there is no update, to avoid triggering bzr-dbus/bzr-gtk notifications for every sourcecode branch.    Should I submit them as one branch or two?
[21:36] <EdwinGrubbs> mars: is there anything that doesn't make sense?
[21:36] <mwhudson> maxb: one sounds ok to me
[21:37] <mars> rockstar, sorry, I didn't realize you were rolling up a bunch of stuff into one branch like that.
[21:38] <rockstar> mars, well, it's all relatively related.
[21:39] <mars> EdwinGrubbs, the contents of icon-sprites.positioning is confusing.  Is it JSON or something?
[21:39] <mars> no, python?
[21:40] <EdwinGrubbs> mars: yes, it's json, but it could just as easily be a pickled object.
[21:40] <mars> oh no thank you!  JSON is better.
[21:40] <mars> EdwinGrubbs, so that file is a build system output?
[21:41] <rockstar> mars, basically, we need separate targets for css and js combinations.
[21:42] <mars> rockstar, yes, that would make things sane again.  Are you going to try and move those targets out of the main Makefile?
[21:42] <rockstar> mars, I don't see any benefit to doing that.
[21:42] <EdwinGrubbs> mars: actually, that file is a build system input. You have to commit it when you commit icon-sprites, so that "sprite-util create-css" knows what background-position to set for each sprite.
[21:43] <rockstar> It just means it's harder to find when someone wants to make changes to it.
[21:43] <mars> rockstar, ah.  I was worried that trying to clean up the static build system would lead to an explosion of targets (css, js, images)
[21:43] <mars> EdwinGrubbs, ok, is the file edited by hand?
[21:43] <mars> whether it is or not is not clear from the diff context
[21:47] <mwhudson> abentley: my main thought in response to your recent email is
[21:47] <mwhudson> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
[21:48] <abentley> mwhudson, +1
[21:48] <EdwinGrubbs> mars: no, icon-sprites.positioning is generated by "sprite-util create-image" using the savePositioning() method.
[21:48] <mars> abentley, is mozrunner playing shenanigans on module import?
[21:48] <abentley> mars, yes.
[21:49] <mars> EdwinGrubbs, ok, that is not clear from the context.  Does that file have a warning and developer instructions at the top?
[21:49] <abentley> mars, there is a function definition where the default is os.environ['PATH']
[21:49] <mars> abentley, argh
[21:50] <mars> abentley, do you have the source line?  I can ask about a fix in #windmill if you like
[21:50] <abentley> mars, windmill/dep/_mozrunner/global_settings.py: 42
[21:51] <mars> if it is fixed in trunk/ then we might be able to do a quick backport patch
[21:51] <mars> abentley, cool, thanks
[21:52] <EdwinGrubbs> mars: that's a good idea. I'll put a warning at the top. It seems a little strange to use json for this, but it is nice that it is human readable. Of course, a pickle would discourage people from editing it by hand.
[21:54] <mars> EdwinGrubbs, I think a message will suite better.  That way you can tell the developer "Here is how you fix this file".  A pickle is just mysterious and confusing.
[21:55] <mars> abentley, ah, a violation of the "use None for default keyword arguments" convention
[21:55] <mars> that should be a trivial patch
[21:56] <mars> but I must go and take care of the twins for a minute.  bbiab
[21:57] <mars> abentley, but unfortunately I have no idea how to update the windmill package we use :(
[21:57] <mars> beyond my ken
[21:57] <mars> rockstar, you are build engineer, perhaps that falls under your domain? :)
[21:57]  * rockstar reads backchat
[21:59] <rockstar> mars, I say "file a bug and assign it to me"
[22:00] <maxb> Is there a standard for order of import statements? dev.lp.net/PythonStyleGuide is not very forthcoming on that aspect
[22:00] <rockstar> mars, I'd like to do as much work on windmill as I can, but my specific target as build engineer is getting it so that our javascript file can be bigger than 500K.
[22:04] <wgrant> didrocks: The only changes that I need are to use Karmic's python-pkg-resources and python-setuptools.
[22:04] <mwhudson> maxb: generally it goes system imports, blank line, "local" (i.e. sourcecode & egg imports), blank line, launchpad imports
[22:04] <mwhudson> maxb: alpha sort within each section
[22:05] <wgrant> ie. PEP8
[22:46] <mars> rockstar, ok
[22:46] <mars> abentley, looks like windmill is kept as python library dependency, and that we are already keeping a patch of some sort
[22:46] <mars> upgrading it should be trivial
[22:47] <mars> 'simple'