[00:00] <barry> #startmeeting
[00:00] <MootBot> Meeting started at 18:00. The chair is barry.
[00:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[00:00] <barry> jml, rockstar, mwhudson hi!
[00:01] <mwhudson> barry: hello
[00:01] <rockstar> Hi barry
[00:01] <jml> hi
[00:01] <barry> so, shall i do a quick update from ameu?
[00:01] <jml> yes please
[00:02] <barry> there was no ui meeting on monday, so nothing to report there
[00:02] <barry> * `__iter__()` in model objects?
[00:02] <barry> we agreed that __iter__ should be avoided except in the case of IFnordSets iterating over IFnords
[00:02] <barry> i should say "except possibly"
[00:02] <barry> no mandate, but it's okay
[00:03] <jml> what was the reasoning?
[00:03] <barry> for things that aren't naturally collections, it's hard to know from looking at the call site what you're iterating over
[00:04] <barry> cprov had a specific example that came up in a review and __iter__() just made things harder to understand
[00:04] <barry> * mkstemp()/open() combination leaks file-descriptors
[00:05] <barry> reviewers have to watch out for these calls when the code does not clearly close the open fd they return
[00:05] <rockstar> Ah yes.  I reviewed a fix for this last week.
[00:05] <barry> general call for questioning the opening/leaking of resources
[00:05] <barry> when you see it in a review, make sure that the resource is being closed
[00:06] <jml> barry, one nice workaround in test code is to have a wrapper method that calls mkstemp and then calls addCleanup appropriately
[00:06] <jml> and then returns what mkstemp returns
[00:06] <barry> jml: right.  that was brought up (or something along those lines)
[00:06] <jml> naturally, that won't stop prod leaks
[00:07] <barry> flacoste suggested using mkdtemp  and then creating files as needed in the directory, blowing the whole dir away in the cleanup
[00:08] <jml> I tend to do that.
[00:08] <barry> yep
[00:08] <barry> * Guidelines changes for tests checking systems pre-requisites (specific umasks, app configurations)
[00:09] <barry> this came up because maxb got bit by a umask sensitivity in the tests
[00:09] <barry> and i remembered fixing a bunch of these ages ago when i first joined
[00:09] <barry> (cause my umask isn't 022)
[00:10] <barry> the general rule is, if the code requires a specific umask, then put it in the code and test for it, otherwise fiddle the umask in the test
[00:10] <barry> the general guideline is, don't assume the user env is the default ubuntu user env
[00:10] <jml> ok.
[00:10] <mwhudson> i guess the hard part is that most of the time you won't realize you're depending on the umask
[00:10] <mwhudson> but it's a good principle i guess
[00:11] <barry> mwhudson: right.  i think in general we're pretty good right now.  maxb found one failing test in archives which was checking a file perm, and thus relying on umask
[00:11] <mwhudson> oh right
[00:11] <barry> * Invalid markup; The <script> tag requires a close tag (Do not: <script type="text/javascript" src="..."/>)
[00:12] <maxb> the other aspect was invocations of devscripts tools which could be affected by ~/.devscripts. I'm going to do some grepping and liberally sprinkle --no-conf around
[00:12] <jml> well, the more likely mistake is code that fails because it implicitly relies on a umask and is not tested
[00:12] <barry> maxb: ah, i didn't know about that one
[00:12] <jml> maxb, I didn't know about that _directory_
[00:13]  * barry neither
[00:13]  * mwhudson either
[00:13] <mwhudson> maxb: tell us, what does it do? :)
[00:14] <mwhudson> barry: shouldn't invalid <script> tags be caught by make lint?
[00:14] <maxb> directory? ~/.devscripts is a conf file for tweaking the behaviour of the devscripts tools
[00:14] <mwhudson> oh right
[00:14] <maxb> when you tweak the behaviour of dch.... the tests get a bit upset :-)
[00:15] <jml> oh right.
[00:15] <barry> mwhudson: problem is, our lint only checks the templates, not the generated html
[00:15] <mwhudson> barry: oh yes
[00:16] <mwhudson> barry: and we have to generate <script> tags in strange ways because TAL*(&(*&(*&)(*
[00:17] <jml> so!
[00:17] <barry> right.  curtis gave some good background on what we do now, and what he hopes to do later.  there was some discussion about validating the html in the tests, which nobody much liked, validating on staging (or was it edge), etc.  no resolution for what we'd eventually like to do
[00:17] <barry> so reviewers just have to watch out for that
[00:17] <barry> and empty <p></p> which apparently ain't kosher either
[00:17] <barry> that's it for ameu update
[00:18] <jml> yay
[00:18] <mwhudson> barry: is chameleon brain dead in the same way in this respect?
[00:18] <jml> barry, one thing on the __iter__ guidelines.
[00:18] <barry> mwhudson: didn't come up, and i don't know
[00:18] <barry> jml: k
[00:18] <mwhudson> jml: operator overloading is evil, don't do it?
[00:18]  * mwhudson hopes
[00:18] <jml> barry, I'd prefer it if we wrote that up as "don't use __iter__ for things that aren't obviously collections"
[00:19] <jml> mwhudson, operator overloading is great.
[00:19] <barry> jml: that's how bigjools worded it, which seemed perfect to me
[00:19] <jml> barry, cool.
[00:19] <mwhudson> jml: when correctly applied, yes
[00:19] <jml> barry, I was a little worried about restricting it to IFooSet or whatever.
[00:19] <mwhudson> branch_set[id] was not a good application :)
[00:20] <barry> so.  i will now open the floor to y'all.  anything on your mind today?
[00:20] <jml> mwhudson, agreed.
[00:20]  * jml does
[00:20] <barry> jml: ga-head
[00:20] <jml> two things
[00:21] <jml> the first is that I don't know the canonical page to get code review policy from...
[00:21] <jml> is https://dev.launchpad.net/StyleGuides is ?
[00:21] <jml> if so, it's a lot of stuff
[00:22] <jml> the second is that I've been telling people to use the cover letter template as checklist, and not feel obliged to fill in every section.
[00:23] <jml> which may have been overstepping the mark
[00:23] <barry> jml: #1 do you mean canonical page for our coding guidelines, or for requesting reviews?
[00:23] <jml> barry, guidelines
[00:23] <jml> barry, what I have to look at as a reviewer / patch submitter to see if a patch passes.
[00:24] <barry> yeah, that's the page, although gary and i have an action item we suck at to migrate stuff on the internal wiki (and old old internal wiki) into here.  it would be nice to find some time to clean those pages up too, but don't hold your breaht
[00:24] <barry> er, breath
[00:25] <mwhudson> barry: go go go!
[00:25] <mwhudson> :)
[00:25] <jml> barry, I understand the difficulty
[00:25] <jml> and it sure is a tedious task
[00:26] <barry> jml: but i understand the need to clarify and make concise.  seems like a general problem with wiki info (he says nearly completing this month's chr penance)
[00:26] <jml> but at the rate we are accruing legislation, I'd be quite surprised if any reviewer had everything in their head...
[00:26]  * barry does :)
[00:26] <jml> barry, problem is, how can we tell :)
[00:26] <barry> jml: just ask me :)
[00:26] <jml> haha
[00:26] <barry> but that's a joke.  i really don't either
[00:27] <barry> jml: i wouldn't be surprised to see a lot of stuff slip through, but at least if either the dev or reviewer remembers, they have a place to look
[00:27] <mwhudson> barry: can i call you at 4am to ask for clarification?
[00:27] <barry> mwhudson: sure.  your 4am
[00:28] <mwhudson> barry: :)
[00:28] <barry> :)
[00:28] <jml> barry, having those pages cleaned up would be great.
[00:28] <barry> jml: seriously though, i'm very sympathetic, i just don't have a good answer
[00:28] <jml> np
[00:29]  * mwhudson hands barry a +1 sword of crap deletion
[00:29] <jml> the other thing was the cover letter
[00:29] <barry> cover letter, right!  do you use the lpreview-body bzr plugin?
[00:29] <jml> no, I don't.
[00:30] <jml> but also, I don't tell other people to do so.
[00:30] <barry> it's pretty simple, but it gives you a standard template in the mailer of you choice, and i do think it's a good idea to fill everything out
[00:30] <barry> it's also not hard
[00:30] <jml> I agree with the spirit of it
[00:30] <barry> jml: but... ?
[00:31] <jml> but I don't feel like telling community contributors to fill out another form before I review their patch
[00:31] <jml> and I'm happy enough if people demonstrate that they've thought about each of the items on https://dev.launchpad.net/QuickCoverLetterTemplate
[00:31] <barry> jml: that's a good point.  we get paid to do menial tasks :)
[00:31] <mwhudson> i think the point is that the reviewee gets the information to the reviewer
[00:32] <mwhudson> the cover letter template is a handy checklist, no more
[00:32] <jml> mwhudson, thank you :)
[00:32] <jml> barry, what he said.
[00:32] <mwhudson> checklists are great, btw
[00:32] <rockstar> Just mentioning you've thought about it should suffice.
[00:32]  * jml loves checklists
[00:32] <barry> agreed!  i'm all for streamlining the process, especially for community contributors
[00:32]  * rockstar can't use lpreview-body in his hardy chroot
[00:33] <jml> barry, as for me, I like using the web ui, just so I can be using the web ui :)
[00:33] <mwhudson> sounds like resounding agreement
[00:33] <jml> yay
[00:33]  * jml is done
[00:34] <barry> yep.  though i do have to say that when i'm reviewing i find a filled out cover letter to be very helpful.  tbh, when i'm submitting a branch too
[00:35] <barry> there might also be a difference between the ameu workflow and asiapac workflow, as in how interactive you can be, how big the queue is, etc.
[00:35] <barry> so i say, use what works for you
[00:35] <jml> +1
[00:35] <mwhudson> i think we should certainly recommend the cover letter
[00:36] <barry> mwhudson: i'd go a little further.  if you're queuing up for +activereviews, a cover letter is much more important.  if you're doing a highly interactive one, much less so
[00:36] <mwhudson> barry: right
[00:36] <barry> as you say, the important thing is to communicate the info, however that happens
[00:37] <jml> btw
[00:37] <jml> putting it out there
[00:37] <jml> a flagon of $BEVERAGE to whoever makes a tool that submits a branch to Launchpad via ec2test based only on the MP page.
[00:38] <barry> tarmac?
[00:38] <rockstar> jml, you mean like Tarmac?
[00:38] <jml> rockstar, I don't know!
[00:38] <rockstar> I'm sure we could probably do something like that.
[00:38] <rockstar> jml, let's talk after this.
[00:38] <mwhudson> jml: get rockstar to do it, he won't ask for a flagon of single malt
[00:38] <barry> rockstar: is a switch to tarmac in the cards after 3.0?
[00:39] <rockstar> barry, well, lp-oops is using it, and some ubuone folks.  We're working out kinks still.
[00:39] <mwhudson> abentley asked in today's call what PQM still does for us
[00:39] <rockstar> abentley broke Tarmac by changing the API - another hint that we need a versioned API.
[00:39] <mwhudson> over and above us just merging and pushing
[00:39] <barry> mwhudson: that's easy.  it crashes and obfuscates
[00:39] <rockstar> :)
[00:40] <jml> it checks for db changes in devel
[00:40] <jml> it enforces the testfix thing
[00:40] <rockstar> We can do this all very easily in Tarmac.
[00:40] <jml> (whether that is _for_ us or _against_ us is an open question)
[00:40] <rockstar> If all we're doing is merging, I'm not even sure why PQM does a build at all.
[00:40] <barry> testfix thing: hopefully much more transparently than pqm
[00:41] <barry> pqm does /not/ run in 5 minutes
[00:41] <rockstar> I think Tarmac will be a lot more useful when we have merge queues.
[00:41] <barry> btw, did someone make ec2 --headless detach more quickly recently?
[00:41] <jml> not I.
[00:42] <mwhudson> barry: a new AMI for ec2test will help a lot there
[00:42] <mwhudson> barry: i intend to do that today
[00:42] <barry> fantastic.  it did not seem to take 45m the last time i used it (more like 5-10 which was a pleasant surprise)
[00:43] <barry> could have been luck i s'pose
[00:43] <mwhudson> two things are very variable
[00:43] <mwhudson> 1) instance launch time
[00:43] <jml> rockstar, what I want is "submit https://code.edge.launchpad.net/~wgrant/launchpad/whatever/+merge/212", for it to take the commit message, target branch and reviewer info and submit it to ec2test.
[00:43] <mwhudson> 2) make schema time
[00:43] <jml> rockstar, tarmac's README implies it does something else.
[00:43] <mwhudson> (making schema before detaching is insane, but...)
[00:43] <barry> mwhudson: yep.  would be nice to detach asap
[00:43] <rockstar> jml, yea, like I said, we should talk after the meeting.  I'm sure my documentation skills are pure suckage.
[00:44] <mwhudson> barry: i hope to get to that before I run out of BE time
[00:44]  * jml assumed that it was after the meeting :)
[00:44] <barry> rockstar: use sphinx
[00:44] <mwhudson> (or sanity, whichever comes first)
[00:44] <barry> jml: yes.  i think we're done.  any objections?
[00:44] <mwhudson> nope
[00:44] <rockstar> Nope.
[00:44] <barry> #endmeeting
[00:44] <MootBot> Meeting finished at 18:44.
[00:44] <barry> thanks guys.  i'm off to dinner
[00:44] <rockstar> jml, okay, so Tarmac.
[00:45] <rockstar> Tarmac is just a script that goes out to find Approved merge proposals against a branch (currently only the development focus) and merges them automatically.
[00:45] <rockstar> There are plugins to be hooked into it that can do all sorts of things.
[00:46] <rockstar> I'm curious to know what the README tells you.
[00:47] <jml> rockstar, that it's focused on projects, basically
[00:47] <jml> I'm just looking at the README in trunk
[00:47] <rockstar> Well, it is now.  My plan is that 0.3 is less about project development focus and more about branches.
[00:47] <jml> rockstar, I don't want auto-landing, I want to store all the information that's in my head about how to land branches in some sort of computer program
[00:48] <rockstar> jml, well, we can use the functionality from Tarmac, and maybe even just make it a Tarmac plugin.
[00:49] <rockstar> I think we can easily do it.  Even something like the old Atomic PQM analyzer would be nice.
[00:49] <jml> rockstar, what would using tarmac give me that launchpadlib doesn't?
[00:50] <rockstar> jml, well, tarmac is implemented using launchpadlib, so most of the code is already written.
[00:51] <rockstar> I'm just saying we give tarmac another task.  That's another goal of 0.3
[00:51] <rockstar> I want Tarmac to be able to deal with all sorts of things related to landing a branch, whatever it is.
[00:51] <rockstar> Many tools > one tool.
[00:52] <rockstar> That's my goal anyway: suite of landing tools.
[00:52] <rockstar> So you're free to implement something else, but I'm free to steal it.  :)
[00:53] <jml> sure :)
[01:40] <wgrant> What was APA? I've seen references to it, but nothing about what it does/did.
[01:40] <jml> wgrant, I can't even remember what it did :
[01:41] <jml> I think maybe it looked ahead in the pqm queue for failures
[01:41] <wgrant> Ah.
[02:10] <rockstar> wgrant, it used to grab all the branches in the PQM queue, make a super branch out of them, and test it in ec2
[02:10] <rockstar> 'Twas quite nice in Week3
[15:49] <Ursinha> OOPS-1347F129
[16:00] <matsubara> #startmeeting
[16:00] <MootBot> Meeting started at 10:00. The chair is matsubara.
[16:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:00] <matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
[16:00] <matsubara> [TOPIC] Roll Call
[16:00] <MootBot> New Topic:  Roll Call
[16:00] <bigjools> me
[16:00] <gary_poster> me
[16:00] <matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
[16:00] <intellectronica> me
[16:01] <rockstar> ni!
[16:01] <Ursinha> meee
[16:01] <matsubara> sinzui, Chex, danilos: hi
[16:01] <Chex> me
[16:01] <sinzui> me
[16:01] <sinzui> matsubara: sorry, I was reading the scrollback
[16:02] <mbarnett> late me
[16:02] <danilos> me
[16:02] <matsubara> stub and danilos can join in later. let's move
[16:02] <matsubara> [TOPIC] Agenda
[16:02] <MootBot> New Topic:  Agenda
[16:02] <matsubara>  * Actions from last meeting
[16:02] <matsubara>  * Oops report & Critical Bugs & Broken scripts
[16:02] <matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
[16:02] <matsubara>  * DBA report (stub)
[16:02] <matsubara>  * Proposed items
[16:02] <matsubara> [TOPIC] * Actions from last meeting
[16:02] <MootBot> New Topic:  * Actions from last meeting
[16:03] <matsubara>     * barry to continue debug on bug 403606 after finishing 3.0 UI stuff
[16:03] <matsubara>     * intellectronica to take a look or find someone to take a look on bug 408738 after finishing 3.0 UI stuff
[16:03] <matsubara>     * ursinha to keep an eye on timeouts for person +branches pages and report back if the CP solved the issue or further action is needed
[16:03] <matsubara>         * The timeouts are gone
[16:03] <matsubara>     * matsubara to file a bug for OOPS-1342EA107 (ValueError using the api) and chase someone to fix it
[16:03] <matsubara>         * Filed bug 423880 and assigned to leonardr
[16:03] <matsubara>     * ursinha to chase jtv about CP to fix rosetta-poimport script failure
[16:03] <matsubara>         * The fix is in devel, but no CP will be requested because according to jtv it's unlikely that the problem hits us hard before 3.0. The script stopped failing as well.
[16:03] <matsubara>     * chex to trawl logs and add request that caused 500 error to bug 422960
[16:03] <matsubara>     * matsubara to email stub about dba report
[16:03] <matsubara>         * emailed stub
[16:03] <matsubara> sinzui, I take barry is still busy with 3.0 ui stuff?
[16:04] <sinzui> matsubara: yes
[16:04] <matsubara> intellectronica, news about 408738?
[16:04] <rockstar> EVERYONE is busy with 3.0 UI stuff.
[16:04] <intellectronica> matsubara: so, we've sceduled the bug for 3.0, and if everything goes according to plan it will be addressed next week. until now we were still very busy with 3.0 UI upgrade
[16:04] <intellectronica> everyone and their sister, even
[16:04] <matsubara> all right. I'll keep both action items in. thanks
[16:04] <matsubara> [action]  barry to continue debug on bug 403606 after finishing 3.0 UI stuff
[16:04] <MootBot> ACTION received:   barry to continue debug on bug 403606 after finishing 3.0 UI stuff
[16:05] <matsubara> [action] intellectronica to take a look or find someone to take a look on bug 408738 after finishing 3.0 UI stuff
[16:05] <MootBot> ACTION received:  intellectronica to take a look or find someone to take a look on bug 408738 after finishing 3.0 UI stuff
[16:05] <intellectronica> matsubara: no objection for keeping the action, but mind you it is now scheduled for this milestone
[16:05] <matsubara> Chex, any news about 422960?
[16:08] <Ursinha> I wonder if I got disconnected again
[16:08] <matsubara> nope
[16:08] <Ursinha> *whew*
[16:08] <matsubara> well, let's move on then.
[16:08] <matsubara> [action]  chex to trawl logs and add request that caused 500 error to bug 422960
[16:08] <MootBot> ACTION received:   chex to trawl logs and add request that caused 500 error to bug 422960
[16:09] <matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
[16:09] <MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
[16:09] <Ursinha> me me
[16:09] <Ursinha> well
[16:09] <Ursinha> flacoste, stub, I have some oopses like OOPS-1345G2533, that reminded me of bug 174368 (that is fix released), but I couldn't reproduce it
[16:09] <Ursinha> stub fixed that
[16:09] <Ursinha> stub, could you take a look, please?
[16:09] <Chex> matsubara: I started to look at that last week and was sidetracked, I will still be looking at it
[16:10] <matsubara> Chex, thanks. I added the action item back. it'll serve as reminder next meeting :-)
[16:10] <Chex> matsubara: great thanks
[16:10] <Ursinha> sinzui, also I have OOPS-1348XMLP49, that seems to be related to the problem barry was working on yesterday, the launchpad-reviewers mailing list
[16:10] <Ursinha> sinzui, do you know if that's correct? if so, is there a bug? (or do you want me to open one?)
[16:10] <Ursinha> and
[16:10] <Ursinha> rockstar, bug 427383, can I haz triage in that, please?
[16:11] <sinzui> Ursinha: there is a bug
[16:11] <gary_poster> Ursinha: you should put me and stub down for that Foundations OOPS
[16:11] <rockstar> Ursinha, I will look.
[16:11] <Ursinha> thanks rockstar
[16:11] <sinzui> Urshina: We do not understand what is wrong and we do not have time to investigate it
[16:11] <rockstar> Launchpad is teh slow today.
[16:11] <Ursinha> gary_poster, I'll file a new bug for that and let you know
[16:11] <gary_poster> Ursinha: thanks
[16:11] <stub> Ursinha: Yes, it looks similar. Separate bug, same piece of crap code.
[16:12] <Ursinha> sinzui, I've added a highlight for 'Urshina' just for you here :)
[16:13] <Ursinha> sinzui, do you know the bug number? I'll keep my eye on that problem and let you know if it gets critical
[16:13] <stub> Ursinha: Not a high priority though, as it is unlikely to be triggered by anything other than a spam bot (like the OOPS you cited)
[16:13] <sinzui> Ursinha: bug 403606
[16:13] <Ursinha> sinzui, this bug is the same of that oops? hmm.
[16:14] <sinzui> Ursinha: sorry, I was confused..my scrolling is knackered
[16:14] <Ursinha> :)
[16:14] <matsubara> [action] ursinha to file a bug for OOPS-1345G2533 and coordinate a fix with gary/stub
[16:14] <MootBot> ACTION received:  ursinha to file a bug for OOPS-1345G2533 and coordinate a fix with gary/stub
[16:14] <sinzui> Ursinha: That is Barry and LOSAs doing DB surgery.
[16:14] <intellectronica> siniuz: that's no excuse
[16:15] <sinzui> Ursinha: That screwed of the data. They fixed it.
[16:15] <Ursinha> sinzui, all right.
[16:15] <Ursinha> thanks sinzui
[16:16] <Ursinha> the only Critical bug is already Fix Committed
[16:16] <Ursinha> thanks gary_poster :)
[16:16] <gary_poster> sorry :-P
[16:16] <Ursinha> matsubara, you can move on
[16:16] <Ursinha> thanks guys
[16:17] <matsubara> all right. thanks Ursinha and everyone
[16:17] <matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
[16:17] <MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
[16:17] <Chex> hello everyone here is what we have for the report:
[16:17] <Chex> - Buildbot issues in the process of being resolved (currently setting up a staging buildbot)
[16:17] <Chex> - Higher than normal load on the app servers yesterday which seemed to be caused by higher than normal edge traffic, but not
[16:18] <Chex> sure if that was slow processing of queries meaning more connections per second, or really more traffic
[16:18] <Chex> (would need to correlate with apache logs)
[16:18] <Chex> - Edge outage over the weekend caused by app server hanging during auto edge rollout (bug 307447)
[16:18] <Chex> - Codebrowse is still timing out a lot
[16:18] <Chex> - A few CPs were applied in the past week.
[16:18] <matsubara> Chex, re: high load on edge, I'll trawl some logs about it today. I'll let you know what I find out
[16:18] <Chex> and thats it from us. any questions?
[16:19] <Chex> matsubara: ok, great thank you on the edge load
[16:19] <gary_poster> 307447 is in progress, btw
[16:19] <matsubara> Chex, do you know if the LP outage reported by spm might be related with the high load?
[16:20] <Chex> matsubara: I am not sure, I would have to check on that
[16:20]  * gary_poster notices ubottu beat me to the punch
[16:20] <matsubara> Chex, ok, we can coordinate after the meeting.
[16:20] <matsubara> thanks Chex
[16:21] <matsubara> [TOPIC] * DBA report (stub)
[16:21] <MootBot> New Topic:  * DBA report (stub)
[16:21] <stub> Discussions afoot on migrating to PostgreSQL 8.4. PostgreSQL 8.4.1 has just been released, but will need packaging and backporting to Hardy. We also want Slony-I 1.2.27 to be released and packaged, as that is the version in the 1.2 series that supports PG 8.4 (I think - slony site is having issues right now so I can't fact check).
[16:21] <stub> Nothing else interesting happening.
[16:21] <stub> 1.2.17 is the Slony-I release we are waiting on
[16:22] <stub> (site is back up, or my net connection is)
[16:22] <matsubara> ok. questions for stub?
[16:23] <matsubara> guess not. moving on
[16:23] <matsubara> thanks stub
[16:23] <matsubara> [TOPIC] * Proposed items
[16:23] <MootBot> New Topic:  * Proposed items
[16:23] <matsubara> no proposed items
[16:23] <matsubara> anything else before I close?
[16:23] <rockstar> Purple monkey dishwasher.
[16:24] <matsubara> [action] matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
[16:24] <MootBot> ACTION received:  matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
[16:24] <intellectronica> rockstar: i don't understand, what does it wash, dishes or monkeys?
[16:24] <rockstar> intellectronica, it was a Simpsons reference, and I was just being silly.
[16:24] <bigjools> or purples
[16:25] <Ursinha> lol
[16:25] <Ursinha> gary_poster, stub, bug 427397
[16:25] <Ursinha> matsubara, you can mark that action as completed :P
[16:25] <gary_poster> thanks Ursinha.  stub, I'm marking it low and throwing it your way.
[16:26] <matsubara> thanks Ursinha
[16:26] <matsubara> ok, I think that's all
[16:26] <Ursinha> thanks gary_poster
[16:26] <matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
[16:26] <Ursinha> and matsubara
[16:26] <Ursinha> and stub
[16:26] <matsubara> #endmeeting
[16:26] <MootBot> Meeting finished at 10:26.
[16:26] <Ursinha> and everyone else
[16:26] <gary_poster> heh, thanks Ursinha and matsubara :-)
[16:26] <Ursinha> :)
[16:26] <intellectronica> thanks Urshina and matsubara
[16:27] <Ursinha> :P
[16:31] <Ursinha> awww I forgot mentioning something
[16:31] <Ursinha> *crap*
[16:32] <Ursinha> I'll mail the list