#launchpad-meeting 2008-04-08
<barry> #startmeeting
<MootBot> Meeting started at 05:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everybody and welcome to this week's asiapac reviewer's meeting.  who's here today?
<mwhudson> good grief
<mwhudson> i am here
<barry> jeebus, i'm going to bed
<mwhudson> jml, thumper, spiv
<barry> thumper told me he might not make it
<barry> so mwhudson how the hell are ya?
<mwhudson> i think the other two should be around
<mwhudson> barry: i am ok!
<barry> :)
<mwhudson> slogging away at code imports for the most part
<mwhudson> barry: how are you?
<barry> getting over being sick for a week :(
<mwhudson> :(
<barry> jamesh: hi!
<jamesh> hi
<barry> we can wait a minute or so to see if jml and spiv show up
<barry> sinzui, ol' eastern timezone buddy, ol' pal
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<barry> same time and place?
<jml> back
<jml> yes
<barry> jml: hi
<jml> sorry, dst confusion
<barry> no worries
<barry> okay.  same time and place next week
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * (continued) thumper to report on pending-reviews killer in LP
<barry> i guess we'll just continue this one on since thumper's not here
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
<jml> actually, this is likely to be a bad time for thumper.
<jml> I'll ask him about timing preferences after the meeting.
<jml> back to queue status.
<barry> jml: please do.  i'm happy to move it one hour earlier, but probably don't want to go much later
<jml> *nod*
<barry> queue looks fine to me. still have one of stub's long running test branches
<barry> not much in PR
<jamesh> I'll get to that.
<barry> jamesh: cool, thanks
<barry> jamesh: looks like it has a conflict
<barry> any feedback on the queue from you guys?
<jamesh> barry: it is in .bzrignore, so doesn't obscure the meat of the branch.
<barry> jml: i reviewed your branch.  i'm really sorry it took so long to get that reviewed
<barry> jamesh: cool
<jml> barry: np. thanks for the review, I'll aim to reply today.
<mwhudson_> pff!
<barry> jml: k
<barry> anything else?
<jml> nope.
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> probably not much to say there, eh?
<jml> nope
<barry> [TOPIC] review process
<MootBot> New Topic:  review process
<barry> anything on your minds about that?
<jml> umm.
<barry> jml: go ahead!
<jml> umm.
<jml> more automation is good
<jml> but we are already working on that as #1 priority
<barry> jml: reviews in lp?
<jamesh> it'd be cool if Launchpad kept track of this stuff
<jml> oh, I remember
<jml> barry, jamesh: yes
<jml> barry: stub was surprised when I asked him about whether he had sent a review letter to the reviews list asking for a review
<jml> barry: he had just added a thing to the wiki page in my queue
<sinzui> abel was working in lala land too
<jml> barry: so, we probably need clearer docs on the PendingReviews page
<barry> did he arrange that with you ahead of time?
<jml> barry: he might have. I can't recall.
<barry> jml: i don't think anybody should drop a branch in your pr queue without arranging so irst
<barry> er, first
<jml> barry: but I think I would have assumed, even we did arrange, that I was waiting for a cover letter.
<barry> jml: yes, always cover letter to list (via bzr review-submit)
<jml> barry: those details are lost in the mists of time
<jml> anyway, we need clearer docs about review-submit and cover letters etc on PendingReviews, I think.
<barry> [ACTION] barry to update PendingReviews with clearer docs on process
<MootBot> ACTION received:  barry to update PendingReviews with clearer docs on process
<jml> cool :)
<barry> :)
<jml> that's it.
<barry> cool.  that's it for me then.  is there anything else you guys want to bring up, or communicate to ameu?
<jml> mwhudson: having fun?
<mwhudson__> this is a little bit annoying
<mwhudson__> jml: no, not really
<jml> barry: keep the dream alive.
<jml> barry: that's all I have to say :)
<barry> mwhudson: i'm not leaving here until you have at least 5 underscores in your nick
<barry> jml: always! :)
<mwhudson__> barry: shouldn't take too long
<barry> okie dokie then.
<barry_____> #endmeeting
<barry> thanks everyone!
<jml> perhaps "__barry__"
<mwhudson__> did that #endmeeting take? :)
<barry> jml: working on that for py3k
<barry> #endmeeting
<MootBot> Meeting finished at 05:19.
<mwhudson__> :)
<barry> :)
<jml> barry: I guess that'll override the diamond operator?
<barry> jml: sshhhh!!!!!!!!  don't tell guido!
<mwhudson__> barry: __barry__ is the special method for grouching about there not being an "<>" operator any more?
<mwhudson__> jml: high five!
<barry> mwhudson: from future import __barry__
<jamesh> 1 __barry__ 2
<barry> from past import __barry__
<barry> jamesh: yes, exactly :)
<barry> ok.  i'm going to bed now.  g'nite
<mwhudson__> bye
<jamesh> maybe python 3k should have a "greater than or less than" operator to replace the deprecated "less than or greater than" operator
<sinzui> ha ha
<thumper> er, hi
#launchpad-meeting 2008-04-09
<barry> #startmeeting
<MootBot> Meeting started at 16:01. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everybody, and welcome to this week's ameu reviewer's meeting
<barry> who's here today?
<schwuk> me
<statik> me
<bac> me
<allenap> me
<bigjools> me
<gmb> me
<flacoste> me
<intellectronica> me
<BjornT> me
<barry> danilos salgado sinzui ping
<danilos> me
<salgado> me
<sinzu1> me
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
 * sinzu1 kills his main computer
<barry> same time and place?  anybody know they won't be able to make it?
<barry> 5..4..3..2..1
<barry> cool
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * (continued) barry to remind lp devs to do pre-impl calls
<barry> do i still need to do this?  ;)  i think so
<bigjools> what's a pre-imp call?
<bigjools> ;)
<barry>  * sinzui to email jamesh about some branches not being picked up by pending-reviews
<barry> bigjools: :)
<barry> sinzui: you did that right?
<sinzui> barry: right. jtv had some creative markup in his PR blocks
<barry> sinzui: cool, thanks
<barry>  * allenap to update Reviewers' guidelines with _pseudo_private policy
<allenap> Done, see https://launchpad.canonical.com/PythonStyleGuide under Private Name Mangling.
<barry> allenap: thanks
<barry> here's one that came up in asiapac:
<barry>  * barry to update PendingReviews with clearer instructions on using review-submit
<barry> i think there's still some confusion about how to ask for a review
<barry> so it was suggested that i add instructions on PendingReviews, pointing people to the lpreview plugin
<barry> i haven't done this yet though ;)
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
<barry> generally looks okay to me; any comments?
<barry> guess not ;)
<schwuk> mwhudson has had a branch sitting in my queue for a couple of weeks. Last activity I saw was sinzui asking him some questions.
<sinzui> that's rught
<schwuk> sinzui: did he answer them?
<schwuk> mwhudson__: ^^
<sinzui> It was an innocent enough set of questions. I didn't even ask for changes I think
<sinzui> I'll hunt down mwhudson__ tonight
<schwuk> sinzui: cheers
 * sinzui struggles to use this keyboard
<barry> one thing to mention: jml had a branch that he tried to get reviewed for a week, with no luck.  that's unfortunate.  i ended up reviewing it on my on-call day
<schwuk> why couldn't he get it reviewed?
<barry> schwuk: i don't really know.  he says he asked #lp-reviews and got no takers
<bigjools> did he put it in the queue?
<bac> tjat
<gmb> That seems odd. We've got pretty good on call coverage now, don't we? And the OCR usually picks up the queue.
 * schwuk suspects this is the same branch he tried to ping jml about at the start of his shift, but got no response
<bac> that's odd.  unless he showed up just as the reviewers were leaving
<barry> hmm
<barry> yeah
<intellectronica> gmb: maybe things are looking differently from that side of the world
<intellectronica> but either way, good old PR should work as a backup.
<gmb> intellectronica: True. Even so, *someone* should have been picking up the queue, or at least doing an assignment run.
<barry> i think this is a good example why we can't completely ignore or kill off PR yet
<gmb> So it looks like there was a big hairy communications failure somewhere along the line.
<bac> barry: when you do your write up, remind developer that merely sending a cover letter to the list isn't sufficient to trigger a review.  this happened yesterday.
<intellectronica> we've got a process in place - the OCR does allocation at the end of the shift. if there's a problem it's simply because we don't follow it
<barry> bac: good point
<gmb> What intellectronica said.
<intellectronica> bac: yeah, happened to me twice today too.
<bac> in their defense 'bzr review-submit' does seem like it should be enough
<gmb> barry: Maybe it's worth making a note that OCRs should be allocating all un-allocated branches at the end of their shift.
<barry> as much as it sucks to edit PR, i still think we should recommend that people do that, but perhaps only if they can't get an all-call review?
<intellectronica> either you get an agreement from a reviewer directly to take on the branch (and send the letter to him directly), or it goes to PR (and preferably both)
<barry> gmb: we've mentioned that before, but i guess i'll add that to my PR note
<gmb> barry: That's what I usually expect. If I have an email dialog with reviewer X then I don't usually put things in their queue unless they ask me to.
<barry> intellectronica: +1
<intellectronica> it sucks, but now that the review plugin generates the markup for you, it's really not that terrible
<gmb> Although interestingly it insists on putting all branches in 1.2.6,,,
<barry> gmb: right, i don't think you should /ever/ put something directly in a review's queue unless you've cleared it with them first
<barry> gmb: yeah, why is that? :)
<barry> gmb:  it also (for me) insists on sftp urls
<gmb> barry: Well the code that looks the milestone up is preceeded by the comment "hacky hacky"
 * barry has been meaning to mention that
<gmb> That might be a clue...
 * barry lols
<gmb> barry: I'll take a look at it this week (or we can file a bug for mwh's attention if you prefer)
<barry> gmb: where would the bug go?
 * bac wondered why everyone seemed to be using sftp now
<gmb> barry: There's an lprevew project in LP.
<gmb> I'll find it, hang on...
<barry> gmb: cool +1.
<gmb> barry: http://launchpad.net/bzr-lpreview
<barry> gmb: do you want to submit those bug reports?
<gmb> barry: Sure, will do.
<barry> gmb: thanks
<gmb> barry: Can we also make a note for the next AsiaPac meeting
<gmb> for mwh to look at my 800-line limit patch?
<barry> [ACTION] gmb to submit bug reports for bzr-lpreview about the 1.2.6 milestone and sftp urls
<MootBot> ACTION received:  gmb to submit bug reports for bzr-lpreview about the 1.2.6 milestone and sftp urls
<barry> gmb: will do
<gmb> It's probably slipped under his radar, much like it did mine.
<gmb> Thanks.
<barry> [ACTION] barry will prod mwh to look at gmb's 800-line limit patch
<MootBot> ACTION received:  barry will prod mwh to look at gmb's 800-line limit patch
<barry> that's all i have about the queue.  anything else from y'all?
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> any comments?
<bac> mentoring + on-call is going well
<barry> for me as well
 * bigjools is enjoying it
 * barry waves to bigjools 
 * bigjools hi-fives barry
 * allenap is enjoying it too
 * schwuk enjoyed his first 'shift'
<schwuk> I'm not sure if intellectronica did though :)
<barry> schwuk: glad you've had your first shift!
<intellectronica> why, it was a great review
<intellectronica> and i totally dug introducing twitter to our arsenal of communication tools ;)
<schwuk> intellectronica: if you were happy, then I'm happy :)
<barry> intellectronica: how did you guys use twitter?
<schwuk> intellectronica: then I'll have to show you my idea for a twitter plugin for bzr :)
<intellectronica> it was the end of the week, schwuk had to go and welcome guests, and he suggested that i twit him once i reply to his review
<bigjools> a diff in 160 chars will be challenging :)
<schwuk> barry: what he said
<intellectronica> :)
<barry> :)
<sinzui> ha
<barry> cool
<barry> [TOPIC] review process
<MootBot> New Topic:  review process
<schwuk> bigjools: 140, and there's always pastebin :)
<barry> i don't have much to add here, any comments?
<sinzui> Last week and this week we have received reviews that were not submitted with review-submit
<sinzui> I think we need a reminder sent to everyone (though everyone may have gotten the message now)
<bigjools> can we get the review plugin packaged and added to lp-debs?
<barry> sinzui: that's part of the note i'm adding to PendingReviews
<gmb> bigjools: I think you'll need to talk to mwh about that. Where would we put it?
<salgado> bigjools, it could also be added to sourcecode/
<salgado> that's way easier
<gmb> salgado: +1
<bigjools> any or all, I don't care :)
<barry> salgado: can that be made to easily plug into bzr from there?
<gmb> We've got to keep it private unless sabdfl authorises it, so...
<bigjools> I've given up constantly doing bzr pull to see if it's been updated
<gmb> barry: We could make it part of rf-setup
<gmb> And create a symlink
<statik> barry: can symlink from ~/.bazaar/plugins to lp-sourcedeps
<barry> good point.  probably as part of utilities/link-external-sourcecode.sh
<barry> anybody want to take that on?  i'll be happy to review such a branch
<BjornT> why would it be in link-external-sourcecode.sh?
<barry> BjornT: that's what creates symlinks into sourcecode
<gmb> barry: I think it should probably be part of rf-setup.
<gmb> Which is run only once (preferably, anyway)
<barry> gmb: yeah, i guess so
<barry> good point
<BjornT> barry: well. it creates symlinks from a branch to another source code location. i'd say that's a bit different from linking from your home dir
<schwuk> gmb: +1
<barry> anyone want to take this action?
<gmb> barry: I'll do it.
<bigjools> rf-setup gets my vote, although I am wary of running it multiple times even though it seems to check if work needs to be done
<barry> gmb: you rock, thanks
<gmb> Shouldn't take long.
<barry> [ACTION] gmb to add lpreview to sourcecode and hack rf-setup to link it in
<MootBot> ACTION received:  gmb to add lpreview to sourcecode and hack rf-setup to link it in
<barry> that's it from me.  we have 8 minutes left if anybody has anything else to discuss
<barry> i guess we're done then
<barry> #endmeeting
<MootBot> Meeting finished at 16:39.
<bigjools> grassy ass barry
<statik> thanks barry
<gmb> Cool, thanks barry.
<barry> thanks everyone!
<intellectronica> thanks barry
<schwuk> thanks barry
 * gmb goes to celebrate with his other half for a few minutes
#launchpad-meeting 2008-04-10
 * Rinchen looks around and sees MootBot and breathes a sign of relief.
<mpt> [WC] <- sign of relief
<intellectronica> thanks for letting us know!
<Rinchen> heh
<mpt> ah, intellectronica, you missed the context by ten minutes :-)
 * thumper has coffee
<intellectronica> i'm not sure whether i should be happy or sad about that
<intellectronica> i'll default to happy
<salgado> me
<schwuk> you
<sinzui> him
<bac> us
<thumper> I
<thumper> aye
 * allenap is feeding his daughter; 7pm is not such a good time for the meeting :)
<carlos> me
<bigjools> allenap: seconded
<al-maisan> me
<thumper> 6am ain't so hot either
<gmb> me
<leonardr> me
<thumper> Rinchen: c'mon
<Rinchen> vroom
<allenap> thumper: granted
<bigjools> thumper: I thought you always got up at 6am? :)
 * schwuk waits for rollcall
<Rinchen> geez, anxious bunch
<flacoste> me
<Rinchen> #startmeeting
<MootBot> Meeting started at 20:02. The chair is Rinchen.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<thumper> bigjools: almost, but not always coherent
<Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<Rinchen> [TOPIC] Roll Call
<abentley> me
<MootBot> New Topic:  Roll Call
<mrevell> me
<gmb> me
<Rinchen> me
<jt1> me
<flacoste> me
<salgado> me
<allenap> me
<bigjools> me
<mars> me
<barry> me
<schwuk> me
<mpt> me
<herb> me
<leonardr> me
<intellectronica> me
<matsubara> me
<Rinchen> (and my beeps aren't working today again)
<bac> me
<adeuring> me
<BjornT> me
<sinzui> me
<cprov> me
<gmb> thumper: Is that a definition of bigjools? Cos that's how it reads ;)
<thumper> me
<jtv> me
<SteveA> me
<kiko-afk> me
<statik> me
<EdwinGrubbs> me
<Rinchen> hmm.... ok, let's keep going!
<Rinchen> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (Matsubara)
<Rinchen>  * Critical Bugs (Rinchen)
<Rinchen>  * Bug tags
<Rinchen>  * Operations report (mthaddon/herb)
<Rinchen>  * DBA report (stub)
<Rinchen>  * Sysadmin requests (Rinchen)
<Rinchen>  * New packages required (salgado)
<Rinchen>  * A top user-affecting issue (mrevell)
<Rinchen>  * Doc Team report (mrevell)
<Rinchen>  * Blockers
<Rinchen> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<Rinchen> same time, same channel?
<SteveA> I'd prefer a tad earlier
<SteveA> bit it's no biggie
<thumper> :(
<kiko-afk> SteveA, what about thumper?
<kiko> well, last week we said we'd experiment rotating team leads
<kiko> the team leads call, sorry
<kiko> turns out we didn't agree to do that for this round
<Rinchen> our next call is on Wednesday of next week so we can bring the topic up again
<SteveA> so, as the meeting is late for europeans, I ask that we keep it firmly on time
<kiko> I really want a time that works for tim and jtv
<SteveA> and end exactly 45 minutes after starting
<kiko> we make a serious effort to end 45 minutes after
<SteveA> well
<SteveA> we just end then ;-)
<SteveA> and take the consequences
<Rinchen> [AGREED] Same time next week
<MootBot> AGREED received:  Same time next week
<Rinchen> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<Rinchen> none
<Rinchen> [TOPIC] Oops report (Matsubara)
<MootBot> New Topic:  Oops report (Matsubara)
<Rinchen> (vrooom)
<matsubara> Today's oops report is about bugs 214843, 198368
 * Rinchen chuckles.
<ubotu> Launchpad bug 214843 in launchpad "Cycles in team data kill mailing lists" [Critical,Confirmed] https://launchpad.net/bugs/214843
<ubotu> Bug 198368 on http://launchpad.net/bugs/198368 is private
<matsubara> #214843 is already assigned do barry.
<matsubara> to barry
<matsubara> barry: any news about #198368?
<barry> i think the data problem is already fixed, as is the resync issue.  we now have bug 215118 in review
<ubotu> Launchpad bug 215118 in launchpad "Odd mailing list resync behavior" [High,Confirmed] https://launchpad.net/bugs/215118
<barry> once that lands we should be good to go
<barry> that's it
<matsubara> thanks barry
<matsubara> back to you Rinchen.
<Rinchen> thanks!
<Rinchen> [TOPIC] Critical Bugs (Rinchen)
<MootBot> New Topic:  Critical Bugs (Rinchen)
<Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/206654
<Rinchen> This is the memory issue. flacoste, SteveA.  Any updated status?
<MootBot> LINK received:  https://bugs.edge.launchpad.net/launchpad/+bug/206654
<Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/207558
<Rinchen>  thumper, what's the next step with this?
<MootBot> LINK received:  https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/207558
<kiko> I'm really unhappy about that one
<flacoste> Rinchen: mthaddonis copying the references leak log
<ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,Fix released]
<thumper> I think that was just with bzr.dev
<SteveA> kiko: what one?
<thumper> and is fixed
<flacoste> Rinchen: i'll investigate after that, but we are not seeing any big leak on the monitoring server, probably due to the fact that it receives a lot less requests
<Rinchen> interesting flacoste
<kiko> the server issue, SteveA
<Rinchen> thumper, can you please update the bug then since there is a code hosting task assigned?
<thumper> ah
<kiko> we need a new strategy for dealing with it
<SteveA> kiko: it's a tricky one, for sure
<thumper> I recall now
<flacoste> Rinchen: i'm hoping to correlate a small leak in the monitoring log to the big one based on the difference in number of requests
<thumper> lifeless filed an RT to get apache config updated
<SteveA> kiko: what are you talking about?
<kiko> SteveA, well..
<SteveA> kiko: we have a strategy for dealing with it, which is in progress
<kiko> SteveA, is that strategy going to work? it seems we've made the change and the change we've made has hidden the problem from that environment.
<SteveA> kiko: I'd appreciate a bit more support and positivity considering the work people are putting into diagnosing this
<kiko> meanwhile, clock ticking, etc
<thumper> Rinchen: confirmed with config that the RT has been executed
<SteveA> we don't know that the change has hidden anything
 * thumper updates task
<Rinchen> thumper, thank you sir.
<flacoste> kiko: well, since the problem now disapperaed from edge, maybe it will go away by itself in the next roll-out ;-)
<SteveA> we are collecting data, and we need to analyze it and tweak how we're collecting it based on the analysis
<kiko> SteveA, that's all just words to me. I haven't seen us progress to a solution after more than a week, and that's what's concerning me
<SteveA> kiko: I have no idea what you're talking about
<kiko> flacoste, completely? no edge instances are balooning?
 * kiko chuckles
<kiko> heisenbug indeed
<flacoste> kiko: i wouldn't count on it though, because until last week, that was isolated to edge
<flacoste> kiko: and it's not like a cherry-pick could explain it
<Rinchen> flacoste, perhaps it time for a quick update on status to be posted to the bug. That way kiko will see the work you and others are doing.  Would you be ok with that?
<kiko> flacoste, f*cking crazy.
<flacoste> Rinchen: sure
<kiko> I know what work's been done, though.
<kiko> that's not really the issue :)
<kiko> but go ahead, it'll be interesting
<flacoste> what kiko wants is results!
<SteveA> what kiko wants is a vacation somewhere sunny
<kiko> or really good excuses :)
<Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/214843
<Rinchen> barry, how is the refactoring going?
<MootBot> LINK received:  https://bugs.edge.launchpad.net/launchpad/+bug/214843
<ubotu> Launchpad bug 214843 in launchpad "Cycles in team data kill mailing lists" [Critical,Confirmed]
<kiko> it's always sunny where /I/ live
<flacoste> SteveA: he just needs a vacation then I guess, i heard it was very sunny where he lives
<matsubara> Rinchen: barry just gave a update about that one in the oops section :-)
<SteveA> flacoste: the memory problems have only happened when kiko's not been on vacation.  so obviously that is the solution.
<kiko> can I not be the subject of the conversation, and instead the problem we're trying to solve?
<barry> Rinchen: the refactoring has not been done and probably isn't critical
<barry> Rinchen: it can be done this cycle as normal
<kiko> flacoste, can you go on describing where we are?
<Rinchen> barry, great...that means we can demote the bug to HIGH.  Would you mind doing the honours?
<flacoste> kiko: i'll analyse the current data we collect and see if there is anything interesting
<barry> Rinchen: done
<Rinchen> barry, thank you sir
<kiko> flacoste, okay. is there a way we could monitor across multiple threads?
<flacoste> kiko: no
<kiko> bummer
<SteveA> well
<SteveA> there are ways.  it's a lot more complicated.
<kiko> yeah, I had that feeling
<flacoste> kiko: we could bump up the number of requests it receives
<kiko> that's a great idea! can we do that mthaddon?
<SteveA> so we should only go there once we've established we can't get decent data the way we're doing it
<kiko> right
<SteveA> first, let's have flacoste analyze the data we have
<mthaddon> kiko, what's that, bump up the number of requests?
<SteveA> then we'll look at increasing the number of requests it gets
<sinzui> I blame SchoÃ«dinger's cat
<mthaddon> kiko, we tried that (from 1/16 -> 1/10) and had to revert since it was timing out
<kiko> mthaddon, make it more preferred in the server rotation I guess
<kiko> mthaddon, hah
<kiko> mthaddon, is there a smaller increment?
 * kiko high 5s jtv 
<jtv> huh?
<mthaddon> kiko, any increment you like - 1/15 for instance... :)
<kiko> mthaddon, yeah, we could do a smaller step to see. okay, let flacoste make that call once he's looked at the data.
<mthaddon> kiko, sounds good
<SteveA> from looking at the data, we may see that we want to look more closely at *particular* kinds of request
<SteveA> so, I'm not so interested in adding shavings to the number of requests it processes
<SteveA> but rather directing requests that matter to it
<SteveA> we'll know soon
<Rinchen> ok, thanks for the lively discussion....
<Rinchen> I'm going to move on
<Rinchen> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<Rinchen> none to be considered
<Rinchen> [TOPIC] Operations report (mthaddon/herb)
<MootBot> New Topic:  Operations report (mthaddon/herb)
<herb> 2008-04-07 - Cherry pick 6013 to lpnet*
<herb> 2008-04-09 - Cherry picks 6006, 6026, 6031 to forster, lpnet*, xmlrpc-internal, mailman
<herb> Memory utilization issues continue, which has forced us to restart multiple lpnet instances daily.
<herb> ... But we have a debug release in place on edge3 and lpnet6. As discussed above, it doesn't seem we're getting any real feedback because the debug instances are throttled due to running them with 1 thread. They don't seem to be getting enough traffic to create the memory leak.
<herb> That's it from Tom and I unless there are any questions.
<Rinchen> This is a good time to talk about cprov's item
<cprov> yup
<Rinchen> update-cache
<mthaddon> what's to talk about?
<mthaddon> sounds like looptuner (sp?) is the way to go, right?
<cprov> mthaddon: exactly, we have to find a way to reduce the commit-rate
<jtv> mthaddon: spelled right
<Rinchen> cprov, so it sounds like the email threads have been updated and we can skip this topic.
<Rinchen> ..yes?
<mthaddon> ype
<mthaddon> yep, even
<kiko> I just replied to cprov and we should indeed use looptuner
<cprov> Rinchen: yes, all sorted
<kiko> it's easy to do
<kiko> gmb, can you help him out?
<Rinchen> great thanks gents
<gmb> kiko: Will do.
<Rinchen> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<kiko> i know you made that change for update-bugtargetnames
<kiko> thanks so much
<Rinchen> no stub
<SteveA> on vacation
<SteveA> or leave
<SteveA> or whatever
<Rinchen> ok, we'll skip the report this week.
<SteveA> anyway, not at work today
<Rinchen> [TOPIC] Sysadmin requests (Rinchen)
<MootBot> New Topic:  Sysadmin requests (Rinchen)
<Rinchen> Hi! Is anyone blocked on an RT or have any that are becoming urgent?
<Rinchen> that I don't already know about
<Rinchen> IS is still congested due to Hardy
<Rinchen> ok, if you do have something, ping me later or email me please. Thanks
<Rinchen> [TOPIC] New packages required (salgado)
<MootBot> New Topic:  New packages required (salgado)
 * bigjools waves at Rinchen
<salgado> if any of the branches you're working on right now depends on any library which is not part of the launchpad-dependencies package, come talk to me ASAP.
 * kiko looks around
<kiko> salgado, do you know if we still require lxml?
 * Rinchen acks bigjools and the ppa issue
<salgado> fyi, I recently made the package depend or pgsql 8.2 or 8.3, so you don't need to keep both versions around anymore
<salgado> kiko, I don't
<kiko> I'm asking because I know that abel isn't using it to validate hwtest schema anylonger
<kiko> (is that right flacoste?)
<adeuring> salgado, kiko: I think I was the only one who used it
<jtv> kiko: we still require xmlproc.
<Rinchen> right and there's a bug open for this cycle to remove that dependency
<flacoste> kiko: i want to use it for other stuff
<Rinchen> it's the only other hardy item on my list
<flacoste> kiko: like pagetests helpers and other general XML usage
<bigjools> what;'s going on with python-xml in hardy now?
<Rinchen> he newest python-xml package in hardy (uploaded April 1st) has made it impossible to run/test Launchpad because it moved its installed files to a place where we can't easily import from.
<kiko> flacoste, yep, that's what I was trying to remember
<Rinchen> translations has a dependency on xmlproc which, when removed, should allow LP to run/test fine on dev machines
<Rinchen> anything further for salgado?
<kiko> will it be removed, though?
<Rinchen> translations has a bug open to remove the dep
<Rinchen> the package itself will remain in hardy
<jtv> kiko: we definitely plan to
<Rinchen> ok, onward! (to make up for the last few meetings which overran)
<kiko> jtv, milestone eta?
<Rinchen> [TOPIC] A top user-affecting issue (mrevell)
<MootBot> New Topic:  A top user-affecting issue (mrevell)
<Rinchen> kiko, this cycle
<mrevell> Hi. I don't have one outstanding user-affecting issue this week. However, there are a couple of issues I've seen that I think are of interest.
<mrevell> 1. We've had a request from beeseek to import mbox files from their existing mailing lists into their Launchpad-hosted mailing lists. Barry, is this something we can/will do?
<kiko> cool cool
<barry> mrevell: yes.  matsubara is this the same request we're working on?
<Rinchen> kiko, https://bugs.edge.launchpad.net/rosetta/+bug/213406
<matsubara> barry: yes
<barry> mrevell: ^^
<mrevell> barry: Ah, thanks. Would you be happy to do this generally? If so, I'll update ListHelp.
 * beuno has been holding back from using LP mailing lists due to not being able to migrate archive/subscribers from lists.ubuntu
<matsubara> mrevell: I talked to barry about that already. we're going to do that after the meeting with mthaddon help :-)
<mrevell> matsubara: Ah, okay :) Thanks!
<mrevell> 2. Bug 213430 requests that "request feedback" in Blueprint should trigger an email notification.
<ubotu> Launchpad bug 213430 in blueprint ""Request feedback" should send an e-mail to the person who is asked" [Undecided,New] https://launchpad.net/bugs/213430
<barry> beuno: migrating subscribers isn't planned, but we can do mboxes
<mrevell> Just thought I'd highlight that request.
<beuno> barry, can you plan it?  :)
<mrevell> Rinchen: Do you want to talk about bug 213406?
<barry> beuno: let's chat after this meeting
<mthaddon> I'd also like to mention https://answers.launchpad.net/launchpad/+question/29265 as well - registering PLD Linux as a distro
<ubotu> Bug 213406 on http://launchpad.net/bugs/213406 is private
<kiko> yep
<beuno> barry, sure, thanks  :)
<kiko> I'll do that today, mthaddon
<Rinchen> mrevell, no, that's ok. Thanks :-)
<mthaddon> kiko, cool, thx
<intellectronica> mrevell: i'm aware of this, but i doubt that we'll have time to look at it for some time
<mrevell> Rinchen: Thanks for pointing me at it.
<mrevell> intellectronica: Thanks. It'd be cool when it arrives.
<intellectronica> mrevell: just like many other blueprint feature requests
<Rinchen> I'm hoping to have more time applied to Blueprint love after our currently schedule work completes.  *fingers crossed*
<mrevell> That's it from me, thanks Rinchen.
<Rinchen> Thank mrevell
<Rinchen> [TOPIC] Doc Team report (mrevell)
<MootBot> New Topic:  Doc Team report (mrevell)
<mrevell> Ah, me again
<mrevell> This week mpt and I met with the designers who are working on our new Launchpad tour. We spent most of the day with them, explaining the concepts behind LP and the ten primary features we want to communicate in the tour.
<kiko> mrevell, what do you think of them?
<mrevell> kiko: I was impressed with how quickly they "got" the concepts behind LP.
<kiko> that's cool
<mrevell> kiko: They had good input into how we could represent them visually, too.
<mrevell> I'll post a report on the meeting to the list.
<mrevell> Please, if you're a team lead, could I have a fifteen minute call with you tomorrow or early next week to go over the parts of the tour relevant to your part of LP?
<mrevell> Ping me with some good times :)
<Rinchen> mrevell, and grab someone from soyuz too please :-)
<mrevell> I'll be posting a new draft of the tour content to the team list either tomorrow or Monday. The tour designers are going to give us some mock-ups next week, which I'll post to the list.
<mrevell> Rinchen: Will do :)
 * Rinchen loves mock-ups.
<mrevell> Thanks, back to you Rinchen.
<Rinchen> Thanks mrevell
<Rinchen> wow, we're really zooming today
<Rinchen> [TOPIC] Blockers
<MootBot> New Topic:  Blockers
<thumper> Code: not blocked
<flacoste> Foundations: not blocked
<flacoste> actually
<mpt> I'm not blocked, but bug 214690 will make me much slower fixing anything that involves CSS
<ubotu> Bug 214690 on http://launchpad.net/bugs/214690 is private
<kiko> what's that bug about?
<jtv> Translations: not blocked
<BjornT> Bugs: not blocked
<bigjools> Soyuz: just the usual
<mpt> kiko, launchpad.dev using style-slimmer.css instead of style.css
<mpt> kiko, so I think it's about launchpad.dev's config
<Rinchen> Releases Team: Not blocked.
<flacoste> i see nothing in the config related to that
<flacoste> i thought that was an apache-side issue
<SteveA> I think I kniw how that works
<kiko> mpt, I think nobody else is aware of that problem
<statik> lpcomm: no blocked
<SteveA> I'll look into it shotyly
<Rinchen> thanks SteveA
<mpt> kiko, I discovered it only yesterday
<mpt> thanks SteveA
<sinzui> Does slimmer rely on devmode == False
<flacoste> i thnk sinzui got an hypothesis here
<schwuk> hwdb: not blocked
<sinzui> I have not messed with that until today, and it absolutely still works in the branch that removes launchpad ZConfig.
<BjornT> mpt: can't you run scripts/make-static.css as a workaround? if it works, it's at least better than restaring the web app
<BjornT> s/css/py
<mpt> I don't know -- I'll try it
<Rinchen> Ok, I'm going to wrap up now
<mpt> thanks for the hint
<Rinchen> feel free to chat about this on -code :-)
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
<jtv> Thank you!
<Rinchen> #endmeeting
<MootBot> Meeting finished at 20:42.
<thumper> \o/
<mrevell> thanks Rinchen
<Rinchen> yo
<jtv> Early even.
<Rinchen> vrooooom
<mrevell> thanks everybody
<Rinchen> ;-)
<statik> thanks rinchen
<cprov> great !
<intellectronica> cheers Rinchen
<gmb> Cheers Rinchen.
<abentley> Thanks Rinchen
 * gmb -> evening things
<cprov> thanks everybody
<Rinchen> thumper <-> rockstar_,  rockstar_ <-> thumper
<al-maisan> thanks!
<thumper> Rinchen: we know
<Rinchen> :-)
<rockstar_> Rinchen, yea, we've met!  :)
<kiko> moonies
<Rinchen> where's my bandana ?
<thumper> Rinchen: bandana?
 * gmb misread that as the Pascal version of thumper != rockstar
<thumper> gmb: and that'd be right
<bigjools> Rinchen's symbols look like an Imperial Tie Fighter
<thumper> <o>
<thumper> |-o-|
<bigjools> !
<bigjools> +1
<bigjools> perfect :)
<rockstar_> thumper, the first is an interceptor
<Rinchen> well, I was using the vader model
<bigjools> lol
<rockstar_> Only Vader flew one of those until RotJ
<Rinchen> tie interceptor maybe
<rockstar_> Yup
 * Rinchen has trouble remembering imperial ship names
<rockstar_> |-oo-|  <-- TIE Bomber
<bigjools> I'm not nearly geeky enough to remember
 * rockstar_ played too much Rogue Squadron
<thumper> me neither
 * thumper hasn't played a game in ages
<rockstar_> Those movies are all older than me.
<bigjools> not me :(
<rockstar_> thumper, your kids don't game?
<thumper> rockstar_: oldest is 7
<bigjools> Wii bowling is my limit these days
<thumper> so they play Clifford games, and my little pony
<thumper> not something that I get involved with
<rockstar_> thumper, I was 4 when I started playing.  Got into computers/electronics because my dad would unhook the stuff from the TV, so I taught myself to hook it back up.
<bigjools> come now thumper don't be shy
<thumper> I'd be happy to get a games console later
<thumper> I remember with fondness the an old playstation game that I can't remember the title to
<thumper> a problem solving one where you were some skeleton
<bigjools> Realistic Breast Physics III ?
<rockstar_> thumper, our LUG here gets together for Warhawk pretty often (everyday lately...)
<thumper> lol
 * thumper has never heard of warhawk
<rockstar_> New PS3 game.
 * thumper wonders if we should really have a #launchpad-offtopic channel
<rockstar_> :)
<matsubara> COD4 ftw
#launchpad-meeting 2009-04-08
<barry> #startmeeting
<MootBot> Meeting started at 09:04. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everyone and welcome to this week's ameu reviewers meeting.  who's here today?
<rockstar> me
<flacoste> me
<EdwinGrubbs> me
<intellectronica> me
<danilos> me
<al-maisan> me
<salgado> me
<barry> adeuring: ping
<barry> allenap: ping
<adeuring> me
<barry> bac: ping
<barry> BjornT: ping
<bac> me
<barry> cprov: ping
<allenap> me
<barry> mars: ping
<barry> sinzui: ping
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  * Action items
<barry>  * Mentoring update
<barry>  * Code must be used once or more to land (excluding tests) (intellectronica)
<barry>  * Avoid refactoring both code and tests in the same branch (intellectronica)
<cprov> me
<barry> let's skip around a bit
<sinzui> me
<barry> [TOPIC]  * Code must be used once or more to land (excluding tests) (intellectronica)
<MootBot> New Topic:   * Code must be used once or more to land (excluding tests) (intellectronica)
<barry> intellectronica: the floor is yours
<intellectronica> this follows from a discussion we had a couple of weeks ago in the ajax swat team
<intellectronica> working on general purpose solutions before they are being used is risky and hard
<BjornT> me
<intellectronica> and we want to avoid that as much as possible, especially when working on JS code
<danilos> intellectronica: what if we are not talking about general purpose solutions but parts of solutions?
<intellectronica> danilos: same thing
<danilos> (I know what you are aiming at, but the problem is more generic: just like there's a rule to not do premature optimization, we should not over-design stuff up-front, but let the design evolve from actual use cases)
<intellectronica> anyway, this is pretty much policy now, and shouldn't be debated here. the only relevant point for reviews is:
<danilos> well, I strongly disagree
<salgado> so do I
<BjornT> intellectronica: i think i agree with danilos
<BjornT> it's ok to land something that isn't used, if you intend to use it in the next branch
<BjornT> it helps keeping the branches small
<danilos> BjornT: +1
<adeuring> me too; the rule is in many cases useful, but i think there are many exceptions
<intellectronica> BjornT: it's ok if it's not in the same branch, but the reviewer should inquire about that, and maybe ask to see the branch where it's being used
<BjornT> landing something that you think will be useful, but don't have any plans to use should of course be discouraged
<barry> BjornT: i agree, i just wouldn't call that "not used" :)  i.e. it's just an artificial decomposition to keep branches manageable
<al-maisan> database patches are a classic example -- you land them first and use them later
<danilos> how would this work with landing DB patches a cycle before? that's a clear violation of the rule, or it means waiting two cycles "for nothing"?
<intellectronica> lazr code, for example, will, by-definition, not be in the same branch as the launchpad code that uses it
<cprov> al-maisan: db-patches are always *used* since the current code has to cope with it.
<intellectronica> danilos: this is particulary relevant for javascript code. deviations are ok at your discretion. and of course stuff like db patches must me done that way, and is pretty low risk
<barry> i also think it's fine to question code that you don't see used in a branch, and it's fine if the dev says "oh, that's in the next branch"
<al-maisan> I guess we need to agree on what constitutes "use" then
<danilos> intellectronica: which means it's not a rule, but a recommendation, specifically aimed at JS work, and should be described as such (IMO, at least)
<BjornT> barry: right. it's ok to question it, as long as it's allowed to land such branches
<danilos> barry: we've done that for ages, but I am willing to hear out intellectronica concrete recommendations for JS
<danilos> :)
<barry> BjornT: +1
<barry> danilos: i'm all for avoiding premature generalizations :)
<danilos> :)
<intellectronica> let's use our common sense. what we're trying to discourage is the development of general-purpose solutions separately from using them, where the risk is high
<barry> intellectronica: i get that, esp. for js stuff.  you think you see a general pattern when doing some ui stuff before it's proven itself
<intellectronica> b.t.w if you haven't already, please read the relevant post to the mailing list. i only wanted to mention this here because reviews are the last point in the development cycle where we can stop this
<intellectronica> what we really want to do is think about this pre-implementation
<danilos> intellectronica: it feels to me reviews are a bit too late to think about this
<intellectronica> danilos: i agree
<intellectronica> but if this wasn't done before, reviews are our last chance, before unused, and possibly unusable, code, lands
<danilos> intellectronica: you are only going to get negative opinions of the review process if you get blocked at that final step; I think that's something we should encourage in pre-imp calls
<intellectronica> danilos: you can gain something from identifying this in a review. the acknowledgedment that the work is incomplete
<intellectronica> the direct result will be that the work can be completed immediately, instead of shelved for a while, which is almost always worse
<danilos> intellectronica: that's ok as long as it's not a de facto blocker for landing stuff... I see the point, but it should clearly be at reviewers' discretion
<barry> i actually don't think this is a big departure from current practice, unless intellectronica is saying we MUST reject such branches
<danilos> barry: I was under the impression he was, which is why you hear me complaining :)
<intellectronica> barry: we only MUST reject lazr-js branches like this. everything else is open for negotiation
<barry> intellectronica: isn't this why we have the ui= tag now?  <wink>
<EdwinGrubbs> I think the JS general purpose solutions are little different, since we usually know that we are going to re-use them, but this increases the size of the project to several weeks. I don't think that whether we know we will use the general purpose solution is a good question to help decide where to split up the increments.
<danilos> I think we are departing from agile development as much as we can, and I don't like that
<intellectronica> barry: no. beuno is unlikely to pay attention to this in his review. he reviews the UI itself, not the code or how it's structured
<flacoste> danilos: hmm, not really, continuous integration is agile
<intellectronica> danilos: how so? that sounds very agile to me
<danilos> for lazr-js, we should definitely have nicer way to add JS directly into LP tree, and then we wouldn't even be having this discussion
<flacoste> danilos: and basically what intellectronica is arguing against is landing unintegrated code
<flacoste> danilos: no, it's not about that
<intellectronica> flacoste: exactly!
<flacoste> danilos: it's about not developping widgets that don't have an integration scenario
<danilos> flacoste: well, the code is used in the sample page in lazr-js
<danilos> flacoste: as I said, I see the point, I think the approach to solving it is completely wrong
<flacoste> danilos: yes, but that's what intellectronica is arguing against, the example page should be developped later, not as the first integration case
<intellectronica> danilos: there's no problem adding js code to the LP tree, and in fact my recommendation is that you develop like that and only move the code to lazr-js when it's ready. but that's up to the developer, on a case by case basis
<danilos> flacoste: in practice, you'll have people develop lazr-js widgets, then having that sit (with small changes) while they fight over integrating it
<barry> intellectronica: that seems like a reasonable approach to me
<intellectronica> danilos: right, and that's exactly what we're trying to avoid
<danilos> intellectronica: the problem is that it's not clear what the best practice is
<intellectronica> danilos: please refer to the email thread, if you haven't read it yet
<intellectronica> the best practice is "integration first"
<danilos> intellectronica: well, then reviewers meeting is completely wrong place to discuss it, and other than engaging in pre-imp calls, I don't want to block branches at review stage
<danilos> intellectronica: as I said, I agree with that, but don't see how it's relevant to blocking at review level
<barry> i think you're right that it's better to discuss this policy further on the ml thread
<intellectronica> i agree that this is not relevant _just_ to reviews, i only wanted to mention this because this is our last opportunity to deal with this. ideally, we should plan to work like that from the beginning, and you won't see this in reviews very often
<danilos> i.e. "you *should* have done this completely differently" -- if we get to that point, we are doing something badly
<flacoste> well, the policy is kind of in place
<intellectronica> barry: i agree
<flacoste> reviewers should just be mindful of it
<flacoste> and remember
<flacoste> reviewers are good candidates for pre-impl call
<flacoste> so i think that this topic was more about
<flacoste> "make sure you are up-to-date with the mailing-list thread" :-)
<barry> flacoste: +1
<intellectronica> flacoste: +1
<intellectronica> with that, i think we can move on
<barry> thanks.  let's move on
<barry> [TOPIC]  * Avoid refactoring both code and tests in the same branch (intellectronica)
<MootBot> New Topic:   * Avoid refactoring both code and tests in the same branch (intellectronica)
<intellectronica> ah yes, another issue that's not really about reviews :)
<danilos> well, I feel this one is, because it's much harder to review stuff that combines refactoring of both
<danilos> :)
<intellectronica> danilos: yes. it came up in a review :)
<barry> as long as the refactoring isn't necessary to actually keep the test suite happy
<danilos> barry: of course
<barry> or if the refactoring is "minor"
<intellectronica> of course
<cprov> danilos: will you disagree of anything intellectronica says today ? :)
<flacoste> danilos is looking for a fight i think ;-)
<danilos> cprov: you mean agree? :)
 * barry wonders who's gonna get voted off the channel today
<danilos> well, I am agreeing with intellectronica this time (at least the topic he proposed :), it's just that he seemed a bit uncertain after the first one :)
<cprov> danilos: I dunno, you tell me ...
<barry> do we need to discuss this topic more?
<intellectronica> not as far as i'm concerned
<salgado> maybe we could just put up some ads saying that if you (developer) refactor just code, you may get an rs= for some reviewer
<danilos> anyway, this is a good think to point out, but we should make this a bit more well advertised imo
<danilos> salgado: ah, sounds really nice!
<danilos> salgado: +1
<salgado> however, if you refactor both code and tests, you'll need a real review that may take much longer
<danilos> provided there's existing test coverage for the code
<salgado> that way we encourage them to do what's more appropriate
<salgado> s/them/us
<al-maisan> stupid question: why are we not to refactor both code and tests in the same branch? Because of the size?
<barry> salgado: i'm all for making it easier to land tech debt reduction branches
<danilos> al-maisan: no, because when you refactor only code, and tests still pass, we have much bigger certainty that your refactoring is good (even if we don't understand all the gory details of your code)
<al-maisan> aha
<barry> danilos: so maybe we need even more scrutiny of test refactoring branches?
<salgado> al-maisan, IMO, it makes it harder to find whether or not your test refactoring left any code untested
<intellectronica> al-maisan: no, because part of the utility provided by the test suite is confirming that your refactoring is ok
<al-maisan> thanks!
 * noodles775 would love to have a refactor-only branch :)
<sinzui> salgado: I was planning to get lots of rs's from you on Friday to move some tests and rm some empty directories created by the migration script
<danilos> barry: maybe, but I'd be scared of proposing that :)
<barry> :)
<salgado> sinzui, I'd be glad to give you them, but Friday is a holiday here
<barry> sinzui: i think it's only /not/ a holiday in the us
<sinzui> salgado: then I will ask your your rs tomorrow
<danilos> anyway, I think salgado's idea is a nice one, and we can start offering rs=me for code refactoring only branches
<barry> danilos: i'd be okay with that
<intellectronica> i'm not sure i understand what the difference is, in this case
<intellectronica> you're still required to actually review the code, right?
<danilos> intellectronica: this is just a way of promoting it
<barry> intellectronica: well, if the tests pass and aren't touched...
<danilos> intellectronica: I think that's what's missing, telling people how we like our code baked
<intellectronica> seems confusing to me, and i don't see the benefits
<salgado> the way I was thinking, I'd glance through the code, check that there are no changes to tests and give an rs=me if the test suite pass
<intellectronica> salgado: but there are other aspects of the code you'll want to review, no?
<noodles775> and it might still be worth a 3rd party review to ensure there is good test coverage in the first place.
<danilos> salgado: I'd also like to be pointed at existing test for that particular code :)
<noodles775> danilos: exactly.
<salgado> intellectronica, depending on the kind of the refactoring, yes
<intellectronica> that it's well documented, orgnised in a maintainable fashion, formatted correctly, etc
<cprov> salgado: that sounds more like an easy r=me than an rs
<salgado> intellectronica, I'd decide that after reading the cover letter and glancing through the diff
<intellectronica> salgado: sure, makes sense
<barry> anyway, shall we move on?
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<salgado> cprov, I don't agree.  even when I give an rs=me, I usually glance at the diff
<barry>  * flacoste to look into storm/sqlobject result set compatibility
<salgado> they're imcompatible
<salgado> and not meant to be compatible
<barry>  * flacoste to work on API reviewer cheat sheet
<flacoste> i started
<flacoste> will finish for next week
<flacoste> i promise
<flacoste> although it's not worth much these days
<barry> flacoste: which one?
<flacoste> cheat sheet
<barry> cool
<danilos> flacoste: because of the economy crisis, or? :)
<flacoste> the previous is actually on allenap plate
<salgado> lol
<cprov> salgado: maybe, but it's seems to be all about offering review-friendly code, sometimes r sometimes rs, the difference isn't very clear.
<barry> flacoste: okay, i'll change that
<cprov> salgado: (not necessarily disagreeing on what you said, now.)
<barry> cprov: rs= almost always means "i didn't look at it, i trust you"
<allenap> flacoste: Do we want to try and update the Storm tree we're using, or shall I back port the IResultSet adapter?
<flacoste> allenap: better to backport
<flacoste> allenap: we are looking at updating Storm, but there was a bunch test failures
<flacoste> allenap: so if we want it now, it's a lot easier to backport and I think that it's a fairly small change?
<danilos> flacoste: maybe it's something for each team to look into (if you have a branch with updated Storm, I'd be happy to have translations-related tests looked over)
<allenap> flacoste: Yep, it merges cleanly, or at least it did last time I tried.
<danilos> anyway, not the right place for this discussion, I guess
<barry> yep, we'll keep it on the agenda for next week
<barry> gary's not here so we'll skip his action item
<barry> since we're almost out of time, i'll just ask if there's anything quick anybody else has?
<barry> 5...4...3...2...1
<barry> #endmeeting
<MootBot> Meeting finished at 09:45.
<barry> thanks everyone!
#launchpad-meeting 2009-04-09
<matsubara> #startmeeting
<MootBot> Meeting started at 10:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<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.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<sinzui> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<Ursinha> me
<herb> me
<intellectronica> me
<matsubara> rockstar, hi
<matsubara> al-maisan, hi
<matsubara> flacoste, hi
<danilos> me (so-so)
<matsubara> ok, foundations, code and soyuz missing. they can join in later
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (stub)
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<rockstar> me
<cprov> me
<matsubara>     * matsubara to file a bug about the missing select permissions that delayed the rollout
<matsubara>         * https://bugs.edge.launchpad.net/launchpad-foundations/+bug/353926
<matsubara>     * cprov to look up soyuz bugs 353568
<matsubara>     * matsubara to include francis suggestion to bug 353530 and ursinha to summarize what spm told her
<matsubara>         * matsubara commented on the bug.
<ubottu> Launchpad bug 353568 in soyuz "ubuntu/source/package/+index timing out" [High,Fix released] https://launchpad.net/bugs/353568
<matsubara>     * salgado to debug and fix bug 353863
<ubottu> Launchpad bug 353530 in malone "OOPS filing a bug using the email interface " [Undecided,Fix released] https://launchpad.net/bugs/353530
<matsubara>     * sinzui to email the list how we should address critical bugs on unmaintained apps (e.g. blueprint)
<ubottu> Error: This bug is private
<matsubara>     * matsubara to talk to mrevell to announce a maintenance in the DB for about 10 min outage in the next 2 weeks. ask mrevell to talk to stub about it
<ubottu> Launchpad bug 353863 in launchpad-registry "TypeError when finishing creating user account in lpnet" [Critical,Fix released] https://launchpad.net/bugs/353863
<matsubara>         * matsubara emailed mrevell about this.
<sinzui> matsubara: not done
<Ursinha> the info I had was useless to the bug report
<Ursinha> very superficial and not helpful, so I didn't add
<flacoste> me
<matsubara> cprov and salgado bugs are fix released. so that's done
<matsubara> sinzui, do you want me to add another action for your item?
<matsubara> for next week
<sinzui> matsubara: please do
<matsubara> [action] sinzui to email the list how we should address critical bugs on unmaintained apps (e.g. blueprint)
<MootBot> ACTION received:  sinzui to email the list how we should address critical bugs on unmaintained apps (e.g. blueprint)
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<matsubara> go ahead Ursinha
<Ursinha> all right!
<Ursinha> one puzzle for losas/stub, three bugs for foundations, three bugs for registry
<Ursinha> flacoste, bug 354593, bug 353926, openid resetting password, bug 358498
<Ursinha> sinzui: bug 357307, bug 358486, bug 358492
<Ursinha> herb/stub: we're having *lots* of oopses like
<Ursinha> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1194D1005. I've sent one email to lp list and spoken with jtv about that, something is killing the db connections, so when a request tries to re-use a connection that died it oopses like that. So herb/stub: do you know what can be possibly happening to the db?
<ubottu> Launchpad bug 354593 in launchpad-foundations "SSO exceptions views need proper branding" [High,Triaged] https://launchpad.net/bugs/354593
<ubottu> Bug 353926 on http://launchpad.net/bugs/353926 is private
<ubottu> Launchpad bug 358498 in launchpad-foundations "AssertionError OOPS on openid when resetting password " [Undecided,New] https://launchpad.net/bugs/358498
<ubottu> Launchpad bug 357307 in launchpad-foundations "TypeError when creating new account in lpnet" [Undecided,New] https://launchpad.net/bugs/357307
<ubottu> Launchpad bug 358486 in launchpad-registry "AttributeError when user is confirming new account and LP is checking if it was a suspended one" [Undecided,New] https://launchpad.net/bugs/358486
<ubottu> Launchpad bug 358492 in launchpad-foundations "ProgrammingError OOPS resetting password" [Undecided,New] https://launchpad.net/bugs/358492
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1194D1005
<sinzui> Ursinha: Account and LoginToken are Foundations issues
<herb> Ursinha: looking at the oops now...
<Ursinha> sinzui, looking..
<Ursinha> sinzui, thanks for changing that
<stub> Ursinha: The OOPS is showing that the database reconnection isn't working as it should. Why that connection died isn't on that OOPS - it would have happened on the previous request handled by that thread.
<Ursinha> so that's flacoste's too
 * sinzui did it a few minutes ago
<flacoste> sinzui, for AuthToken: +resetpassword, do you think salgado could look into this one?
<sinzui> flacoste: Not this week, He is gone. I can take the  +resetpassword in a few hours
<flacoste> Ursinha: for the branding bug, how often does it happen?
<flacoste> Ursinha: reworking these templates is going to happen, but it's not easy to fix now
<stub> Ursinha: We have watchdogs that kill bad connections. I don't recall seeing any reaped connections from the appservers recently.
<Ursinha> flacoste, about 6,7 a day
<Ursinha> stub, we had 2 thousand oopses like this one I showed
<flacoste> Ursinha: actually, i think these are related to the DisallowedStore error i'm seeing
<flacoste> Ursinha: because these links don't appear on normal SSO pages
<flacoste> stub: what the permission bug in 358492?
<flacoste> nm, i know what this is about
<Ursinha> stub, jtv said he saw a lot of "administrator terminated connection" errors on lp-errors-report list
<stub> When?
<Ursinha> yesterday
<Ursinha> I couldn't find them
<stub> Anyway - the reason the OOPS count is so high is the appserver isn't recovering like it should.
<flacoste> stub: could you look at this bug tomorrow?
<stub> I can look at the oops - I don't know if there is a bug yet (I think there is - not sure though)
<Ursinha> for the db killing spree no, there isn't
<stub> What db killing spree?
<Ursinha> at least I didn't open one, I'll do now
<Ursinha> ah
<Ursinha> I mean, the oopses
<Ursinha> the lots of oopses because of the appserver isn't recovering like it should
<stub> ok
<Ursinha> anyway, it's that bug you're talking about flacoste?
<flacoste> yes
<Ursinha> I'll open one and let you know
<Ursinha> that's all for me
<Ursinha> we have one critical bug, in progress
<Ursinha> so, if matsubara has nothing else to say, oops section is closed
<matsubara> [action] ursinha to file a bug about "appserver isn't recovering like it should causing too many oopses"
<MootBot> ACTION received:  ursinha to file a bug about "appserver isn't recovering like it should causing too many oopses"
<Ursinha> thanks sinzui, flacoste, stub and herb
<Ursinha> and matsubara, of course
<matsubara> intellectronica, can you move bug 269538 from fix committed to fix released?
<ubottu> Launchpad bug 269538 in bugzilla-launchpad/bugzilla-3.2 "Compilation error in plugin when authenticating" [Critical,Fix committed] https://launchpad.net/bugs/269538
<matsubara> or at least chase why it's not fix released yet?
<matsubara> that bug been in fix committed for ages
<intellectronica> matsubara: i have no idea what's going on with that. i'll talk to gmb about it
<matsubara> thanks intellectronica
<matsubara> thanks everyone
<matsubara> let's move on
<matsubara> [action] intellectronica to talk to gmb about bug 269538
<MootBot> ACTION received:  intellectronica to talk to gmb about bug 269538
<ubottu> Launchpad bug 269538 in bugzilla-launchpad/bugzilla-3.2 "Compilation error in plugin when authenticating" [Critical,Fix committed] https://launchpad.net/bugs/269538
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> 2009-04-04 - Launchpad experienced an outage most likely due to hitting some connection limits on the DB. Some users may have experienced issues for up to 90 minutes.
<herb> 2009-04-08 - Deployed r7947 to soyuz and xmlrpc servers.
<herb> Bug 156453 and bug 118625 continue to be problematic for us. Just want to make sure I'm keeping it on your radar.
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,In progress] https://launchpad.net/bugs/156453
<ubottu> Launchpad bug 118625 in launchpad-bazaar "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/118625
<herb> That's all for this week, unless there are questions.
<rockstar> herb, I have something to report here again!
<herb> woohoo!
<rockstar> herb, so we've identified the real memory pig.  Unfortunately, it won't be trivial to change.
<matsubara> cool!
<rockstar> herb, so we know where the issue is, and now we just need to schedule about two weeks and re-write loggerhead.
<herb> haha
<matsubara> hehe
<flacoste> the problem is that he is serious :-/
<herb> mine was a laugh of despair
<matsubara> rockstar, so are you tackling that for 2.2.4 and maybe 2.2.5?
<sinzui> flacoste: I believe the problem with +resetpassword is that it sends logintokens to users who have not setup a person yet.
<rockstar> matsubara, well, I doubt it'll be 2.2.4, because mwhudson is on leave for so much of it.
<rockstar> matsubara, what really needs to happen is that we need to be sequestered again for a week to do nothing but fix it.
<flacoste> sinzui: sounds about right, that shouldn't happen :-)
<sinzui> flacoste: I'll get this fix today
<matsubara> by we, you mean you and mwhudson or the whole code team?
<flacoste> sinzui: thanks a lot
<rockstar> matsubara, mwhudson and I.
<rockstar> matsubara, we got some really good work done at the Pycon sprints last week.
<matsubara> there's all hands and uds coming, maybe during that?
<matsubara> anyway, that's beyond the scope of this meeting.
<matsubara> I think that's all. anything else for herb?
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> thanks herb
<stub> Can you describe the memory leak?
<herb> thanks matsubara
<stub> During the last rollout, one of the database patches turned out to be relying on database row ordering for some data migration, with the end result being some newly created rows on the slaves had different primary key values to the master and each other.
<stub> This caused replication to block later when changes to the data on the master could not be duplicated on the slaves due to constraint violations, alerting us to the problem. We rebuild the slave databases to correct the problem (the safest way of recovering the situation).
<stub> The corruption was not noticable to end users and did not infect the master, as only the internal database ids where affected.
<stub> I was hoping to switch our master to the 16 core box, but public holidays and illness have put a hold on that this week.
<stub> On the 6th and 7th, some batch jobs erroneously had their database connections terminated. Sorry about that. It is unlikely this was end user visible.
<stub> echo... echo...
<sinzui> oi oi
<matsubara> stub, you're coordinating the downtime annoucement with mrevell, right?
<stub> I will
<matsubara> stub, ok. thanks.
<matsubara> anything else for stub?
<matsubara> thanks stub.
<matsubara> I think that's all for today.
<matsubara> Thank you all for attending this week's Launchpad Production Meeting.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:37.
<Ursinha> thanks all
#launchpad-meeting 2010-04-14
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> hello and welcome to the mostly-weekly reviewers meeting
<bac> who is here today?
<sinzui> me
<abentley> me
<bac> danilos, bigjools, gary_poster, gmb: ping
<gary_poster> me and pinging...
<bac> EdwinGrubbs, noodles775, jelmer, mars: ping
<danilos> me
<EdwinGrubbs> me
<bac> danilos: can you round up your team?
<danilos> bac, only henning is around but seems to not have come back from lunch
<bac> BjornT: are you interested in attending?  if so i'll continue to ping you.  let me know.
<noodles775> me
<gary_poster> for me team, I pinged leonardr and mars, and salgado is out
<gary_poster> s/me/my/
<bigjools> me
<bac> allenap: ping
<bac> [topic] agenda
<allenap> me
<MootBot> New Topic:  agenda
<mars> me
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * Mentoring update
<bac>  * New topics
<bac>    * Multiline parameter lists in function definitions vs. function calls [hennnige, jtv]
<bac>    * Reduction of negation preferred over "common case first" in if statements? [henninge, jtv]
<bac>    * Should doctests only be testable documentation? [abentley]
<bac>  * Peanut gallery
<bac> [topic] outstanding actions
<MootBot> New Topic:  outstanding actions
<bac> [topic] * bac to restart discussion on community reviewer/committers after feedback from elmo
<MootBot> New Topic:  * bac to restart discussion on community reviewer/committers after feedback from elmo
<bac> i (just barely) did this item by sending an email to the internal list this morning.  i hope we can have a good discussion there and come to a concensus.
<bac> [topic] mentoring update
<MootBot> New Topic:  mentoring update
<wgrant> For those of us playing at home, what was the 'feedback from elmo'?
<bac> hi wgrant
<noodles775> Regarding the mentoring update, jelmer is doing well - holidays this week though :)
<bac> wgrant: elmo shared the opinion of others that since launchpad is a service with the obligation to protect our user's private data we cannot allow community code contributions to go into the tree that automatically rolls to edge without a Canonical-employee review
<wgrant> bac: OK. Thanks.
<bac> wgrant: i'd like to get your feelings on the matter off-line whenever you have time.
<bac> noodles775: thanks for the update
<bac> [topic] * Should doctests only be testable documentation? [abentley]
<MootBot> New Topic:  * Should doctests only be testable documentation? [abentley]
 * bac going out of order since henninge is not here
 * noodles775 sits back a bit.
<abentley> I had gotten the impression that we had a consensus that doctests should be testable documentation, and everything else should be unit tests.
<bigjools> there seems to be some confusion on what testable documentation really is
<abentley> bigjools, could you expand?
<bac> does testable documentation live in 'doc' directories or is anything that uses the doctest framework?
<bigjools> I was hoping you would :)
<bigjools> abentley: depending on who I speak to they all have a different idea of what constitutes documentation, so I think we need to carefully define what we want to document
<danilos> I'd say "minimal test that demonstrates how API is used" would be classified as documentation
<abentley> Perhaps definitions are part of the problem.
<gary_poster> "minimal"?
<danilos> heh, they most certainly are
<danilos> yes, minimal, at least imho
<abentley> My definition would be a work whose contents were primarily descriptive, but contained examples of how to do things.
<gary_poster> perhaps it would be better to specify an audience?
<gary_poster> or...
<bac> minimal in the sense that real doc tests should test all corner cases
<gary_poster> s/better/helpful/
<abentley> Basically, something I might see in a reference book.
<bigjools> maybe we have use cases for different types of doc tests
<bac> er s/should/should NOT/
<noodles775> +1 for abentley's def.
<gary_poster> bac, danilos, ack
<bigjools> so yes +1 for abentley's as one type, but also it's sometimes useful to see test cases written in a narrative style
<abentley> A counterexample would be a work that contained mainly tests, and showed numerouse ways that the API would fail.
<gary_poster> agree with bigjools, but worried about how to delineate
<danilos> there are also corner cases which are tested with a single line of code but need a lot of narrative
<gary_poster> fine with abentley's general approach
<abentley> bigjools, many things are useful that are not, on balance, worthwhile.
<sinzui> abentley, I prefer your definition. In the view examples you cited, I think base and mixins need documentation since we expect engineers to reuse the view. but most views that get their forms exercised are better tested in unittest
<abentley> AIUI, doctests are much slower than unit tests.
<abentley> I find they are also fragile.
<bigjools> actually they can be much quicker
<bigjools> since the db is not reset between tests
<danilos> again, it's a matter of drawing the lines, and I am positive we can't do it here (anybody remembers actual pagetest stories, or series of stories?)
<sinzui> abentley, doctests are faster because they reuse data instead of setting up for each test.
<sinzui> abentley, conversely, adding to a doctest can be painful
<abentley> Anyhow, our definition of "testable documentation" doesn't matter unless we agree that our doctests should be testable documentation.
<danilos> and agreeing doesn't matter unless we all consider it a same (or well, similar enough) thing ;)
<abentley> I've looked at the test style guide and it definitely doesn't recommend one style over another.
<abentley> But I need to know whether I should be watching for doctests that aren't documentation in my reviews.
<bigjools> I consider an ideal doctest as one that describes to me how I should drive the object it's documenting
<henninge> me ;)
<sinzui> bigjools, I agree
<bigjools> anything else distracts
<danilos> I think you should, but there're also many old tests
<abentley> bigjools, that sounds somewhat compatible with what I was saying.
<danilos> for any new one: request it; for old ones, suggest it
<bigjools> maybe we need a second doctest dir "unit-doc" and move the old crappy tests into it
<bigjools> then we have a target to clean up
<bigjools> I figure most of them are soyuz :)
<danilos> bigjools, +1 (on everything except the name)
<sinzui> bigjools, abentley I think the distinction is that the documentation may not be in doc/ if is for a non intrerface
<abentley> bigjools, but a component of "testable documentation" would be prevalence of text, rather than just tests interspersed with a few words.
<bigjools> sinzui: +1, that's what I was suggesting a few minutes ago
<bigjools> abentley: we could keep that style, just not put it in "doc"
<abentley> sinzui, when you say Interface, do you mean the zope construct?
<sinzui> abentley, the tests in doc/ should be about what is defined in interfaces/
<bigjools> totally
<abentley> sinzui, it seems to me that there are items which are not defined there which are useful.
<abentley> For example, the job runner.
<sinzui> doc/tales.txt for example
<abentley> Or the direct branch committer.
<bigjools> it's obvious to me that we need more than one "doc" directory
<gary_poster> I think "documenting interfaces" is a subset of abentley's "reference documentation for developers"
<sinzui> When I document a view mixin, I expect it to be in browser/tests or browser/doc
<abentley> It would seem silly to document IRunnableJob and not the ways of using it, for example.
 * sinzui never understood why lp/<app>/tests is where all unittests go except for browser/tests
<abentley> sinzui, actually, ours usually go in lp/code/model/tests
<sinzui> abentley, I know, and that violates the flacoste rules for the apocalypse
 * sinzui had actually written migrater rules to put tests below the implementation class
<bigjools> can we drive to a solution here, or do we need to take this to the list?
<abentley> Okay, so how do we move this discussion forward?
<bigjools> I am thinking list
<sinzui> we talk about this 3 times a year
<noodles775> lol
<bigjools> because we never agree on anything :)
<bac> I don't think we're going to come to a decision here.
<sinzui> there will be no consensus, We need a dictator
<danilos> I say *somebody* go and define it; BjornT claimed to be interested in the past
 * bigjools steps up
<bac> So it is take it to the list again
 * sinzui wants a doctest-> unittest converter though
<bigjools> +1k
<danilos> bigjools: dictate! :)
<bigjools> danilos: clean my shoes
<danilos> sinzui, we've got one, it's called "sinzui"
<sinzui> bac: why the list, why not ask that we read all the previous threads
<bigjools> lmao
<danilos> bigjools, anyone, you heard the dictator :)
<bac> sinzui: hmmm, good point
<danilos> no lists, no discussions, somebody who cares enough go ahead and define the policy, put it in the wiki and we'll start pointing people at it in our reviews
<gary_poster> sigh
<gary_poster> what, did I say something?  don't mind me. :-)
<sinzui> I think this discussion has been productive. abentley and bigjools provided good definition of documentation and I think all of us can find doctests that fail that definition
<bigjools> this is important enough to gather more opinions please
<noodles775> sinzui: +1
<danilos> we'll get opinion as we build the policy
<danilos> s/opinion/opinions/
<bigjools> does else anyone want to create a second doctest dir to shove all the non-interface documentation into?
<danilos> we can even create a standard topic in this meeting to discuss what has come up during reviews last week
<sinzui> We are an open source project now, we do not need democracy, we want leadership via meritocracy.
<bigjools> or the other way, make a new one to put the interface docs in
<abentley> Is there anyone against the idea of requiring that new doctests are testable documnetation?
<danilos> bigjools, I don't mind
<danilos> sinzui, +1
<sinzui> abentley, +1
<bigjools> yes, provided there's a written definition of what that is
<bigjools> but you said it earlier so c&p is fine
<noodles775> abentley: +1, and even a strong push that when updating current doctests, converting them.
<gary_poster> fine with me
<bac> ok, so it *does* sound like we're coming to an agreement
<noodles775> s/current doctests/current doctests that are not documentation
<bac> I will take the item of collecting the thoughts and making a first draft of the new policy on the wiki, for us to refine later.
<danilos> (I'd say we've always had a majority agreement on high-level points, we just never implemented that agreement into policy)
<danilos> bac, thanks a lot!
<abentley> bac, thank you.
<bac> [action] bac to define new doctest policy.
<MootBot> ACTION received:  bac to define new doctest policy.
<bac> and we can have more focused discussions on the finer points here in the coming weeks
<bac> thank you abentley for pushing the discussion forward
<sinzui> bac will take off his mask as reveal that he is the supreme leader
<abentley> bac, np.
<gary_poster> heh
<bac> [topic] * Multiline parameter lists in function definitions vs. function calls [hennnige, jtv]
<MootBot> New Topic:  * Multiline parameter lists in function definitions vs. function calls [hennnige, jtv]
<henninge> Ah yes.
<bac> note we have six minutes, so let's not dawdle...
<henninge> I have since been told that this has been discussed recently, so now I am just asking what I should put in the style guide.
<henninge> http://paste.ubuntu.com/414360/
<MootBot> LINK received:  http://paste.ubuntu.com/414360/
<danilos> henninge, afaik, we've allowed both styles so far
<henninge> There seems to be different ways to format multi line definitions to multi-line calls, is that correct?
<danilos> henninge, or well, perhaps not for function definitions
<bac> most multi-line fcn calls don't follow the style shown
<abentley> danilos, for function calls, I have not been allowed to use the first style.
<henninge> or was I told rubbish?
<danilos> henninge, you can use the first style for calls as well; second style is not customary in function defs
<henninge> danilos: style guide only allows the second style for calls.
<noodles775> abentley: that's what the paste shows, that the styleguide *currently* says the second for calls... and not the first.
<henninge> noodles775: yes, I was told, though, that somewhere it was agreed to use the first for definitions.
<abentley> noodles775, right.  danilos seemed to be suggesting using the first style for function calls was permissible.
<henninge> I am just asking if that is the case and  I'll update the style guide.
<noodles775> Yep, so if so, let's update the styleguide :)
 * danilos thought it was, and I've written numerous lines of code in that style and nobody complained
<henninge> danilos: get jtv as a reviewer ...
<henninge> ;-)
<bac> danilos: me too.  i prefer the first.
<henninge> bac: for calls or definitions?
<abentley> Using the first style for function calls does have the advantage that it's suggested in PEP-8
<henninge> we could simple allow both styles for both situations
<bac> henninge: calls.  the first only for defn
<danilos> henninge, I prefer them for both, I resort to second style for calls only when function name is already long and I'd need 5 lines for 5 parametes
<danilos> bac, +1
<henninge> bac, danilos +1
<henninge> I'll put that in the style guide.
<bigjools> if your function call params are spreading that far, I'd be tempted to make a container object, FWIW
<bac> do we need a vote?
<bac> i think not.
<danilos> bigjools, sometimes just the function name is long
<bigjools> danilos: shrtn it :)
<bac> [action] henninge to update the style guide
<MootBot> ACTION received:  henninge to update the style guide
<danilos> bigjools, we can start considering names like 'zap_it' :)
<henninge> btw, style guide is this to me: https://dev.launchpad.net/PythonStyleGuide
<bac> henninge: may we roll your other item to next week?
<henninge> bac: that's fine.
<bac> great.
<bac> this has been a very productive meeting.
<bac> thanks for coming and participating.
<bac> #endmeeting
<MootBot> Meeting finished at 09:46.
<bigjools> thanks bac
<abentley> bac, thanks.
<danilos> bac, all, thanks
<gary_poster> thank you
#launchpad-meeting 2010-04-15
<Ursinha> OOPS-1564CEMAIL1
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1564CEMAIL1
<Ursinha> thanks ubottu
<bigjools> me
<danilos> me
<Chex> me
<Ursinha> I have to wake up the bot
<Ursinha> #startmeeting
<MootBot> Meeting started at 11:02. The chair is Ursinha.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Ursinha> 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.
<rockstar> "Gimp's sleepin'" "Well wake him up"
<Ursinha> [TOPIC] Roll Call
<Ursinha> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<MootBot> New Topic:  Roll Call
<sinzui> me
 * rockstar  
<Ursinha> me
<Ursinha> and all the others that already meed
<Ursinha> stub is excused
<Ursinha> gary_poster, allenap, hello
<allenap> me
<danilos> me (maybe I get counted twice)
<gary_poster> Ursinha: on call but sort of here
<Ursinha> :)
<Ursinha> gary_poster, ok, maybe matsubara can join us in your behalf?
<Ursinha> I'm moving on, will poke you when it's time :)
<Ursinha> [TOPIC] Agenda
<Ursinha>  * Actions from last meeting
<Ursinha>  * Oops report & Critical Bugs & Broken scripts
<Ursinha>  * Operations report (mthaddon/Chex/spm/mbarnett)
<Ursinha>  * DBA report (stub)
<MootBot> New Topic:  Agenda
<Ursinha>  * QA stats of the week
<Ursinha>  * Proposed items
<Ursinha> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<Ursinha> * matsubara to file a bug for OOPS-1553EC1332
<Ursinha>     * Filed https://bugs.edge.launchpad.net/launchpad-code/+bug/558597
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1553EC1332
<ubottu> Launchpad bug 558597 in launchpad-code "OOPS using person branch feed" [High,Triaged]
<Ursinha> * matsubara to chase critical bug 556839 with noodles or someone from soyuz
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/556839)
<Ursinha>     * chatted with noodles about this one. Jelmer is investigating.
<Ursinha> * matsubara chase someone from soyuz about expire-ppa-files failing script
<Ursinha>     * chatted with noodles about this one and he's going to reply to the failure email
<Ursinha> * gary_poster to investigate OOPS-1557EA572 and re-open or file a new bug for it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1557EA572
<Ursinha>     * Not needed. it's a code issue (bug 558585)
<ubottu> Launchpad bug 558585 in launchpad-code "branch merge proposal diff page should handle librarian outage better" [High,Triaged] https://launchpad.net/bugs/558585
<Ursinha> * matsubara to file a bug on launchpad-code about OOPS-1557EA572 including
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1557EA572
<Ursinha>   details from salgado ("the OOPS above is different from the one I'd seen when
<Ursinha>   fixing the bug.  that's in the view that generates merge-proposal diffs.
<Ursinha>   that view should either use StreamOrRedirectLibraryFileAliasView (which knows
<Ursinha>   what to do when the librarian is down) or do something similar to that")
<Ursinha>     * Done: https://bugs.edge.launchpad.net/launchpad-code/+bug/558585
<ubottu> Launchpad bug 558585 in launchpad-code "branch merge proposal diff page should handle librarian outage better" [High,Triaged]
<Ursinha> * matsubara to talk to foundations about launchpadlib untriaged items
<Ursinha>     * Done: talked to Gary about this and triaged a few bugs.
<Ursinha> it seems all bugs were filed and oopses sorted out
<Ursinha> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<Ursinha> all relevant bugs were discussed with people during this week; the most offenders are bug 553361 (~1200 oopses a day, targetted to 10.04) and bug 54005 (we're not sure this is the real one, given it's old)
<ubottu> Launchpad bug 553361 in launchpad-foundations "OOPS when accessing launchpad with no referrer, eg. via wget" [High,Triaged] https://launchpad.net/bugs/553361
<ubottu> Launchpad bug 54005 in launchpad-foundations "bugs.launchpad.ubuntu.com email ending up in Launchpad mailbox" [Low,Triaged] https://launchpad.net/bugs/54005
<Ursinha> bug 54005 (OOPS-1564CEMAIL1) is hard to debug given the almost empty oops report, but this emptyness is bug 230106, which deryck said won't be fixed now but discussed soon
<ubottu> Launchpad bug 230106 in malone "emails interface oops reports need better error messages" [Low,Triaged] https://launchpad.net/bugs/230106
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1564CEMAIL1
<Ursinha> we're having other email related oops, besides the OOPS-1564CEMAIL1 one: OOPS-1563CEMAIL101, to which I filed bug 563055, and gary_poster already triaged them
<ubottu> Launchpad bug 563055 in launchpad-foundations "Mail parsing failing with ValueError" [Low,Triaged] https://launchpad.net/bugs/563055
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1564CEMAIL1
<Ursinha> sinzui, do you know what's going on in this oops? OOPS-1564B963
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1563CEMAIL101
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1564B963
<Ursinha> sinzui, hi :)
<sinzui> Ursinha, it looks like an insane file name
<Ursinha> sinzui, is it possible to upload files with insane names?
<sinzui> I do not know
<sinzui> nunitv2
<sinzui> has one it seems
<allenap> Ursinha: I've now also commented on bug 230106, https://bugs.edge.launchpad.net/malone/+bug/230106/comments/3
<ubottu> Launchpad bug 230106 in malone "emails interface oops reports need better error messages" [Low,Triaged]
<ubottu> Launchpad bug 230106 in malone "emails interface oops reports need better error messages" [Low,Triaged] https://launchpad.net/bugs/230106
 * sinzui looks on site
<Ursinha> thanks allenap
<Ursinha> there's also another oops that I'm not sure who should take a look
<Ursinha> it's OOPS-1565O1873
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1565O1873
<Ursinha> maybe sinzui or gary_poster
<gary_poster> looking
<sinzui> Ursinha, the file is sane
<sinzui> http://edge.launchpad.net/nunitv2/2.5/2.5.3/+download/NUnit-2.5.3.9345.msi
<MootBot> LINK received:  http://edge.launchpad.net/nunitv2/2.5/2.5.3/+download/NUnit-2.5.3.9345.msi
<Ursinha> sinzui, I saw that
<gary_poster> Ursinha, I'll throw it to sinzui unless he throws it back.  we generally haven't worked on the gog stuff to my knowledge
<gary_poster> gpg
<Ursinha> I just didn't get why that happened
<Ursinha> allenap, your comment is interesting, would that be too hard to do?
<allenap> Ursinha: No, not too hard. Abel has made the statement logging code for webapps work well in a longer-running script context.
<sinzui> gary_poster, I accepted the bug, but the issue still looks to be an issue between slave and master
<Ursinha> allenap, cool! could you please check with deryck what does he thing about that idea? :)
<allenap> Ursinha: Okay.
<Ursinha> allenap, thanks
<Ursinha> sinzui, what should we do about that?
<sinzui> I do not know
<sinzui> I saw this happen in the UI two weeks ago
<sinzui> The CoC oopsed for 10 minutes then worked when the key was really visible
<Ursinha> hm
<Ursinha> sinzui, should I open a bug so that can be investigated properly?
<gary_poster> sinzui: re bug that you accepted: would you bring it up with me out of meeting then?  I'm happy to help, or take it from you if appropriate, but my understanding is that the answer is to use the context manager I mentioned before, and that you chould just use it to always connect to the master for this purpose.  I May be off base, so I'd like to coordinate with you .
<sinzui> We have a fix for the page to step out of that condition, but I do not know how to make the master pass the data appear in a timely fashion
<gary_poster> sinzui: do you mean you need info on the context manager I'm mentioning.  can find
<Ursinha> gary_poster, sinzui, I'll file a bug for that, is that ok for you guys?
<sinzui> These is a bug
<gary_poster> Yeah thought so
<sinzui> bug 562486
<ubottu> Launchpad bug 562486 in launchpad-registry "accessing pending_gpg_keys using the api fails to some users" [High,Triaged] https://launchpad.net/bugs/562486
<Ursinha> sinzui, okay, thanks
<Ursinha> [action] gary_poster and sinzui to discuss about the issues between master and slave that could be causing oopses
<MootBot> ACTION received:  gary_poster and sinzui to discuss about the issues between master and slave that could be causing oopses
<Ursinha> [action] allenap to follow up with deryck about bug 230106
<ubottu> Launchpad bug 230106 in malone "emails interface oops reports need better error messages" [Low,Triaged] https://launchpad.net/bugs/230106
<MootBot> ACTION received:  allenap to follow up with deryck about bug 230106
<Ursinha> I'm moving on
<Ursinha> we have three critical bugs, the two foundations ones are fix committed, one soyuz is in progress
<Ursinha> jelmer is working on the soyuz one
<Ursinha> I guess bug 514267 and bug 530002 are actually Fix Released, right gary_poster?
<ubottu> Launchpad bug 514267 in launchpad-foundations "InternalError on clusters under busy load" [Critical,Fix committed] https://launchpad.net/bugs/514267
<ubottu> Launchpad bug 530002 in launchpad-foundations "Launchpad edge 'devel' webservice serving 'beta' WADL" [Critical,Fix committed] https://launchpad.net/bugs/530002
<sinzui> Ursinha, The filename oops was caused when a chinese user used the chinese name to access a file that does not exist
<Ursinha> sinzui, oh boy
<Ursinha> chinese name
<sinzui> I think there was a transliteration problem for the user.
<gary_poster> yes, and...
<Ursinha> hehe
<gary_poster> yes
<Ursinha> sinzui, you mean he typed the url by hand?
<sinzui> I think so
<gary_poster> both are now marked as resolved
<Ursinha> thanks gary_poster
<Ursinha> sinzui, well, so I guess there's almost nothing we could do about that..
<Ursinha> in the failing scripts land, a fix for retry-depwait has landed production-devel, so the only script constantly failing has been fixed, it seems
<Ursinha> thanks everyone
<Ursinha> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Ursinha> hi Chex
 * Ursinha hands Chex the mic
<Ursinha> or the keyboard :)
 * Ursinha pokes Chex in every possible channel
<Chex> sorry
<bigjools> oouch!
<Chex> LP report for this week is short:
<Ursinha> SNAFU? :P
<Chex> - LP incidents of note:
<Chex>         : 11-Apr: swap alerts. restarted some LPNet servers. Bug: 531071
<Chex>         : 15-Apr: Librarian1 rapidly gobbling memory again, restarted to free up.  Bug 556245.
<ubottu> Launchpad bug 531071 in launchpad-foundations "lpnet app servers are leaking memory again" [High,Triaged] https://launchpad.net/bugs/531071
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/556245)
<rockstar> Looks like Launchpad is timing out for ubottu as well as myself.
<gary_poster> that's actually a different one
<gary_poster> you mean...
<Chex> these are existing issues, but I just bring them up as they occurred in the last week. any questions or comments?
<gary_poster> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/556245
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/556245)
<gary_poster> oh
<gary_poster> duh
 * gary_poster grins shamefacedly
<Ursinha> rockstar, that's a private bug, maybe that's why?
<gary_poster> yeah prob
<rockstar> Ursinha, ah, maybe.
<rockstar> I've been getting lots of timeouts on Launchpad recently...
<Ursinha> rockstar, any specific pages?
<rockstar> Ursinha, mostly bugs stuff.
<Ursinha> well, lp is working pretty fine for me these days, I'm actually happy with that :)
<Ursinha> rockstar, could you let me know when that happens, please?
<Ursinha> and about Chex bugs, anyone has something to add?
<bigjools> lp is sloooow right now
<rockstar> bigjools, thank you for confirming what I just said.
<bigjools> it just took about 13 seconds to load a simple page
<Ursinha> ouch
<Ursinha> Chex, do you know if is there anything going on right now that could be causing that?
<Ursinha> bigjools, do you have a link so I can test it here, please?
<bigjools> https://edge.launchpad.net/~launchpad/+archive/ppa/+build/1693771
<Chex> Ursinha: I just quickly looked at the lpnet servers, and db-master, I dont see anything striking at the moment
<Ursinha> bigjools, yes, that's really slow
<Ursinha> I'll check the timeouts more closely
<Ursinha> thanks bigjools, rockstar and Chex
<Chex> Ursinha: welcome
<Ursinha> gary_poster, about that bug Chex mentioned, is there anything that would be done soon?
<Ursinha> bug 556245
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/556245)
<Ursinha> I guess not
<Ursinha> I'll move on to finish this meeting today :)
<gary_poster> Ursinha: I'm going to ask stub to investigate it.  That's all I can say for now.
<Ursinha> gary_poster, that's fine, thanks
<Ursinha> [action] gary_poster to ask stub to investigate bug 556245
<MootBot> ACTION received:  gary_poster to ask stub to investigate bug 556245
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/556245)
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/556245)
<Ursinha> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<Ursinha> [action] Ursinha to send an email to stub asking for the dba report
<MootBot> ACTION received:  Ursinha to send an email to stub asking for the dba report
<Ursinha> [TOPIC] * QA stats of the week
<MootBot> New Topic:  * QA stats of the week
<Ursinha> and here are the untriaged bugs of this week
<Ursinha> launchpadlib: 13
<Ursinha> lp-dev-utils: 9
<Ursinha> launchpad-buildd: 9
<Ursinha> launchpad-foundations: 6
<Ursinha> launchpad-dev-moin-theme: 5
<Ursinha> lp-qa-tools: 3
<Ursinha> lpbuildbot: 2
<Ursinha> trac-launchpad-migrator: 2
<Ursinha> launchpad-loggerhead: 2
<Ursinha> launchpad-news-wordpress-theme: 2
<Ursinha> launchpad-help-moin-theme: 2
<Ursinha> launchpad-cscvs: 2
<Ursinha> launchpad-registry: 1
<Ursinha> launchpad: 1
<Ursinha> launchpad-documentation: 1
<Ursinha> tickcount: 1
<Ursinha> malone: 1
<Ursinha> so, it seems soyuz managed to triage of their bugs :)
<bigjools> \o/ \o/ \o/
 * rockstar gives Soyuz a cookie
<Ursinha> bigjools, congratulations :)
<gary_poster> :-)
<bigjools> did the last 30 this morning :)
<rockstar> You have to split between yourselves though.  I only had one cookie.
<Ursinha> haha
<Ursinha> :))
<Ursinha> I'll talk to people about the other ones
<Ursinha> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<Ursinha> anyone have anything else to add?
<rockstar> I have one thing to say, which I'll express in a haiku (ala barry)
<Ursinha> go ahead
<rockstar> Code team sprinting / this meeting is at 4 am / I am not waking up
<Ursinha> lol
<rockstar> That's for next week.
<Ursinha> thanks for letting me know
 * Ursinha gives rockstar a cookie for his creativity
<Ursinha> so I guess that's all for this week
<danilos> now rockstar has another cookie to hand to soyuz team
<Ursinha> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<Ursinha> #endmeeting
<MootBot> Meeting finished at 11:39.
<danilos> cheers
<gary_poster> thanks
<bigjools> hehe
<rockstar> danilos, lulz
#launchpad-meeting 2011-04-11
<rvba> wgrant: Hi! I guess you marking my bugs as qa-ok is due to the fact that I'm blocking the rollout and you know my developments are protected by the feature flag anyway ... right?
