#launchpad-meeting 2008-02-05
<thumper> barry: meeting soon?
<barry> thumper: 9 minutes
<thumper> barry: ta
<mwhudson> dammit, why is by clock slow
<barry> mwhudson: okay, 8 minutes :)
<mwhudson> barry: my clock says 10 :/
 * barry now tries to pull an agenda out of his ass
<barry> #startmeeting
<MootBot> Meeting started at 03:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> welcome everyone to this week's asiapac launchpad reviewer's meeting
<barry> who's here today?
<thumper> me
<mwhudson> me
<barry> jtv!
<jtv> me
<thumper> jml: ping
<barry> afaict that's everyone who's here on the channel.  should we expect anyone else?
<thumper> barry: jml should be here shortly
<jml> Hi
<barry> jml hi!
<mwhudson> jamesh?
<barry> jamesh: hi!
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>    * we fell behind during the sprint
<barry>  * Mentoring update
<barry>  * Review process
<barry>    * how to transition from on-caller to the next
<barry>    * Tool update
<barry>  * On-call reviews
<barry>    * Keeping the time to around 8 hours
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<barry> so, today + 1 week?  is this a good time for everyone?
<jml> yep
<mwhudson> sure
<thumper> yep
<barry> well, other than jtv ;)
<jamesh> yep
<barry> great
<barry> [TOPIC]  * Action items
<MootBot> New Topic:   * Action items
<barry> i think all the outstanding action items are for ameu
<barry> nothing for asiapac afaict
<barry> anybody know of anything i'm missing?
<jml> no.
<barry> cool
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
<barry>    * we fell behind during the sprint
<barry> pretty much sums it up.  4 of us were sprinting in florida, so none of us did reviews last week
<sinzu1> 6 were sprinting
<sinzu1> 4 were on-call
<jml> and some were at LCA :)
<barry> oh right
<jml> I have a question.
<jml> Is my queue on PendingReviews still the place to look for reviews that I have to do?
<barry> jml: go ahead
<thumper> I'd say yes
<thumper> (for now)
<jml> (excluding on-call day, of course)
<barry> jml: yeah, thumper's right.  it's a bit of a mess currently
 * barry looks to mwhudson and his PendingReview killing machine
<jml> barry: no worry!
<mwhudson> barry: we need gmb to finish his bit
<barry> jml: to make matters worse, i did a branch assignment after my shift today, so folks do have branches on the PR queue
<barry> mwhudson: don't worry, i'll bug him on wednesday :)
<jml> barry: move on?
<thumper> I do wonder how much work we should put into the PendingReview killing machine
<thumper> with the work on LP
<thumper> and I'm wondering if there is any way we could sync up more
<barry> thumper: ideally maybe the PR killer /is/ LP
<mwhudson> thumper: that's a fair point
<thumper> particularly I'm thinking of the combination of private remote branches and merge proposals
<mwhudson> thumper: it should be fairly easy to switch my plugin over to lp
<thumper> we are working on subscriptions for reviews now
<mwhudson> (once we have apis, i guess...)
<barry> it might be a while before we get the apis to support those though
<thumper> anyway, continue
<barry> thumper: what do you mean by "sync up more"?
<thumper> perhaps just focus our LP work more to help with the review process
<thumper> we are doing reviews
<thumper> so I'm wondering if we can try to move the review process to LP
<thumper> for the listings
<thumper> the "what reviews do I need to do"
<thumper> type thing
<thumper> I'll think some more and get back to y'all later
<barry> thumper: yeah, +1 to that.  i do think it's a bit silly to work hard on a separate PR killer unless it's good prototyping for what might eventually get moved to LP
<jtv> it'd be great, but having the branches on different projects might complicate things
<barry> thumper: please do!
<thumper> jtv: I'd suggest that we just use launchpad for branches
<thumper> rather than putting them on rosetta or malone
<thumper> et al
<jamesh> thumper: sqlobject, cscvs, etc?
<jtv> then I guess it belongs under the person page
<thumper> we could for those too I guess (I had forgotten about them)
<spiv> The non-launchpad branches are touched pretty infrequently.
<barry> spiv: agreed
<thumper> except bzr
<jamesh> spiv: PendingReviews currently has branches for zope, launchpad-loggerhead and cscvs
<barry> i wouldn't mind special casing them
<jml> I suggest a spec!
<barry> thumper: but bzr has its own review process
<jml> DirtCheapLaunchpadReviewsInLaunchpad
<thumper> barry: the launchpad copy of bzr
<barry> thumper: ah
<jml> because this is prolly out of scope for this meeting
<spiv> The launchpad copy of bzr is touched once or twice a month, I think?
<thumper> spiv: ack
<barry> thumper: do you want to work on a spec, or a wiki page with some thoughts and we can talk about it more on next week or on the m.l.?
<mwhudson> if we can get it working just for launchpad landings, it's still a huge win
<thumper> barry: action me, and I'll write something somewhere
<barry> [ACTION] thumper to write up his thoughts about LP-as-PR-killer
<MootBot> ACTION received:  thumper to write up his thoughts about LP-as-PR-killer
<barry> anything else on this topic?
<barry> 5
<jtv> "go thumper"
<barry> 4
<barry> 3
 * mwhudson as forgotten what the topic is :)
<barry> 2
<barry> 1
<jml> Queue Status
<thumper> mwhudson: can you ask MootBot
<thumper> ?
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<thumper> MootBot: topic?
 * thumper was curious
<barry> mwhudson: the topic is "mentoring update" :)
<jml> I am on neither end of a mentoring stick
<thumper> me neither
<barry> jml: we can change that if you want :)
<spiv> Ooh, MootBot can talk through barry.  That must have been tricky to code... ;)
<barry> spiv: not tricky, but a little, um, uncomfortable
<mwhudson> jtv is the only non-full-reviewer in the meeting?
<jml> barry: I'm open.
<mwhudson> i guess we overlap enough with US people to mentor them
<thumper> who needs reviewing?
<barry> i think i'm looking for a mentor for schwuk
<thumper> barry: you probably want someone closer to him than all us
<barry> right now all the mentorees are in europe: danilo, allenap, bigjools
<barry> and jtv
<jtv> "somewhere inbetween"
<thumper> who is in asiapac who isn't a reviewer right now?
<jtv> thumper: me
<thumper> jtv: you're in the middle, so count as a reviewer
<barry> jtv: jamesh is your mentor right?
<thumper> I was meaning "not in training" even
<jtv> barry: right
<jtv> thumper: I meant geographically really, but anyway, never mind me then.  :-)
<jml> thumper: no one, afaik.
<jamesh> I think jtv's reviews have been great, so I'd be happy for him to graduate
<jtv> yay!
<barry> yay!
<thumper> jtv: you are in asiapac
<jml> thumper: in fact, we are over-blessed with reviewers, since spiv isn't even on the LP team :)
<thumper> jtv: congratulations on your promotion
<thumper> :)
<jtv> thanks!
<sinzu1> \0/
<barry> jtv: congrats!  i will make it official after this meeting
<barry> i just looked on directory.c.c and i think all of asiapac are now reviewers
<thumper> go asiapac!
<barry> i think we may soon have some americans (in the broad sense) coming on line soon for reviewing, so there may be enough overlap for y'all to mentor
<barry> maybe in a cycle or two
<mwhudson> it's probably a /little bit/ soon to get Aaron on the team :)
<thumper> just a little
<barry> i'll ask schwuk what he thinks about having an asiapac mentor.  if he's okay with it and one of y'all is too, then that's fine with me
<barry> anyway...
<mwhudson> i'm not sure it's a good idea, unless he keeps strange work hours
 * thumper agrees with mwhudson
<barry> mwhudson: you're probably right.  maybe we just have to wait until we get some ameu slots open then
<barry> such is life
<barry> anything else on this topic?
<barry> 5
<barry> 4
<jml> not from such as I!
<barry> 3
<barry> 2
<barry> 1
<barry> [TOPIC]  * Review process
<MootBot> New Topic:   * Review process
<barry> there's probably not much to say about the tool, right?
<barry> (that we haven't already said)
<jtv> except it stopped working for me :(
<barry> jtv: you mean the lpreview plugin?
<jtv> barry: right
<mwhudson> well, i'm here to hear the comments now, i guess
<jtv> but the same happened to pqm-submit, so it may be my system.
 * barry will be using it tomorrow :)
<jml> mwhudson: has abentley talked to you about it?
<jamesh> jtv: for sending email, or other?
<jtv> jamesh: sending email
<sinzui> jtv: did you mail setting change?
<mwhudson> jml: he sent me a couple of bundles to fix some option texts
<jtv> sinzui: not that I _know_
<mwhudson> jml: but nothing very significant
<jamesh> jtv: bzr-pqm-0.92 should be able to send through Canonical's SMTP server if you want to try that
<mwhudson> jtv: review-submit uses the stdlib's smtplib module
<jtv> jamesh: I already use that server.  Maybe that's the problem: it's certificate expired
<jtv> s/it's/its/
<jamesh> mwhudson: so does bzr-pqm, but the Canonical server is pretty picky about the sequence of commands
<jamesh> ehlo, starttls, ehlo, auth, then send message using an @canonical.com address
<jtv> jamesh: sounds like it... my mail client routinely claims it's "not an IMAP4 server"
<jtv> jamesh: scratch that, my coffee's still too hot for thought
<mwhudson> jamesh: still, no idea why it would _stop_ working if it once did
<mwhudson> anyway, off topic
<barry> moving on?
<jtv> moving on
<barry>    * how to transition from on-caller to the next
<barry> so i'm still unsure of the best way to transition to the next on-caller.  i just did as many reviews as i could, then assigned all the general branches to people
<jml> barry: what are the issues?
<barry> but what if people show up looking for on-call reviews and their branches are sitting in someone else's queue?
<barry> is that a problem?
<thumper> the reviewer should get to them within 24 hours
<mwhudson> barry: they check that the assigned reviewer hasn't started them and whip them out of the queue?
<jml> barry: as in, someone asked for an on-call review and the on-caller passed the buck?
<barry> jml: yeah.  i did that to one of intellectronica's branches today.  i just couldn't get to it
<barry> mwhudson: yeah i guess so.  if the reviewer is unresponsive though (because of timezones or whatever) it makes things tricky
<jamesh> if the branch isn't on the top of someone else's queue, maybe it should be fair game
<jml> barry: I reckon just pass the buck and send them a note.
<jml> barry: the burden still lies with the branch author
<jamesh> that said, we don't really distinguish between "hasn't been looked at yet", and "developer put branch back into needs-review state"
<jamesh> so it is difficult to say what the top of someone's queue is
<barry> jamesh: maybe we need "started" and "needs-further-review" states?
<jml> no we don't!
<thumper> barry: people don't edit the wiki now
<mwhudson> barry: going to sleep with a half-done review sounds like a bad idea
<thumper> barry: it'll be worse if you make them do it more
<jml> we need to KISS until it's part of Launchpad
<jtv> mwhudson: might be lunch though
<jamesh> I tend to agree with jml here
<jml> then we can over-engineer it for fun _and_ profit :)
<barry> yeah, okay.  if you guys say "it's not a problem" then i'll go to sleep and forget i ever mentioned it :)
<barry> just take notes if you find lines getting crossed and we'll figure out how to fix it when it happens
<mwhudson> okidoke
<barry> cool.  moving on...
<barry> [TOPIC]  * On-call reviews
<MootBot> New Topic:   * On-call reviews
<barry>    * Keeping the time to around 8 hours
<barry> sinzui: you had some concerns about exceeding 8 hours on reviews.  do you want a few minutes to talk about it here?
<sinzui> barry: I sent an email outlining my concerns. I have nothing to add right now
<barry> sinzui: cool.
<barry> that's all i have.  we have 3 more minutes for any other topic not on the agenda
<mwhudson> i should get myself an on-call slot
<barry> open floor
<barry> mwhudson: +1
<mwhudson> thursdays again looks like a reasonable choice
<barry> mwhudson: thursday asiapac slot?
<mwhudson> barry: yep
<mwhudson> might be cheeky and not spend all day this week on it though
<mwhudson> (i'm off tomorrow)
<barry> mwhudson: np.  btw, hope the move went smoothly!
<mwhudson> barry: seems to be going ok so far :)
<barry> mwhudson: can you edit OnCallReviewers?
<mwhudson> barry: sure
<barry> thanks
<barry> well, we're out of time, so...
<barry> #endmeeting
<MootBot> Meeting finished at 03:45.
<barry> thanks everyone and good night!
<jtv> barry: thank you, nice to see you again.  :-)
<thumper> barry: thanks
<barry> you too, and congrats jtv
<jml> barry: g'night
#launchpad-meeting 2008-02-06
<barry> i'll be right with you guys.  my machine is acting stupid
<barry> #startmeeting
<MootBot> Meeting started at 15:01. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello and welcome everyone to the ameu launchpad reviewers meeting
<barry> who's here today?
<sinzui> me
<statik> me
<bac> me
<intellectronica> me
<bigjools> me
<gmb> me
<gmb> (sprinting)
<allenap> me
<BjornT> me (at least partly)
<bigjools> which part? :)
<danilos> me
<barry> flacoste, schwuk ping?
<flacoste> me
<schwuk> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>    * jtv graduates
<barry>    * schwuk to be mentored by sinzui
<barry>  * Review process
<barry>    * Tool update
<barry>    * Release-critical review (flacoste)
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<barry> same time, week += 1?
<barry> anybody know they can't make it?
<bigjools> me
<bigjools> I will be on leave
<barry> actually, it's possible i might be late.  i have a meeting at my son's school an hour before that
<barry> bigjools: cool
<barry> i might ask someone else to chair it just in case the meeting goes long
<schwuk> I'll be in leave as well
<barry> schwuk: cool
<schwuk> s/in/on/
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * intellectronica to put cover letter draft on wiki
<intellectronica> ehm
<barry> :)
<intellectronica> didn't, i suck
<barry> we'll just carry it over then
<barry>  * (continued) gmb to work on the review web site
<barry> this topic came up on the asiapac meeting
<barry> thumper has thoughts about using launchpad to help kill off PR and not spending a lot of extra time on a separate project
<barry> thumper is going to write his thoughts up on the wiki
<gmb> Well I haven't had a lot of time to spend, so that's fine with me ;)
<barry> gmb: have you gotten a chance to look at review-board?
<gmb> barry: No, as I'm sprinting this week without a hotel internet connection :(. But I will as soon as I get chance.
<barry> i wonder if we could do something quick and dirty, like bring that up on devpad while we wait for uber-reviews on lp
<barry> i read the article but haven't had time to grab the code and fire it up
<gmb> I wonder how easy it would be to get lp-review working with it...
<barry> does anybody else have thoughts on using review-board in the short term?
<barry> gmb: that, and bzr
<gmb> Yes.
<statik> the tricky thing with review-board is getting it to accept our diffs
<statik> I never finished adding bzr support to review-board
<statik> due to lack of time
<barry> statik: did it seem like a lot of work?
<statik> it shouldn't be that hard, but it's more time than I have right now
<statik> the devs would be happy to get a patch for that
<BjornT> is review-board web-only, or can you access it via a command line tool, or e-mail?
<statik> no email (well, notifications I think)
<statik> web and rest api
<statik> but the review itself is done by clicking in ajaxy things in the web ui
<BjornT> then it gets a big -1 from me. i don't want to use a browser to do reviews
<flacoste> -1
<flacoste> same here
<sinzui> -1
<flacoste> review-board doesn't solve the PendingReviews problem at all
 * sinzui likes his tools
<barry> ok, then let's not waste any more time on it
<barry> thanks for the feedback!
<barry>  * (continued) sinzui to look into running `make lint` and output PR stanza by default in `review-submit`
<sinzui> barry: I have not...I completely forgot.
 * sinzui sets a todo
<barry> sinzui: np, thanks
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
<barry> i know we had a ton of branches while the sprints were happening last week.  thanks everyone for working hard to clear the backlog!
<barry> there's still a lot of pink in pending-reviews, but i think we'll catch up
<barry> anybody have any comments on the queue?
<barry> how have on-calls gone this week?  any comments on that?
<barry> 5
<bac> yesterday was fine.  didn't have much on-call traffic so i caught up on PR reviews
<jtv> For which we thank bac
<bigjools> I think a couple of sprints have reduced on-call significantly
<barry> indeed, thanks bac!
<bigjools> we should consider having backup reviewers on-call
<gmb> It wouldn't have been so bad, but most of the remaining reviewers were mentees :/
<bigjools> indeed
<barry> yep
<bigjools> I dread putting something on PR and wondering when it will get reviewed!
<barry> bigjools: PR needn't be post-and-forget.  even if you have a branch on PR, you can still ping an on-caller if they're available, or your reviewer if need be
<barry> but yeah, if we have more branches than cycles to review them, we need more reviewers or fewer branches
<bigjools> barry: I can but with timezone issues plus a lack of on-call reviewer it makes it harder
<barry> bigjools: yep
<jtv> Could we also ping the on-call and say "have a branch for me?"
<barry> jtv: you mean if you have spare cycles to review stuff?
<jtv> barry: right
<barry> jtv: you have spare cycles?! :)
<bac> jtv: grand idea
<jtv> barry: no, but I do get pangs of guilt sometimes
 * bigjools has an 800-line soyuz branch waiting for someone just like jtv :)
<barry> jtv: ah yes, guilt can overcome oppressively stressful overworking sometimes :)
<jtv> bigjools: jtv is currently reviewing a 2000-line one
<bigjools> !
<barry> :-o
 * bac remembers when 2000+ was the norm...  :(
<barry> moving on?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> [TOPIC] mentor updates
<MootBot> New Topic:  mentor updates
<barry> first off: congratulations jtv on graduating
 * jtv bows
<barry> give all your 2000+ branches to him :)
 * jtv runs
<barry> also, welcome schwuk who is joining the team, mentored by sinzui
<barry> thanks sinzui for volunteering to mentor schwuk
 * bigjools high-fives schwuk
 * schwuk starts to wonder what he's let himself in for
<barry> where "volunteering" means "allowing himself to be volunteered by barry" :)
<barry> [TOPIC] review process
<MootBot> New Topic:  review process
<barry>    * Tool update
<barry> jtv: weren't you having some trouble with lpreviews?  did that get cleared up?
<jtv> barry: it did, thanks.
<barry> jtv: great!
<jtv> barry: provider may have been guilty.
<barry> jtv: you mean your isp?
<jtv> barry: yes.
<barry> jtv: glad it's working now.
<barry> anybody have anything else to discuss on the tool?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry>    * Release-critical review (flacoste)
<barry> flacoste: the floor is yours
<flacoste> ok, this is about clarifying the process around release-critical reviews
<flacoste> the process should be this:
<flacoste> 1- when submitting a RC branch for review, make sure that the reviewer is aware that this is a RC branch
<flacoste> 2- if you cannot complete the RC review, make sure that there is someone assigned to complete the review before you leave
<flacoste> this means talking to another available reviewer that will do the job once you leave
<flacoste> we probably need to make the whole team aware of (1)
<flacoste> any comments?
<bigjools> sounds good to me
<barry> +1.  flacoste, can you capture this on a wiki page?
<flacoste> barry: i can send an email to the list about this, and I'll let you find a proper place to put that on the wiki
<flacoste> how does that sound?
<barry> flacoste: +1
<barry> [ACTION] flacoste to email RC review policy to list
<MootBot> ACTION received:  flacoste to email RC review policy to list
<barry> [ACTION] barry to capture RC review policy in a wiki page
<MootBot> ACTION received:  barry to capture RC review policy in a wiki page
<barry> flacoste: done?
<flacoste> yep
<barry> flacoste: thanks
<barry> that's it for the agenda.  we have 10 minute left if anybody has anything else
<barry> otherwise we can end early!
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 15:36.
<barry> thanks everyone!
<bigjools> cheers barry
<jtv> thanks barry
#launchpad-meeting 2008-02-07
<Aloha> premeeting tailgate
<Rinchen> a pre-gate?
<Rinchen> head gate?
<Rinchen> ah, no, a jump start!
<Rinchen> seems we've lost mootbot for today.  I've pinged the scribes team but I doubt it will be fixed in time
<Aloha> what happened?
<Rinchen> yea! Welcome back MootBot
<thumper> Rinchen: bet you're happy about that
<Rinchen> indeed I am!
<Aloha> woohoo bot is back
<Rinchen> welcome welcome.  There are plenty of chairs.
<Rinchen> There are a few down here in here front
<Rinchen> now, let's see if this project works
<Rinchen> #startmeeting
<MootBot> Meeting started at 17:55. The chair is Rinchen.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Rinchen> Welcome to the Launchpad Developers Meeting!
<Rinchen> The purpose of the meetings is to coordinate Launchpad development, and particularly to ensure that none of the developers is blocked from doing what they need to do.
<Rinchen> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<Rinchen>     *
<Rinchen>       Roll call
<Rinchen>     *
<Rinchen>       Agenda
<Rinchen>     *
<Rinchen>       Next meeting
<Rinchen>     *
<Rinchen>       Actions from last meeting
<Rinchen>     *
<Rinchen>       Oops report (Matsubara)
<Rinchen>     *
<Rinchen>       Critical Bugs (Rinchen)
<Rinchen>     *
<Rinchen>       Bug tags
<Rinchen>     *
<Rinchen>       Operations report (mthaddon)
<Rinchen>     *
<Rinchen>       DBA report (stub)
<Rinchen>     *
<Rinchen>       Sysadmin requests (Rinchen)
<Rinchen>     *
<Rinchen>       New packages required (salgado)
<Rinchen>     *
<Rinchen>       A top user-affecting issue (mrevell)
<Rinchen> ug
<Rinchen> Blockers
<Rinchen> Thumper just pointed out that my clock is apparently off
<stub> Only four minutes or so...
<stub> I was just sobering up
<mrevell> heh :)
<Aloha> lol
<barry> Rinchen: dress rehearsal?
<Rinchen> apparently
 * Rinchen kicks ntp
<intellectronica> since when are we having launchpad meetings dressed?...
<Aloha> heh
 * sinzu1 covers up
<Rinchen> well, let's do an early
<Rinchen> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<sinzui> me
<EdwinGru> me
<thumper> me
<mthaddon> me
<mwhudson> me
<kiko> me
<matsubara> me
<vednis> me
<mrevell> me
<BjornT> me
<Aloha> me
<jtv> me
<stub> me
<intellectronica> me
<barry> me
<salgado> me
<gmb> me
<Rinchen> [ACTION] Rinchen to fix intro script on the meeting page
<MootBot> ACTION received:  Rinchen to fix intro script on the meeting page
<danilos> me
<flacoste> am i late?
<flacoste> mr
<flacoste> me
<schwuk> me
<Aloha> flacoste, early
<Rinchen> [ACTION] Rinchen to fix agenda so it's cut-n-paste-able
<MootBot> ACTION received:  Rinchen to fix agenda so it's cut-n-paste-able
<allenap> me
<stub> ACTION Rincen to fix his ntp setup
<flacoste> stub: indeed!
<Rinchen> yeah, my ntp is hosed.
<carlos> me?
<thumper> stub: you missed the []
<danilos> :)
<matsubara> Rinchen: the agenda is actually quite cut-n-paste friendly if you use raw mode :-)
<flacoste> Rinchen jumped the gun
<Rinchen> I'm doing my normal...let's start early routine apparently
<Rinchen> Anyone who hasn't said ME, please do so now
<kiko> said ME!
<abentley> ME
<Rinchen> thanks
<Rinchen> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<Rinchen> The next meeting is on the 14th.
<Rinchen> kiko, same time, 18:00?
<stub> ME
<thumper> I like this time more
<barry> Rinchen: maybe 17:58? <wink>
<kiko> yes!
<Rinchen> [AGREED] Next meeting 14 Feb @ 18:00 UTC
<MootBot> AGREED received:  Next meeting 14 Feb @ 18:00 UTC
<Rinchen> [TOPIC] Actions from last meeting
<barry> well, i /know/ one of these days i'll take a late lunch and forget :)
<MootBot> New Topic:  Actions from last meeting
<leonardr> me
<thumper> barry: get google calendar to remind you :)
<Rinchen> there were no actions recorded
<barry> thumper: doesn't help when you're not in front of your lappie
<thumper> barry: it can SMS you
<Rinchen> [TOPIC]  Oops report (Matsubara)
<MootBot> New Topic:   Oops report (Matsubara)
 * sinzui 's phone has the launchpad cal on it
 * barry has cheap-ass cell services :)
<matsubara> jtv: Can you take a look at OOPS-764F1198? I think it's related to bug 186548, but didn't happen during an import
<ubotu> Launchpad bug 186548 in rosetta "Still an "iterable argument required" on Slovenian translation import" [Medium,New] https://launchpad.net/bugs/186548
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/764F1198
<Aloha> flacoste, the meeting is
<Aloha> hoser!
<matsubara> intellectronica: the +roadmap timeout bug is targeted to this cycle, but has no assignee. It's currently the second top timeout of the week
<matsubara> intellectronica: bug 185135
<ubotu> Launchpad bug 185135 in blueprint "+roadmap page still times out" [Undecided,Confirmed] https://launchpad.net/bugs/185135
 * Aloha likes the 1800 time
<danilos> matsubara: I was supposed to look at 186548, didn't have the time this past week
<kiko> matsubara, I saw a couple of odd oopses in the latest reports -- have you gone through them?
<intellectronica> matsubara: i'll take a look
<kiko> ah! also
<matsubara> danilos: right. is the OOPS I pasted above related to it?
<kiko> I have found a number of 404s related to merged accounts
<kiko> salgado, have some time to look over them with me later today?
<danilos> matsubara: very much looks like it; how many of those do we get?
<Rinchen> [ACTION] intellectronica to investigate Bug 185135
<MootBot> ACTION received:  intellectronica to investigate Bug 185135
<jtv> matsubara: certainly looks related
<danilos> matsubara: we used to have a single occurrence before, which is why I didn't bother
<abentley> kiko: I changed my username and now I get 404s.
<matsubara> kiko: I think we linkify a $name-merged in some portlet still
<salgado> kiko, could it be tomorrow? I am on call today and have a call with flacoste after the meeting
<matsubara> there's a bug for open for that
<abentley> It would be nice to have redirects.
<kiko> salgado, okay, tomorrow then, please remind me
<flacoste> abentley: the point of merging is to also free up the name space
<kiko> matsubara, OOPS-763C1027, OOPS-763D1843 OOPS-767B2435 OOPS-767E2288
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/763C1027
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/763D1843
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/767B2435
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/767E2288
<Rinchen> [ACTION] Salgado and Kiko to discuss recent 404s
<MootBot> ACTION received:  Salgado and Kiko to discuss recent 404s
<matsubara> there's another oops in the DataTimeWidget which I haven't reported yet. will do after the meeting
<Rinchen> did someone from Translations take the early oops request?
<Rinchen> jtv?
<abentley> flacoste: sure, but until the freed name is taken, you can redirect to the appropriate place.  A grace period.
<carlos> Rinchen: jtv did
<Rinchen> [ACTION] jtv to investigate  OOPS-764F1198
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/764F1198
<MootBot> ACTION received:  jtv to investigate  OOPS-764F1198
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/764F1198
<adeuring> me
 * Rinchen waves to adeuring 
<danilos> Rinchen: I already looked at it, it seems to be instance of the bug matsubara mentioned
<matsubara> Rinchen: that oops is related to the bug danilo will check out
<SteveA> me!
<matsubara> [ACTION] matsubara to file a bug about the DateTimeWidget oops (https://devpad.canonical.com/~jamesh/oops.cgi/OOPS-765EB80)
<Rinchen> ACTION] matsubara to file a bug about the DateTimeWidget oops (https://devpad.canonical.com/~jamesh/oops.cgi/OOPS-765EB80)
<Rinchen> [ACTION] matsubara to file a bug about the DateTimeWidget oops (https://devpad.canonical.com/~jamesh/oops.cgi/OOPS-765EB80)
<MootBot> ACTION received:  matsubara to file a bug about the DateTimeWidget oops (https://devpad.canonical.com/~jamesh/oops.cgi/OOPS-765EB80)
<matsubara> thanks Rinchen
<Rinchen> meeting chair permissions, sorry
<Rinchen> anything else on oopses?
<matsubara> I think I'm done for now. thanks
<kiko> hey!
<Rinchen> great thanks matsubara
<kiko> what about the oopses I posted matsubara?
<matsubara> kiko: isn't that the 404 you and salgado are going to investigate?
<jtv> kiko: The last one was a known problem with tar file uploads (from what I see in the source, malformed ones)
<kiko> matsubara, no, none of them are 404s.
<Rinchen> [ACTION] matsubara to investigate OOPS-763C1027, OOPS-763D1843 OOPS-767B2435 OOPS-767E2288
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/763C1027
<MootBot> ACTION received:  matsubara to investigate OOPS-763C1027, OOPS-763D1843 OOPS-767B2435 OOPS-767E2288
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/763D1843
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/767B2435
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/767E2288
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/763C1027
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/763D1843
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/767B2435
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/767E2288
<Rinchen> moving on...
<Rinchen> [TOPIC] Critical Bugs (Rinchen)
<MootBot> New Topic:  Critical Bugs (Rinchen)
<SteveA> I want to discuss https://devpad.canonical.com/~matsubara/oops.cgi/2008-01-30/B1498 with someone
 * kiko kicks Rinchen 
<SteveA> later
<Rinchen> Hi, I have no critical bugs to talk about today but I would like to talk about bug which causes the "choose" widget to fail for beta team members. Thanks to sinzui for doing the initial problem determination.  I wanted a consensus that this is really high and not critical.
<Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/189742
<MootBot> LINK received:  https://bugs.edge.launchpad.net/launchpad/+bug/189742
<Rinchen> I have set that as high and not critical. Does anyone have any issues with that?
 * thumper looks
<SteveA> does it actually cause something to not work?
<SteveA> I'm kind of surprised at that
<Rinchen> Yes. Clicking on it does nothing.
<SteveA> I'd expect a JS error to be logged
<SteveA> ok
<danilos> SteveA: I remember jtv looking into it and suspecting some sort of cache issue
<kiko> no issues, but it's weird
<sinzui> SteveA: The popup widget will fail
<kiko> cache issue?!
<SteveA> nah
<SteveA> it's just going to the wrong host
<danilos> SteveA: (the OOPS for 'TranslationMessage deleted')
<SteveA> no problem -- we can fix it in apache easily enough
<jtv> danilos: the cache issue wasn't me
<Rinchen> We're agreed to leaving it as high then.   Objections?
<SteveA> Rinchen: I'd propose doing a workaround in apache then doing a proper fix as a medium priority task
<kiko> agreed
<danilos> jtv: didn't you mention something about looking into https://devpad.canonical.com/~matsubara/oops.cgi/2008-01-30/B1498 already?
<jtv> danilos: yes, but the cache issue wasn't me
<Rinchen> [AGREED] work around should be done in apache and the proper fix can be a medium task
<MootBot> AGREED received:  work around should be done in apache and the proper fix can be a medium task
<Rinchen> [ACTION] Rinchen to update the bug report
<MootBot> ACTION received:  Rinchen to update the bug report
<danilos> jtv: you are totally confusing me
<Rinchen> any further discussion on critical bugs before we move on?
<jtv> danilos: I did not suspect a cache issue.
<danilos> jtv: ok
<Rinchen> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<Rinchen> We have no proposed bug tags
<SteveA> just a sec
<SteveA> to clarify
<SteveA> the cache issue discussion was about OOPS B1498
<SteveA> not about the +dims on edge issue
<SteveA> clarification over
<Rinchen> [TOPIC] Operations report (mthaddon)
<MootBot> New Topic:  Operations report (mthaddon)
<mthaddon> Nothing major to report, rather disappointingly
<mthaddon> unless there are any questions, back to you, Rinchen
<Rinchen> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<stub> DB review review call with Mark scheduled for Monday. I don't forsee any issues with this months patches so hopefully formal reviews will all be done Monday or Tuesday at the latest.
<stub> Purchasing new kick arse db hardware to replace the existing kick arse db hardware is in the final stages. We can expect a little downtime as things are rsynced across. Thanks to elmo for the benchmarking and driving this through over the xmas break.
<stub> https://launchpad.canonical.com/AuthPersonSplit isn't finished or polished but is ready enough for people to have a look and approve or scream.
<stub> Me done.
<thumper> question
<thumper> stub: does this mean that the db won't be open until Tuesday?
<stub> thumper: Given it is Friday, it can open as soon as someone lands a branch that opens it.
<stub> thumper: If there is something approved from a previous cycle go for it.
<Aloha> stub, its friday for you?
<thumper> Aloha: and me
<stub> 1:20am
<jtv> and me
<Aloha> woah its thursday morning here
<thumper> stub: I'll talk to you later about my patch
<SteveA> I propose a call sometime next week with me, stub and some people from the Foundations team to talk over AuthPersonSplit
<kiko> good idea
<stub> It will need discussion.
<thumper> Aloha: 7:21am Friday here
<Rinchen> [ACTION] Steve to arrange a call sometime next week with stub and some people from the Foundations team to talk over AuthPersonSplit
<Aloha> thumper, almost 24 hours difference
<MootBot> ACTION received:  Steve to arrange a call sometime next week with stub and some people from the Foundations team to talk over AuthPersonSplit
<Rinchen> Anything else on DB?
<Rinchen> hmm my ntp client is fixed
<Rinchen> [TOPIC] Sysadmin requests (Rinchen)
<MootBot> New Topic:  Sysadmin requests (Rinchen)
<Rinchen> I have nothing to report on this, this week.  Is anyone blocked on an RT or have any that are becoming urgent?
<kiko> not me
<Rinchen> I will add that since lamont has joined IS, we have seen in an increase in ticket closures
<kiko> I posted an RT but forgot about it
<Rinchen> flacoste, barry - are the mailman RTs still ok as is?
<flacoste> Rinchen: i think so
<mrevell> Rinchen: I wouldn't say it was urgent but it'd be nice to get the Launchpad News blog some spam filtering. I'm hunting for the RT number.
<Rinchen> I saw those 258 awaiting moderation comments
<mrevell> Rinchen: Yeah, and because one of the spams is huge, WP freaks out and prevents moderation
<Rinchen> [ACTION] mrevell to ping Rinchen about new blog spam
<MootBot> ACTION received:  mrevell to ping Rinchen about new blog spam
<mrevell> thanks
<Rinchen> [TOPIC] New packages required (salgado)
<MootBot> New Topic:  New packages required (salgado)
<salgado> if any of the features you have targeted to this cycle depend on any library which is not in launchpad-dependencies or inside our sourcecode/ directory, come talk to me
<thumper> packages for lp?
<salgado> that's not really a new topic
<kiko> salgado, I have one
<Rinchen> lp dependencies
<thumper> salgado: turbogears for codebrowse
<kiko> salgado, cjwatson pointed out germinate is missing
<salgado> any others?
 * thumper wonders what germinate is
<SteveA> are we getting launchpad-dependencies inside our sourcecode tree?
<SteveA> I'd like that
<SteveA> thumper: it's a tool to work out the packages that appear in a distro
<Rinchen> [ACTION] salgado to investigate adding turbogears for codebrowse and germinate
<MootBot> ACTION received:  salgado to investigate adding turbogears for codebrowse and germinate
<SteveA> thumper: from a set of initial seeds, then looking at their dependencies
 * thumper nods
<salgado> Rinchen, I'm done, btw
<Rinchen> waiting on your reply salgado to Steve's question
<flacoste> Rinchen: i need to discuss this with salgado
<Rinchen> <SteveA> are we getting launchpad-dependencies inside our sourcecode tree?
<Rinchen> k
<flacoste> Rinchen: it was on my todo list, but forget about it during the sprint
<Rinchen> [ACTION] flacoste to discussing adding launchpad-dependencies inside the sourcecode tree with salgado
<MootBot> ACTION received:  flacoste to discussing adding launchpad-dependencies inside the sourcecode tree with salgado
<Rinchen> no problem, thanks
<Rinchen> [TOPIC] A top user-affecting issue (mrevell)
<MootBot> New Topic:  A top user-affecting issue (mrevell)
<mrevell> Hello. I don't have any user-affecting issues this week as all the usual sources have either dealt with issues I've raised previously or have been quiet.
<kiko> I'm concerned with rosetta timeouts again
<kiko> how about we resurrect the ole ajax suggestions patch?
<kiko> it's a simpler change and would work in the shorter term
<kiko> than a big refactoring
<kiko> opinions?
<carlos> kiko: as I said last time you said that (I think it was last week) I prefer that we profile the code before going for ajax...
<danilos> kiko: I'd still prefer going for the fixing only those messages which cause timeouts
<carlos> after having some profile information, we will know whether ajax is needed or trivial changes would improve the performance
<kiko> aren't we sure we're timing out because of the multiple requests for suggestions?
<danilos> kiko: we aren't
<kiko> okay. where's the profile, then?
<Aloha> whats the address for LP news blog?
<stub> I've been pushing strongly for suggestions to be done async
<mrevell> Aloha: news.launchpad.net
<jtv> there is no profile in the usual sense: we have oops reports.
<kiko> that isn't a very straight answer
<danilos> kiko: I am pretty sure we are timing out because of the few very common messages and their external suggestions
<Aloha> mrevell, thnx
<carlos> danilos: do you have documented your last profile work?
<kiko> can someone do the investigation and conclude and make a plan to fix this by next week?
<kiko> I just want a plan, not a fix
<danilos> carlos: that was before the refactoring
<danilos> kiko: sure, I'll do that
<carlos> danilos: I'm not talking about the data you got but the procedure you followed to do the profiling
 * kiko nudges Rinchen 
<Rinchen> was that action for danilos and the profile or the whole time out issue?
<danilos> carlos: I don't have it documented, it's not really a big deal
<jtv> List of possible ideas here: https://launchpad.canonical.com/Translations/Timeouts
<kiko> Rinchen, yes
<carlos> Rinchen: danilo does the profile, and the whole team prepares a proposal for next meeting
<carlos> based on the data we got
<Rinchen> [ACTION] danilos to investigate profiling and Rosetta team to prepare proposal for next week to fix remaining timeouts
<MootBot> ACTION received:  danilos to investigate profiling and Rosetta team to prepare proposal for next week to fix remaining timeouts
<danilos> matsubara: can I get a list of all the timeouts for +translate pages (I need exact message IDs where fetching external suggestion fails)?
<jtv> danilos: it varies.
<danilos> matsubara: I mean, is it possible to get that? (for the last week or so)
<Rinchen> I see no special request topics.... does anyone have any last minute items.. steve kiko?
<danilos> jtv: I know it varies
<SteveA> I wonder if there's a way to get the data by analyzing our oops reports specially...
<jtv> danilos: I mean, once it's loaded, it stops timing out.
<matsubara> danilos: yes, I can get them for you.
<kiko> pas mois
<danilos> jtv: not necessarily, I see many times same page timing out for 37 times or so
<danilos> matsubara: cool, thanks, should I ping you about it tomorrow?
<jtv> danilos: until it's fully loaded, yes.
<matsubara> danilos: yes, please do.
<danilos> matsubara: cool, thanks
<Rinchen> [TOPIC] Blockers
<MootBot> New Topic:  Blockers
<Rinchen> [AGREED] Releases Team:  Rinchen blocked on Moin OpenID nickname decision. Rinchen blocked on team support in Moin.
<MootBot> AGREED received:  Releases Team:  Rinchen blocked on Moin OpenID nickname decision. Rinchen blocked on team support in Moin.
<flacoste> Foundations: not blocked
<jtv> Translations team: Not blocked
<thumper> Code: not blocked
<BjornT> Bugs: not blocked
<kiko> Rinchen, what's this openid nickname stuff?
<kiko> I have read about it in emails but forgot all about it
<carlos> Rinchen: agreed?
<Rinchen> carlos, yeah so it shows up in the summary
<matsubara> Rinchen: [ACTION] matsubara to get last week +translate timeouts OOPS ids for danilo
<flacoste> kiko: OpenID returns the launchpad nickname instead of the wiki name
<Rinchen> [ACTION] matsubara to get last week +translate timeouts OOPS ids for danilo
<MootBot> ACTION received:  matsubara to get last week +translate timeouts OOPS ids for danilo
<carlos> Rinchen: so all blocked things should be set as agreed?
<matsubara> Rinchen: gracias
<flacoste> kiko: so on launchpad.canonical.com Rinchen is known as rinchen instead of JoeyStanford
<kiko> flacoste, can OpenID not pass back more than one identifier?
<stub> I think spiv was right all along and the wikis should be using emailaddress anyway
<flacoste> kiko: we can pass back the appropriate wiki name based on the connecting site and the information we have in the DB
<kiko> stub, that's still different from launchpad name
<flacoste> kiko: or we can pass extra information, but that requires the wiki to handle that extra information
<stub> (or I have to move Person.name to Account.name too)
<kiko> so either way a change needs to be made
<Rinchen> I think we should continue the wiki discussion after the meeting
<kiko> flacoste, how overbooked is vednis yet?
<stub> kiko: Yes. I'm just trying to push the direction it gets changed :-)
<flacoste> kiko: is not
<Rinchen> kiko, soyuz team blocked?
<kiko> flacoste, we could get him to look into this since it does block a big migration
<kiko> not really
<Rinchen> statik's team blocked?
<Rinchen> SteveA, special circumstances blocked?
<schwuk> hwdb: not blocked
<SteveA> jamesh, stub: blocked?
<SteveA> I'm not blocked
<stub> Nup
<SteveA> SC: not blocked
<Rinchen> bigjools, cprov - you guys blocked?
<Rinchen> I'll take that as a no.
<flacoste> kiko: yes, if that's what we want to do, it could
<SteveA> danilos, matsubara: I'd like to help you plan out how to analyze oops reports for maybe cacheing certain suggestions
<cprov> Rinchen: no
<flacoste> kiko: but i think stub has objections to syncing wikiname data across databases
<kiko> stub, only issue with using emailaddress is legacy links all over our wikis
<stub> We can sync stuff. But this is why we need the auth/person split discussion.
<kiko> right
<EdwinGrubbs> lpcomm: not blocked
<Rinchen> thanks EdwinGrubbs
<danilos> SteveA: we're just going to look into them and see if my suspicion is correct (if it is, then we're going to play with caching them)
<stub> The wikiname table needs to be refactored anyway. Great big hairy WHUI IMO
<danilos> SteveA: you are welcome to help anytime, though :)
<flacoste> what is WHUI?
<Rinchen> Thanks everyone for attending this week's mayhem...er Development Meeting.
<SteveA> flacoste: We Haven't Used It
<flacoste> thanks for a on time meeting
<SteveA> flacoste: what happens when a YAGNI isn't considered early enough
<flacoste> right
<thumper> :)
<Rinchen> #endmeeting
<MootBot> Meeting finished at 18:43.
<kiko> stub, well.. we use it in all our person pages actually
<mwhudson> what's the other one? DON?
<SteveA> danilos: I'm hoping we can get more specific than "we'll just look at them" :)
<kiko> there are many people that have multiple wikinames
<SteveA> yes
<mrevell> thanks everyone
<flacoste> sub, and Rinchen is probably a big user of the feature
<flacoste> that's why he's so vocal about it
<thumper> it was good to be here for a change
<flacoste> kiko: how many?
<flacoste> hey, i've got staging access...
<flacoste> i can check that
<kiko> GoOD
<stub> kiko: We use the information, but the design is my issue. Maybe WHUI isn't the term, but the table design is a pain to use the information the way we want to.
<danilos> SteveA: well, I can easily be more specific... I am going to count on which msgid's has the suggestion fetching been timing out, and the number of all suggestions in DB for those msgid's
<SteveA> stub: do a view on it, then mirror the view, perhaps?
<kiko> stub, how could it be different, though? sorry, I am unimaginative today
<SteveA> danilos: can we talk this over on a quieter irc channel in say 15 mins?
<danilos> SteveA: in my previous tests, these cases have caused the most problems (i.e. strings like "Name" which have thousands of translations per language in different PO files, thus DB needs to go through all of them)
<danilos> SteveA: I am mostly planning to be out in 15 minutes
<SteveA> danilos: so... grab hard and soft timeout OOPSes for +translate pages...
<SteveA> danilos: for a particular set of days
<danilos> SteveA: yeah
<salgado> thumper, kiko, bug 189994, fyi
<ubotu> Launchpad bug 189994 in launchpad "Add python-turbogears and germinate to launchpad-dependencies" [Medium,Confirmed] https://launchpad.net/bugs/189994
<SteveA> danilos: then, collate them by msgid
<mwhudson> turbogears is fun, because of a crack headed conflicts: line in a dependency
<SteveA> danilos: then, work out how much time is spent in suggestion-getting queries?
<danilos> SteveA: right, that's the plan (matsubara will provide me with an initial set of oopses for the last 7 days), I'll look for queries taking the most time
<mwhudson> (turbogears depends: on python-sqlobject|python-sqlalchemy and python-sqlalchemy conflicts: with psycopg1)
<stub> kiko: We will be logging into the wikis via openid using an emailaddress, so wikiname is purely legacy for our wikis. The table design where 99.9% have 'launchpad.net' or whatever as their wikiname is a bit borked.
<danilos> SteveA: exactly, and the prime suspect is the query from getExternalSuggestions
<SteveA> danilos: I'd like you to do this scientifically -- a scientist will write down the steps to produce a result -- in your case some figures time taken to get suggestions for particular msgids
<SteveA> danilos: then someone else can reproduce the analysis on other data, easily, if needed
<danilos> SteveA: uhm, that's how I am going to do it
<SteveA> danilos: to do this, the way of doing the analysis needs to be written down
<danilos> SteveA: that's how I've always did it, including the previous performance improvements I did
<danilos> SteveA: and that's what I always do (except for the specific 'import cprofile' and similar bits)
<SteveA> cool.  I'm very interested to see how it goes.  I think you had a very insightful idea to cache just the most common suggestions
<danilos> SteveA: sure, I'll keep you in the loop
<SteveA> thanks!
<stub> My rationale for moving the suggestions async as the preferred next step is that the pages would no longer time out - just some of them will take a long time to fully load but they are still usable. Even if we optimize and speed up the translation db queries, it still only *might* stop timeouts and then maybe only for a time until our dataset grows more.
<danilos> stub: there's another thing we're considering to actually remove exponential growth of data we have at the moment
<kiko> salgado, thanks
<danilos> stub: basically, sharing potmsgset's (between potemplates in different distroserieses)
<danilos> stub: of course, solutions we've discussed earlier about db replication will never hurt, and are truly the only real solution
<stub> danilos: Rosetta is still affected by load on other parts of Launchpad. Even if rosetta remains stable or shrinks it doesn't mean other parts of lp won't step up and chew up all the resources you need
<danilos> stub: agreed
<danilos> stub: especially with all the other considerations, like implementing search and getting stable results out of it
<danilos> anyway, done for the day
#launchpad-meeting 2009-02-03
 * sinzui is here, but why is he here.
#launchpad-meeting 2009-02-04
<flacoste> me
<mars> (psst, flacoste, we haven't started yet)
<mars> as evidenced by barry's absence
<barry> sorry for the delay folks!
<barry> #startmeeting
<MootBot> Meeting started at 09:06. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> welcome to today's ameu reviewer's meeting, who's here today?
<allenap> me
<mars> me
<gary_poster> me
<intellectronica> me
<bac> me
<flacoste> me
<salgado> me
<intellectronica> barry: abel apologises, he's in transit
<barry> intellectronica: thanks
<abentley> me
<BjornT> me
<barry> bigjools, cprov, EdwinGrubbs ping
 * bigjools offers apologies as he is sprinting
<bigjools> as is cprov
<barry> gmb:, rockstar, salgado, sinzui ping
<sinzui> oops
<barry> bigjools, cprov no worries!  enjoy the sprint
<salgado> barry, me'ed already. :)
<bigjools> we're redesigning the world, it's very enjoyable
<barry> salgado: oops, sorry ;}
<EdwinGrubbs> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * encourage appropriate RENormalizer use in doctests (it is nicer than ellipses in many cases), gary
<barry>  * Action items
<barry>  * Mentoring update
<barry>  * Peanut gallery (anything not on the agenda)
<flacoste> i have a peanut gallery item
<abentley> bigjools: remember to include beer waterfalls.
<gmb> me (sprinting, so distracted)
<bigjools> abentley: ++
<barry> flacoste: cool, i'll make sure we get to it
<barry> [TOPIC] * encourage appropriate RENormalizer use in doctests (it is nicer than ellipses in many cases), gary
<MootBot> New Topic:  * encourage appropriate RENormalizer use in doctests (it is nicer than ellipses in many cases), gary
<barry> gary_poster: the floor is yours
<gary_poster> :-) k.  So, I wanted to make sure everyone knew about the RENormalizing in zope.testing
<gary_poster> And I wanted to see if we could encourage folks to use it more when appropriate
<gary_poster> is anyone not familiar with what it does?
<barry> gary_poster: can you explain what that is for those not familiar with it?
<abentley> gary_poster: me
<bac> me
<intellectronica> gary_poster: not a clue, tbh
<gary_poster> k
 * BjornT knows about it, and doesn't like it so much :)
<gary_poster> so, you use it when an ellipsis is too generic, and when an example output might be more helpful
<gary_poster> so for instance, in your test, you might not want to specify what a host name is
<gary_poster> so you can write in your test that http://launchpad.net/ should be normalized.
<gary_poster> It's not good for big long strings IMO
<barry> gary_poster: do you have an example?
<gary_poster> but good for short bits in which having real text would help
<flacoste> my main gripes for it is that it's hard to setup using our current infrastructure
<abentley> gary_poster: What does normalized mean in this context?
<intellectronica> gary_poster: is there an example we can look at?
<rockstar> me
<gary_poster> yeah I was thinking that I should have gotten that.  One sec, we have one in the tree (my fault ;-) )
<mars> is this a feature already in doctest?
<flacoste> no
<flacoste> it's an addition on top of doctest
<flacoste> you have to install it as an outputchecker
<flacoste> iirc
<gary_poster> right.  you hook it up in tests.py
<flacoste> that's the setup part that isn't convenient
<flacoste> since we usually don't have a separate setup for doctests
<flacoste> but it's probablys omething we should change
<mars> setuptools extension points FTW
<sinzui> me
<BjornT> gary_poster: fwiw, i would like RENormalizing more, if it was possible to use it from within the doctest, instead of doing everything in the harness
<gary_poster> right.  sorry my grep was too promiscuous
<barry> flacoste: well, we kind of do, but it's tricky to add stuff globally
 * sinzui keeps typing into the wrong window
<gary_poster> BjornT: I can see that.
<barry> BjornT: you mean something like a + option?
<flacoste> like Bjorn says, having to modify the harness everytime you want to use it isn't convenient
<mars> oh, /that/ kind of setup - not activating the tool, but setting up the harness.  I get it.
<BjornT> gary_poster, flacoste: i'm not worried about the difficulty of setting up, but rather making it clear to the reader that something special is going on
<flacoste> barry: +1
<BjornT> barry: yes, something like
<barry> flacoste, BjornT that makes a lot of sense (maybe: i still don't quite know what renormalizing looks like :)
<intellectronica> gary_poster: perhaps it would be better to write about this to the list, so that we can discuss after we've all familiarized ourselves with it?
<gary_poster> ok, so in the set up:
<gary_poster> lib/canonical/launchpad/mail/ftests/test_stub.py
<flacoste> barry: think of it as a regex that is applied before comparing the output
<barry> flacoste: that's kind of cool
<flacoste> barry: it is!
<flacoste> not just that convenient to use
<flacoste> especially if you need a bunch of different normalizing rules for different examples in the same test
<flacoste> being able to control it from within the doctest would be a huge gain
<intellectronica> oh, now i understand. i agree with BjornT, having this transformation done behind the scene without any indication in the document itself sounds very confusing to me
<barry> gary_poster: nice example, i get it
 * barry agrees
<flacoste> well
<flacoste> i think the confusion springs for us to be accustomed to seeing ellipses everywhere
<gary_poster> so the premise is that it is supposed to make it easier to get the gist; and that it makes the test a-bit-to-a-lot more precise than an ellipsis
<flacoste> if the policy was never to use ellipses
<flacoste> it isn't confusing
<flacoste> because you know that normalisation is happening
<flacoste> always
<flacoste> or can expect it to be
<barry> i've never looked: how hard is it to add new +OPTIONS?
<flacoste> i think it is very hard
<flacoste> not pluggable at all
<gary_poster> so anyway, my proposal is that we encourage the use of this thing.
<gary_poster> Right
<barry> dang
<mars> barry, doctest.register_optionflag(name)
<gary_poster> You may be able to do it in zope.testing
<flacoste> ok, i'm on crack
<gary_poster> because that is already essentially a fork of dictes
<gary_poster> heh
<gary_poster> doctest
<gary_poster> since it is not pluggable
<flacoste> well, mars seems to indicate that it is
<mars> http://docs.python.org/library/doctest.html#doctest.register_optionflag
<MootBot> LINK received:  http://docs.python.org/library/doctest.html#doctest.register_optionflag
<abentley> bzr development frequently uses assertContainsRe in its unittests, and it's quite useful.
<flacoste> heh MootBot, you're not on strike today!
<barry> um, okay, that registers the flag, how do you tell it what the flag should do?
<abentley> (It asserts that a string contains a given regex)
<gary_poster> Well, I know that customizing doctest has been a problem
<gary_poster> and right
<gary_poster> this is not just a flag
<abentley> This seems similarly useful.
<abentley> Though it does kinda get away from the idea that the tests are documentation.
<barry> gary_poster: are you interested in investigating whether renormalization can be hooked into a +flag?  if so, then i think we could start using it in a limited/experimental way
<flacoste> barry: i don't think we should start there
<flacoste> i think we can try using it today
<flacoste> with the current limitations
<gary_poster> abentley: do you feel that the example I gave took it away from documentation?
<flacoste> which will give us more exposure to the setup problems
<gary_poster> the idea there was that it helped, since an example revision # is more informative than an ellipsis
<abentley> gary_poster: No.  The example you gave didn't seem to need it either, though.
<barry> flacoste: that sounds good to me
<gary_poster> abentley: you mean, an ellipsis would have been as good or better for you?
<abentley> Regexes tend to look like line noise.
<abentley> gary_poster: Yes.
<gary_poster> abentley: hm.  diff'rent strokes and all I guess.
<barry> abentley: but you don't generally see the regexp in the doctest, and also ellipses can often be distracting
<gary_poster> ok so anyway, barry, that's my spiel. :-)
<gary_poster> as an aside, maybe we ought to investigate manuel or other more flexible doctest mechanisms at some point, but that's a much bigger deal
<barry> gary_poster: thanks.  can you send an email to the ml explaining this and letting them know we can use it experimentally?
<abentley> gary_poster: Okay, I skimmed too quickly.
<barry> gary_poster: yeah, and yeah :)
<abentley> gary_poster: It's not as bad as I thought.
<gary_poster> abentley: cool
<gary_poster> barry: will do.
<barry> [ACTION] gary_poster to send an email to ml explaining RENormalization
<MootBot> ACTION received:  gary_poster to send an email to ml explaining RENormalization
<barry> thanks
<flacoste> my item?
<barry> flacoste: sure
<barry> [TOPIC] flacoste peanut gallery item
<flacoste> it's about dead zone reviews
<MootBot> New Topic:  flacoste peanut gallery item
<flacoste> TOPC: dead zone reviews
<barry> flacoste: you mean reviews outside my cell phone range?
<flacoste> how to proceed with branches that are ready when nobody is on call
<flacoste> for example, stuart put out a branch last week for review
<flacoste> that hasn't been picked up by anybody yet
<flacoste> simply because he didn't try finding a reviewer
<barry> rockstar: when are we getting mp queues? :)
<flacoste> nobody was on call when the branch was reviewed
<rockstar> barry, dunno.  thumper talked about it.
<barry> flacoste: didn't try or couldn't find?
<flacoste> i think the former, but nobody was on call
<flacoste> and previously
<rockstar> barry, but there is http://edge.launchpad.net/launchpad/+requestedreviews
<flacoste> the general queue was assigned automatically
<flacoste> but this kind of died with the advent of OCR
<barry> flacoste: well, not so much automatically, but i get what you're saying
<rockstar> flacoste, I still think it's the reviewee's responsibility to find a reviewer, even if there are tools for the reviewer to find outstanding reviews.
<flacoste> right, you put a branch on pending reviews and somebody would get to it
<barry> flacoste: as a fallback, you can always ping someone on #lp-code.  i've done reviews that way several times
<allenap> rockstar: Do you mean +merges? That link breaks.
<barry> rockstar: yep
<rockstar> allenap, no, +requestedreviews
<barry> flacoste: or, set up a mp and pick some reviewer at random to review it
<flacoste> well
<flacoste> that would be annoying for everybody i think
<barry> flacoste: yeah, but it shouldn't happen often, right?
<allenap> rockstar: Ah yeah, I see it.
<rockstar> allenap, sorry, address is https://edge.launchpad.net/~launchpad/+requestedreviews
<gmb> flacoste: can't we just make it policy that the OCR checks the queue at the start of their shift for any un-owned branches?
<flacoste> that's more what I was getting into
<flacoste> back in the days of PendingReviews
<flacoste> allocating reviews was part of the OCR shift
<flacoste> and this was never replaced when we switched to MPs
<gmb> flacoste: Also
<gmb> A simple option would be to put your nick and a link to the mp in the queue in #lp-r
<gmb> Regardless of whether someone is on call.
<gmb> That way the next OCR knows what needs dealing with.
<flacoste> IRC is a lossy medium
<rockstar> I re-he-ally don't like the idea of just throwing a review on a pile and saying "get to this"
<flacoste> so i wouldn't count on it
<gmb> rockstar: What, any more than we do already? The only difference now is that hte reviewer can say "sorry, branch X took longer than I expected, no can do sunny jim"
<rockstar> gmb, but there's still an personal interaction there.
<gmb> True
<rockstar> For instance, I think there's real value in someone ASKING me if I can do a review even if I'm OCR.
<flacoste> ok, so we are changing the policy here
<flacoste> if we agreees on this change
<rockstar> Code reviews should not be mechanical.
<rockstar> Maybe we're changing the policy to match our current flow.
<flacoste> well
<barry> rockstar: i tend to agree with you
<flacoste> what about when we get drive-by contributors?
<flacoste> we'll have to have some form of queue there
<rockstar> My understanding has always been that it's reviewee's responsibility to make sure the branch gets reviewed.
<flacoste> rockstar: it is
<flacoste> but
<flacoste> there were mechanism to make that easy
<flacoste> now, it's much more "personal"
<rockstar> Yes, it's called "hey flacoste, can you review my branch" ?
<BjornT> rockstar: the problem is that it's not always easy to find someone online. if there's a policy that if you submitted the merge request yesterday, you can jump the queue, then it might work. otherwise we'll have branches that take a long time to get reviews, just because you'r not at irc at the right time
<flacoste> exactly
<flacoste> especially in dead zones like thailand
<barry> flacoste: the main thing i want to ensure tho, is that it's foolproof that the queue is managed correctly.  meaning specifically it cannot be possible that someone forgot to pop an item off the queue and an ocr wastes time reviewing something already reviewed because they failed to look in the magical right place
<rockstar> BjornT, you can email.  I've done reviews for jtv that way before.
<flacoste> which increase the turn-around time even more
<flacoste> since there is no queue management right now
<rockstar> If you're requesting a review from someone on the other side of the world, you're not worried about turnaround time.
<bac> email increases turn-around time?  not if stub/whoever looks at the schedule and picks the next OCR to come on duty
<flacoste> i think it's ok for the policy to be, you have to find someone to agree to review your branch
<flacoste> given the current number of reviewers it shouldn't be a problem
<flacoste> but we need to make that official policy
<flacoste> it means that once you have a merge proposal out there
<flacoste> there should be an indivual assigned to it
<flacoste> not just the LP team
<flacoste> otherwise, your branch isn't going to get reviewed
<flacoste> that's how review allocation is done through Launchpad
<rockstar> flacoste, well, it can be the LP team, just in case that person doesn't get to it in time (like in gmb's case).
<flacoste> that doesn't work
<rockstar> In that case, you ask someone else and they pick it up instead.
<mars> flacoste, rockstar, would adding a "Pending review by" column to +activereviews help?
<flacoste> and you assign it to them
<flacoste> if it's assigned to the team
<barry> flacoste, or anyone: do we know of other people having problems or is it primarily stub?  if the latter, we can add special cases for his situation
<flacoste> it's assigned to no one
<gary_poster> barry: foolproof that queue is managed correctly: sometimes you get a branch that has not been assigned specifically for you to review.  Maybe in that case you make a "i'm reviewing it" review initially as a marker for others?
<rockstar> mars, I don't know if it would.  It wouldn't help me.
<mars> rockstar, ok
<barry> dammit!
<rockstar> It would be helpful if you could un-request someone to review it.
<flacoste> barry: i only know of stub, but that's mainly because he's used to the old scheme
<barry> what did i miss? ;)
<barry> rockstar: that would be useful.  then stub could pick the next schedule ocr, which would work 90% of the time
<rockstar> Because ideally, once every reviewer says "Approve" then the status of the BMP should be "approved"
<barry> flacoste: as an ocr, i'd be happy if there were a stub branch or two that were waiting for me when i started
<abentley> gary_poster: Would it make sense for "claim review" to be separate from "perform review"?
<flacoste> yes!
<flacoste> there is no way to claim a review
<gary_poster> abentley: I think that would be cool
<flacoste> except by doing it
<barry> flacoste: i'd just pick them off first.  the question is, how best to seed the queue?
<flacoste> or marking your vote as abstain
<flacoste> which sounds weird
<barry> flacoste: what about this as a trial: stub can pick the next scheduled ocr, assign the mp to him, and leave a note in the channel topic
<barry> flacoste: that sounds simple and i think it would work for me.  if that fails then we can try something else
<flacoste> barry: i don't think making an exception for stub is useful at this point
<flacoste> we just have to state that you have to find a reviewer for your branch
<flacoste> so if there is no indivual reviewer assigned to it
<flacoste> your branch is not going to be reviewed
<flacoste> and run with it for a while
<barry> flacoste: stub was just an example.  i think most devs don't fall into dead zones
<flacoste> it's possible that it's not a problem in practice for anybody to be able to find somebody to commit to a review
<bac> reviewers will need to get in the habit of checking their +requestedreviews ... i know i've never looked at it before
<flacoste> the problem here is that he was expecting somebody to pick it up, like it used to work
<rockstar> bac, it's a relatively new view.
<flacoste> the problem is that there was a subtle change in workflow without any formal announcement
<flacoste> bac: well, if you commit to something, you commited to something
<barry> flacoste: i think i get what you're saying
<bac> flacoste: well, i didn't commit to it if someone just assigns the review to me
<flacoste> you only need to look at +requestedreviews if you have trouble remembering your commitments :-)
<flacoste> bac: nobody would
<flacoste> they would ask you permission to assign you to it
<bac> that's not what barry suggested ^^, which seems reasonable to me
<barry> flacoste: it's always been dev's responsibility to get reviewed, but you're right that it's relatively new that you had to actively round up a reviewer
<flacoste> hey bac, can you review this branch for me (because you are OCR, or simply because you are cool)
<flacoste> sure!
<flacoste> then I assign the review to you
<bac> flacoste: that's great if it is the flow we decide on.
<barry> flacoste: also would work: an email saying "hey barry, you're on call tomorrow so i left you a present"
<flacoste> well, it's the one that we seem to be using and that is possible given the current tool
<flacoste> (since we don't want to manage a queue somewhere else)
<bac> ah, nm.  being assigned a review will generate email addressed directly to me, so i'd know about it.
<barry> bac: yeah
 * bac still like the new +requestedreviews view...
<rockstar> bac, yeah, I do too, but I think it's important to have that acknowledgement/handshake in the review process.
<barry> flacoste: we're out of time today.  can you bring this up on the ml just to solidify the policy?  or email me to hash it out first
<BjornT> the problem with this workflow is that now you suddenly rely on a single person to have time to review your branch, instead of relying that any of the OCRs have time
<bac> Q:  i see ~launchpad/+requestedreviews has very few listed, which means ~launchpad is not automatically being added to some new MPs.  why is that?
<bac> BjornT: only if you're not around for the OCR.
<abentley> bac: Most likely because reviews created by email don't have that set.
<BjornT> bac: or the branch is around too late, so that you have to wait the next OCRs to start their shift
<flacoste> barry: i'll start a thread
<barry> bac: there are also some cases where mp's won't auto-assign a team
<bac> abentley: i created one this morning using lpsend
<barry> flacoste: thanks
<flacoste> BjornT: that's what I usually do, if i'm too late, i'll just ask somebody the next day
<abentley> bac: and it automatically requested ~launchpad to review?
<barry> [ACTION] flacoste to take dead zone reviews discussion to ml
<MootBot> ACTION received:  flacoste to take dead zone reviews discussion to ml
<bac> abentley: it did not.  i expected it would.
<bac> abentley: wrong assumption?
<BjornT> flacoste: right. it would still be nicer to ask a group of people, instead of a single person.
<abentley> bac: Wrong assumption.
<abentley> bac: Not that it shouldn't, but it doesn't.
<bac> abentley: ok.
<flacoste> BjornT: yeah, but my experience is that this doesn't really work in practice
<flacoste> at least, that's my experience with the advent of OCR
<flacoste> sure, the OCR might swap it between themselve
<flacoste> but only because the first one agreed to it
<BjornT> flacoste: that's why i said "would" :) it doesn't work atm, but it would be nice if it would
<flacoste> i agree
<barry> okay, sorry to do this and my apologies for starting the meeting late, but we're way over, so let's end things here and take it to the ml or #lp-code
<barry> #endmeeting
<MootBot> Meeting finished at 09:53.
<barry> thanks everybody
#launchpad-meeting 2009-02-05
<matsubara> ping MootBot
<matsubara> #startmeeting
<MootBot> Meeting started at 09: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
<herb> me
<jtv> me
<sinzui> me
<Ursinha> me
<rockstar> me
<jtv> I'm standing in for henninge today, since he's on sprint.
<matsubara> thanks jtv
<danilos> me
<BjornT> me
<matsubara> so, if any of you can't make the meeting next week, please coordinate with another teammate to cover for you and add a notice in the Apologies section in the MeetingAgenda page.
<matsubara> flacoste: ping
<intellectronica> me
<matsubara> bigjools: ping
<bigjools> me
<flacoste> me
<matsubara> ok, let's move on, stub can join 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 (DBA contact)
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>  * bac to check with barry if there's an open bug for  OOPS-1125A1096, if not, Ursinha to file one - there was, bug 280925
<matsubara>  * intellectronica to work on bug 279561
<matsubara>  * rockstar to check OOPS-1125CEMAIL1
<matsubara>  * bac to take a look at OOPS-1125A165 - bac filed bug 322792
<matsubara>  * Ursinha to check with kiko if any other rollouts will happen this week
<ubottu> Launchpad bug 280925 in launchpad-registry "Project overview page shows obsolete series" [Low,Fix released] https://launchpad.net/bugs/280925
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1125A1096
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/279561/+text)
<ubottu> Launchpad bug 322792 in launchpad-bazaar "Attempting traversal past an unknown object causes an OOPS" [Undecided,Fix released] https://launchpad.net/bugs/322792
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1125A165
<Ursinha> holy crap
<Ursinha> that bug is timing out
<Ursinha> or what?
<Ursinha> anyway
<matsubara> intellectronica: any news about the api bug?
<Ursinha> my items were done
<matsubara> rockstar: what's up about that oops?
<intellectronica> matsubara: sorry, no news yet
<Ursinha> matsubara, he landed a fix for that
<matsubara> Ursinha: who's he?
<matsubara> :-)
<Ursinha> matsubara, rockstar :)
<Ursinha> sorry
<rockstar> matsubara, I got an RC in for that one.
<matsubara> ok, I remember that one.
<matsubara> so I guess the only pending one is the api bug which is a mistery to everyone
<matsubara> the good news is that intellectronica found out another thing about that bug that might lead to its root cause
<matsubara> intellectronica: thanks for keeping us posted in the report
<matsubara> let's move on
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<matsubara> so in today's oops section I'd like to talk about the timeout bugs you guys are working for the LPW
<matsubara> https://dev.launchpad.net/PerformanceWeeks/February2009
<matsubara> I'm going to review all the landings related to LPW work and add to that page.
<matsubara> so if you wanna help, point me to revision numbers on RF related to that work
<jtv> matsubara: bug 324264 is now Fix Committed.
<ubottu> Launchpad bug 324264 in rosetta "Speed up +translations" [High,Fix committed] https://launchpad.net/bugs/324264
<sinzui> matsubara: r7705 for Bug: 325321
<Ursinha> jtv, great
<matsubara> intellectronica, BjornT : any news about the bug number 1 time out?
<sinzui> matsubara: EdwinGrubbs will land his branch today
<danilos> work on bug 302798 is in progress in different ways (there's a commit from 323something which disabled external suggestions to give us a better idea on how stuff is working, and henning is working on removal of obsolete translations which will reduce our DB size by ~33%)
<ubottu> Launchpad bug 302798 in rosetta "Timeout on +translate page" [High,Triaged] https://launchpad.net/bugs/302798
<BjornT> matsubara: me, intellectronica, and allenap are working on it
<jtv> danilos: hey, I was putting that paragraph together!
<BjornT> matsubara: allenap is looking at reducing the time it take to render the comments, possibly by not showing all by default
<danilos> jtv: ok, I'll let you handle it all from now on :)
<BjornT> matsubara: intellectronica is working on loading the subscribers portlet in a different request
<danilos> matsubara: you can have full trust in jtv as far as PW is concerned :)
<jtv> *cough*
<BjornT> matsubara: and i'm working on optimizing code, based off profiling information
<matsubara> danilos: I do! he's been very helpful with the status updates
<BjornT> matsubara: also, intellectronica's inital tests on dogfood were successful, reducing the time quite a lot :)
<matsubara> great
<flacoste> matsubara: i'm working on bug 316881 (which isn't an OOPS per-se, but related to performance anyhow)
<ubottu> Launchpad bug 316881 in launchpad "Page headers not suitable for HTTP caching" [High,In progress] https://launchpad.net/bugs/316881
<matsubara> stub: there's an email from jono asking for some help with the +project-cloud oops, so if you could help out there, would be awesome
<matsubara> thanks flacoste, i'll add it to the page
<stub> I've replied on the bug. Not sure if I'm helpful though.
<matsubara> stub: cool. thank you
<matsubara> bigjools: news in soyuz. how about the one muharem is taking care of?
<matsubara> s/./?/
<bigjools> matsubara: it's not going so well unfortunately
<bigjools> I don't expect any progress this week
<matsubara> [action] matsubara to add 316881 to foundations section in LPW wiki page
<MootBot> ACTION received:  matsubara to add 316881 to foundations section in LPW wiki page
<matsubara> bigjools: why is that?
<bigjools> matsubara: the first attempt to fix it failed.  he's also been at the distro sprint this week
<matsubara> bigjools: oh right. well, you guys are excused since the whole team is sprinting and you already landed 2(?) timeout fixes :-)
<bigjools> matsubara: thanks :)
<matsubara> I guess that's it from me. Ursinha, anything else?
<Ursinha> matsubara, no, the pending oops for soyuz I already talked with bigjools
<bigjools> yeah, get edge updating again and we'll see how it went
<matsubara> great. thanks everyone!
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> - 2009-01-30 - Friday we updated lpnet, edge and the scripts servers to to r7676.
<herb> - 2009-02-04 - Yesterday we updated codebrowse to r43
<herb> - I feel like I'm starting to sound like a broken record... But we're still being bothered daily, often multiple times, by bug #156453 and bug #118625 which seem to be related.
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,In progress] https://launchpad.net/bugs/156453
<herb> - We also continue to run into issues associated with bug #260171
<ubottu> Launchpad bug 118625 in launchpad-bazaar "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/118625
<ubottu> Bug 260171 on http://launchpad.net/bugs/260171 is private
<flacoste> herb: i herd mwhudson was working on loggerhead performance this week
<flacoste> as part of LPW
<matsubara> yes!
<sinzui> herb: There is a sprint in the planning to fix that too
<Ursinha> yes, he is
<matsubara> mwhudson is indeed working on that
<flacoste> herb: and well-placed sources also told me that a sprint is being organized to fix those damn issues
<flacoste> herb: so there is hope!
<herb> excellent. a fix would be huge for the LOSAs
<rockstar> herb, mwhudson is on the verge of insanity tracking loggerhead issues down.
<herb> thanks for all the work on that. it is much appreciated.
<matsubara> thanks herb
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> The production dbs seem to be ticking away nicely.
<stub> Staging db updates are being disabled by the losas for some testing, so expect a drop in timeout OOPSES.
<stub> I've had some db patches for this cycle come through already, which is great.
<stub> 3
<stub> 2
<stub> 1
<matsubara> all right. thanks stub
<flacoste> what about the staging issues?
<matsubara> herb: ^
<flacoste> staging isn't available at the moment
<herb> it's restoring
<flacoste> but we didn't understand why it failed?
<flacoste> or did we?
<matsubara> herb: how long will it take to restore?
<flacoste> and it's just that gmb is done with the testing and we can resume normal staging updates?
<herb> matsubara: should be back up within the next couple of hours.
<Ursinha> herb, about 10 hours ago I was talking with spm and he was unsuccessful to put staging on again
<herb> flacoste: upgrade.py failed because there will still connections open to the staging db.  This left the DB in an indeterminate state, so we had to go through the full restore process with a new copy of the staging DB.
<gmb> flacoste: I'm not done yet.
<gmb> flacoste: I need staging to be up for that
<flacoste> so this means that we are still screwed?
<stub> This is all useful information for read only launchpad btw.
<flacoste> we either need to fix upgrade.py to work without a db restore
<flacoste> or to turn off staging ugprades for the duration of gmb's test
<herb> flacoste: upgrade.py works fine
<herb> and we'll need to turn off upgrades while gmb's testing, per stubs note above.
<flacoste> why were there still connections open?
<stub> upgrade.py cannot work when there are active db connections, as upgrade requires exclusive locks on all the replicated db tables.
<herb> flacoste: the rollout process shuts down the app servers, but there are still potentially cron scripts running, etc.
<flacoste> why usually is this not a problem then?
<stub> Because the restore, replicate and upgrade process is done as a fresh db. Once it is finished, it is swapped into place.
<flacoste> ah right!
 * bigjools has to run, will catch scrollback later if you need anything from me
<flacoste> so when I said fix upgrade.py, i should have said 'fix rollout process'
<flacoste> so I guess it's best to simply disbale upgrade for now
<flacoste> i also heard that gmb might do his tests elsewhere
<flacoste> so that might becomes a moot issue
<flacoste> but like stub said, very instructive for read-only launchpad
<gmb> flacoste: Well, that's an embryonic idea right now. I still need a staging / demo machine for the forseeable future.
<matsubara> I want to make an action item for the fix rollout process thing
<matsubara> not sure who would be responsible for that
<matsubara> losas?
<herb> whoa
<flacoste> with the help of stub probably
<matsubara> [action] losas and stub to fix rollout process to avoid the staging restore problems
<MootBot> ACTION received:  losas and stub to fix rollout process to avoid the staging restore problems
<herb> there isn't anything inherently wrong with the rollout process.
<herb> but ok
<matsubara> thanks everyone
<matsubara> anythign else before I close?
<flacoste> well, it's currently not reliable if we don't do a DB restore it seems
<flacoste> nope
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 09:36.
<Ursinha> thanks matsubara
#launchpad-meeting 2010-02-08
<GeaNNy17> hellop
<GeaNNy17> e
<GeaNNy17> cinva??
#launchpad-meeting 2010-02-10
<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 LP Reviewers Meeting.  Who is here today?
<jtv> me
<jtv> hi bac
<sinzui> me
<noodles775> me
<henninge> me
<bac> hi jtv
<barry> lurk
<bigjools> me
<bac> BjornT, EdwinGrubbs, mars, gmb, allenap: ping
<gmb> me
<bac> adeuring, gary_poster: ping
<gmb> Thanks bac.
<adeuring> me
<mars> me
<bac> salgado: ping
<bac> who else are we missing?
<allenap> me
<gary_poster> me-ish
<BjornT> me
<bac> ok, let's move on and perhaps others will show up
<deryck> me
<bac> [topic] Agenda
<MootBot> New Topic:  Agenda
<bac> * Roll call
<bac>  * Action items
<bac>  * Landing branches for community contributors. [bac for jml]
<bac>  * Ease the "no lambdas" coding style to allow using them for Twisted callbacks. [heninge, allenap, abentley]
<bac>  * Peanut gallery (anything not on the agenda)
<bac> we had a lot of outstanding actions from two weeks ago but not much on the agenda for today.
<bac> [topic] action items
<MootBot> New Topic:  action items
<bac> [topic] * allenap to start discussion on the ML about doctest size, refactoring, moving corner cases to unittests, etc
<MootBot> New Topic:  * allenap to start discussion on the ML about doctest size, refactoring, moving corner cases to unittests, etc
<allenap> Dang, still haven't done that.
<allenap> Please keep it on the list.
<bac> allenap: will do.  you think you'll have time this week?
<bigjools> we need a new topic, "who sucks this week?"
<bac> [topic] * gary_poster to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again 10-Feb.
<MootBot> New Topic:  * gary_poster to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again 10-Feb.
<EdwinGrubbs> me
 * gary_poster cringes
<allenap> bac: Yes, I will. I do suck :(
<gary_poster> 17-Feb
<bac> did i say the 10th?  surely i meant the 17th, gary_poster
<gary_poster> :-D
<gary_poster> :-) thanks
<abentley> me
<bac> [topic] * brad to find and clean up relevant reviewer pages on lp.c.c and move to dev.launchpad.net.
<MootBot> New Topic:  * brad to find and clean up relevant reviewer pages on lp.c.c and move to dev.launchpad.net.
 * bac rocks
<henninge> cool bac!
<bac> i think i got all of this done.  let me know if there are other old pages that need carting over.
 * jtv cheers bac
<bac> [topic] * salgado to update the wiki page to encourage reviews with sufficient context.
<MootBot> New Topic:  * salgado to update the wiki page to encourage reviews with sufficient context.
<bac> salgado doesn't appear to be here so we'll hold that one
<bac> [topic] * bac to update coding guideline wrt conditional expressions.
<MootBot> New Topic:  * bac to update coding guideline wrt conditional expressions.
 * bac two for two
 * noodles775 claps
<bac> [topic] * barry to school us on the proper use of 'with'.
<MootBot> New Topic:  * barry to school us on the proper use of 'with'.
 * bigjools hi-5s bac
<bac> barry thanks for the great email on that topic
<barry> np!
<bac> it was really informative
<bac> and finally
<bac> [topic] * edwingrubbs to document JS namespace issue.
<MootBot> New Topic:  * edwingrubbs to document JS namespace issue.
<EdwinGrubbs> bac: yes, that has been added to the wiki, and I opened bugs for each team.
<bac> excellent EdwinGrubbs
<bac> so, we've closed about half of those outstanding issue
<bac> so on to new, hopefully more interesting stuff
<bac> [topic] * Landing branches for community contributors. [bac for jml]
<MootBot> New Topic:  * Landing branches for community contributors. [bac for jml]
<bac> ok, so this isn't too interesting
<bac> jml wanted us to discuss our approach for landing community contributions
<bac> i think unofficially we've assumed the reviewer would do it but that isn't always the case.
<jml> hello, I am unexpectedly here
<bac> i'm pretty sure we discussed in the past the idea that the contributor needs to find someone to do the landing and make arrangements.  but i think reviewers need to plan on taking care of the landing unless otherwise noted
<bac> hi jml.  welcome.
<henninge> bac: +1
<bac> jml's other point was the OCR should be the next contact if the original reviewer isn't around when the branch is actually ready
<bac> like i said, not controversial but we need to agree this is how we'll do it
<bac> thoughts?
<bac> ok, i'll formalize that idea and slap it on the wiki page
<henninge> I agree. Also, as mentioned before, all it takes is "ec2 land http://url_to_mp" in a current devel.
<jtv> doesn't that suffer from the last-minute-change hole?
<bac> [action] bac to update wiki page to make clear community contributor landing responsibilities
<MootBot> ACTION received:  bac to update wiki page to make clear community contributor landing responsibilities
<bac> jtv: it does
<henninge> oh, it does?
<jml> jtv, you mean, the script has a bug?
<bac> jtv: there is an easy fix to ec2 i'd like to do when i get a chance but haven't yet
<jtv> jml: not necessarily, but I'm not sure what behaviour is specified
<henninge> bac: also, I made it my practice to add "Landed by henninge" to the commit message, as we discussed earlier. Should that be formalized, too?
<bac> the problem is the contributor can push new changes to the branch during the time ec2 is running.  those new unreviewed, untested changes are then picked up and landed by pqm
 * henninge remembers
<abentley> bac, and also the contributor can push new changes while the branch is in PQM.
<bigjools> I always copy the branch before submitting it
<bac> abentley: sure, but that's generally a smaller windown
<jtv> I think bigjools' approach is absolutely the right one.
<jml> I think it's almost the right one.
<bigjools> I also think we should be emailed when a branch gets new revisions after a review has started
<jtv> But with that, resorting to the OCR when the reviewer is out of reach may lead to confusion.
<jtv> jml: given the current technical constraints.
<bac> bigjools: that's what i do now.  i wonder if we could get some tool support to make that less of a PITA
<jml> jtv, the tools are easily fixed.
<bigjools> I'd rather a way of freezing the branch
<abentley> I implemented merge directives so that they would specify the particular revision to land.  Unfortunately, PQM still doesn't support them.
<jtv> jml: all for that.
<bigjools> PQM must die
<jml> jtv, do it. if you have time to land someone's branch in a painstaking way you have time to make it easier for everyone.
<jml> bigjools, +1
<jtv> abentley: I'd prefer "refuse branches with unreviewed revisions" over "land an older version"
<bigjools> die in the most horrible manner possible
<jml> bigjools, swift death ftw.
<bigjools> jtv: +1
<bac> jml: the tools can not eliminate the PQM window abentley pointed out
<jml> bac, copying the branch addresses that issue too.
<bac> jml: yes, if that is the tool fix you're referring to
<jtv> jml: it narrows the window for unreviewed revisions and in return for that you get more time for revisions to be lost
<noodles775> Couldn't the current tool just not land the branch if there are extra untested revisions after it finishes the test?
<bigjools> I think the branch should get frozen once approved
<noodles775> Like a failure?
<jtv> noodles775: that's my preferred outcome
<noodles775> That way we could still use ec2 land safely?
<jtv> bigjools: I do sometimes have last-minute fixes, e.g. because I forgot to check for lint.  They need to be reviewed, but apart from that...
<bac> why is the 'reviewed revision' not set on our MPs?
<abentley> bigjools, our partly-implemented landing queues are reasonably sophisticated, but let's talk about that offline.
<henninge> jtv: well, you *could* always rs them, couldn't you?
<jtv> henninge: that'd be another extra feature I guess
 * henninge has never tried to approve his own MP
<abentley> bac, there was no immediate win.
<jtv> maybe it's not so bad if we can review our own cosmetic changes, as long as all revisions have been approved by _someone_ who is a reviewer
 * abentley has approved many of his MPs, because the reviewers neglected to set the status.
<bac> i think we've opened up a can of worms here that we need to discuss more on the ML, again.
<henninge> abentley: oh, I have done that, too.
<bac> let's table it for now
<bac> [topic] * Ease the "no lambdas" coding style to allow using them for Twisted callbacks. [heninge, allenap, abentley]
<MootBot> New Topic:  * Ease the "no lambdas" coding style to allow using them for Twisted callbacks. [heninge, allenap, abentley]
<henninge> This came up during a review on Monday.
<bigjools> heh, tabling means something different in British English :)
<bac> bigjools: like everything else
<henninge> allenap submitted code for review that uses Twisted and had lines like this
<henninge> d.addCallback(lambda ignored: reactor.stop())
<barry> hmm.  are use of lambdas "standard operating procedure" for twisted dev?
<jml> barry, yes.
<jml> barry, as is using 'd' for a narrowly-scoped Deferred
<barry> jml: then: when in rome...
<jml> barry, which is also verboten in our coding standard.
<jtv> stupid question perhaps but is there no "bind" in python?
<jml> bac, bigjools: http://www.economist.com/research/styleGuide/index.cfm?page=673901 (go to the end of page)
<jtv> d.addCallback(bind(reactor, stop)), something like that?
<allenap> abentley had a good point yesterday, which is that this is not about code reuse, but about adapting functions to be callbacks.
<allenap> jtv: There is functools.partial
<barry> jml: same reason we don't pep8 our method names
<allenap> jtv: But that doesn't help when you want to ignore an argument.
<jml> jtv, what definition of bind would make that equivalent to 'lambda ignore: reactor.stop()'?
<jtv> oic
<jml> http://paste.ubuntu.com/373295/
<MootBot> LINK received:  http://paste.ubuntu.com/373295/
<henninge> Ok, so do we agree that the use of lambda is acceptable in Twisted context?
 * jml agrees
<bigjools> +!
<sinzui> +1
<bigjools> and +1
<abentley> +1
<adeuring> +1
<allenap> +1
<barry> +1
<al-maisan> +1
<henninge> +1
 * barry would much rather see lambda than kerchop!
<bac> +1
<jtv> I hate for the rule to be so "arbitrary" though.
<bigjools> common sense applies
<henninge> cool, I'll update the guideline to say so.
<jtv> bigjools: now *that* is a rule I like
<al-maisan> kerchop was certainly enough of a deterrent to sway the votes ;)
<jml> "Break any of these rules sooner than say anything outright barbarous."
<bac> [action] henninge to update guidelines to allow lambda in twisted context
<MootBot> ACTION received:  henninge to update guidelines to allow lambda in twisted context
<noodles775> "Adapting functions to be callbacks" seems to make sense too though, as a more general context? - maybe that point should be said with the guideline :)
<bac> [action] bac to not use 'table' as a verb in mixed company
<MootBot> ACTION received:  bac to not use 'table' as a verb in mixed company
<bac> [topic] * Peanut gallery (anything not on the agenda)
<MootBot> New Topic:  * Peanut gallery (anything not on the agenda)
<jtv> bac: you split an infinitive.
<bigjools> lol @ bac
<deryck> it's allowed in southern US english
<bac> any new topic?
<barry> noodles775: well.  in general, lambdas shouldn't e used for callbacks.  it's just that twisted style embraces and promotes lambdas, so it's more a "fit in with twisted coding styles when necessary" rule
<noodles775> barry: oic
 * jml disagrees w/ barry, but whatever.
<barry> jml: :)
<bac> nothing else then?
<abentley> barry, it's also a matter of "writing twisted without lambdas is unnecessarily painful".
<bac> 3
<bac> 2
 * bigjools has a quickie
<barry> abentley: true that
<bigjools> topic, that is
<jtv> bigjools: enjoy it
<bac> bigjools: thanks for sharing
<bigjools> welcome
<bigjools> do I have the floor?
<bigjools> darn, did it again
<bigjools> In a review of mine, bac noticed that I had some long line lint in a file
<bigjools> that I'd changed, but not anything I'd changed myself.  The file was
<bigjools> _schema_circular_imports.py and someone had added very long lines to hack
<bigjools> the return types for API exports.  I want to remind people to use the
<bigjools> helpers in that file (e.g. patch_return_type()) because a) they're much
<al-maisan> stay away from the table though ;)
<bigjools> shorter, b) it factors the hacky code.  This might be worth having as
<bigjools> a review point if everyone agrees?
<barry> +1
<bac> bigjools: thanks for bringing that up.  i didn't know about the helper
<abentley> +1
<bigjools> also if you need to patch something and there isn't a helper, write one
<jml> a hearty +1 to that last point
<bigjools> and make an effort to convert some of the existing crack in the file if you edit it
<bigjools> that's it from me
<bac> [topic] ensure developers have tested API changes with launchpadlib
<MootBot> New Topic:  ensure developers have tested API changes with launchpadlib
<bigjools> heh
<bac> in that same review i noted bigjools was fixing an API change that hadn't correctly updated the WADL.
<bac> had the original code been exercised locally using launchpadlib the error would've been discovered
<bac> so, encourage the use of lplib.  it's easy and fun!
 * bigjools wants lplib-based tests ...
<jml> is it at all possible to automate?
<abentley> bac, do you mean that our tests should use the python launchpadlib library?
<bac> jml: we discussed that a long time ago and it wasn't do to the credentials problem
<jml> do we not include launchpadlib in our dependencies and generate the wadl every single build precisely because of this?
<flacoste> bigjools: that's actually possible iirc
<bigjools> flacoste: IIRC it wasn;t done because LP would have a dependency on lplib
<bac> leonardr has added new functionality to bypass the OAUTH browser dance which may make putting lplib into our test suite feasible now
<jml> bigjools, we already depend on lplib
<bigjools> oh?>
<bigjools> wait, that conflicts with your previous statement
<bac> gary_poster: perhaps foundations should revisit this issue to see if it is something we can do now
<jml> bigjools, poor phrasing on my part
 * gary_poster reads back
<jml> bigjools, get rid of the "do", "not" and the question mark, and add "don't we?" to the end.
<gary_poster> I think we can have lplib tests now.  I have some httplib hacks to make it possible in one of our layers.
<gary_poster> In any case, I was just talking to Leonard about him producing tests like this
<gary_poster> so then people can use that as an example
<bac> gary_poster: can one of your team do a prototype?
<gary_poster> :-) ^^^
<bac> [action] leonardr to create an example for automated lplib tests in the launchpad tree
<MootBot> ACTION received:  leonardr to create an example for automated lplib tests in the launchpad tree
<gary_poster> That should be within this cycle.  It will hopefully be produced as part of the webservice versioning work Leoanrd is doing
<bac> great!
<bigjools> \o/
<bac> that's it, we're out of time.  thanks for coming.
<bac> #endmeeting
<MootBot> Meeting finished at 09:45.
<jtv> thanks bac!
<bigjools> thanks all
<bac> hi thumper, mwhudson -- reviewers meeting?
<thumper> bac: hi, just getting on a call with mrjazzcat
<bac> thumper: will you be available this hour?
<thumper> yes, in 30 min
<bac> ok
<bac> mwhudson: reviewers meeting at :30
<mwhudson> bac: ack
<bac> thumper: let me know when you're available
<thumper> bac: ready
<bac> #startmeeting
<MootBot> Meeting started at 15:31. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<mwhudson> hi
<bac> hi, welcome to our, uh, quarterly ASIAPAC reviewers meeting
<bac> thumper is rockstar around today?
<thumper> bac: rockstar is not well today
<bac> sorry to hear that
<bac> so we had a good meeting today with the AMEU people
<bac> before we get to that, though, i'd like to chat with you two about these meetings and how to make them useful and informative.
<bac> i want you to be plugged in to what the rest of the reviewers are doing but don't want to show up here and regurgitate info about what happened at the earlier meeting.
<bac> thoughts on what you'd like to see?
<mwhudson> well, that part is useful tbh
<thumper> general agreements on change in style
<thumper> or issues that other reviewers are having
<mwhudson> it's nice to have a semi-interactive forum to disagree with the others :)
<bac> ok.  i try to keep https://dev.launchpad.net/ReviewerMeetingAgenda updated with at least the highlghts
<bac> and the log files are available
<bac> cool mwhudson
<bac> well do jump in so it doesn't feel like i'm just cut-n-pasting you a wiki page.  :)
<thumper> I just read the outstanding actions section
<bac> one non-controversial topic jml brought up (well i brought it up on his behalf) was having reviewers land community contribution branches
<thumper> seems reasonable
<bac> it seems there are a few people (jml being one) who get pinged to land stuff
<mwhudson> well that sounds sensible yes
<bac> so we formalized the informal idea that the reviewer is to assume he'll be landing the branch
<mwhudson> ok
<bac> and if the reviewer cannot then whoever is OCR at the time should consider it part of their duties
 * thumper nods
<bac> i'll be adding something to summarize that to the wiki
<bac> other than wgrant do you have other contributors in your time zone?
<thumper> not that I know of
<thumper> bac: but we may end up working with some americans
<mwhudson> we sometimes get us folks in their evenings
<thumper> bac: as it is only 3h to pacific time
<mwhudson> nothing regular though
<bac> ah, right
<bac> that topic led to the issue of 'ec2 land' having a 3-4 hour window where unreviewed and untested code can be pushed to LP and pqm will happily land it
<bac> we talked about solutions to that but nothing bubbled up to the top as a winner
<thumper> the solution is to finish off merge queues
<bac> the only risk-free way to do it is to get a copy of the branch for landing
<thumper> we record revision ids
<bac> thumper: and will that include integration with PQM?
<thumper> bac: getting a copy is safe for now
<mwhudson> oh right yeah
<thumper> bac: we'll move to tarmac I believe
<mwhudson> that really sucks :(
<bac> doing it manually is a bit of PITA, though
<thumper> bac: although integration with pqm isn't too hard
<thumper> yes
<thumper> perhaps we'll get the time to finish off merge queues
<bac> that'd be sweet.  in the interim we may need to look at some light tool support to make grabbing and landing a branch less painful
<bac> we've all become soft since 'ec2 land' is so easy now!
<thumper> agreed
<thumper> bac: or...
<mwhudson> i guess you could do ec2 land --community that would construct the arguments from the mp, copy the branch and then ec2 test -s that
<thumper> bac: we extend ec2 land to accept a revid
<bac> thumper: it needn't even do that.  it could just take the current one, right
<bac> thumper: but even then, there would still be the time it languishes in PQM as a window where new stuff could push
<thumper> bac: well, you'd still want the ability to specify it if an unreviewed revision has already been added
<bac> but i think just having ec2 not submit if the branch changed after it started it's work would be sufficient
<thumper> bac: agreed
<bac> i've meant to do that but just haven't gotten around to it
<bac> another topic
<bac> henning, abentley, and gavin brought up the fact that twisted uses lambdas a lot for defining callback functions
<bac> after some discussion we agreed to a "when in rome" approach and decided to relax our coding guidelines to allow lambdas for that purpose when dealing with twisted
<mwhudson> well yeah, the total lambda ban is a bit silly for this
<mwhudson> in fact i'm fairly sure there are some lambdas in the code already for callbacks...
<thumper> I agree with mwhudson
<bac> bigjools repeated his mantra of "let common sense prevail" and we moved on
<thumper> +1
<bac> bigjools also reminded everyone of the circular import patching helper.  i knew nothing about it so i was glad to learn about them
<bac> patch_return_type()
<bac> makes _schema_circular_blah more readable
<thumper> interesting
<thumper> hadn't heard of that, so also happy to learn
<mwhudson> ah worth knowin
<bac> i then got on a soap box to encourage reviewers to insist that API changes be tested via launchpadlib, even if only in an ad hoc fashion
<bac> which led us to talk again about getting launchpadlib tests in our test suite.  gary indicated it may be possible now and leonard is supposed to create some examples
<bac> there was much celebration
<thumper> I remember seeing a launchpad client in some test code
<thumper> I remember thinking that that seemed like a much more sensible approach than the webservice doctests
<bac> yeah, leondard had to write an approved way to get credentials without using the browser since people were making hacks to do it anyway.  while he didn't like the idea for real code it does allow us to use it for tests
<bac> i'm anxious to see this work.
<thumper> me too
<bac> that pretty much sums up our meeting.
<bac> do either of you have anything new to bring up?
<mwhudson> well, i don't think i have anything to disagree with this week then
<bac> darn
<bac> thumper you're generally good for some disagreement...
<mwhudson> i'm glad weekly chr is going away i think
<bac> yeah, me too
<thumper> I'm pretty happy right now, just tired
<bac> ok, well that's it then.  i've got to race off to another call
<mwhudson> ok, thanks bac
<bac> #endmeeting
<MootBot> Meeting finished at 15:56.
<thumper> thanks bac
<mwhudson> talk to you soon
<bac> see you next week...
#launchpad-meeting 2010-02-11
<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
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<Chex> here
<gary_poster> me
<abentley> matsubara, hello, my name is rockstar
<gary_poster> heh
<matsubara> hi abentley, welcome :-)
<abentley> (rockstar is not well)
<flacoste> me
<matsubara> just saw his email, thanks for standing in
<matsubara> bigjools, danilos, Ursinha, sinzui, allenap: hi
<bigjools> o/
<allenap> me
<matsubara> ok, let's move on while others can join in later
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara>  * DBA report (stub)
<matsubara>  * Proposed items
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>  * matsubara to email Tim about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA174 and
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1488EA174
<matsubara>     * Filed bug 520446 and emailed Tim about it.
<matsubara>  * matsubara to talk to leonard about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA884
<matsubara>     * Talked to leonard about this one, details added to bug https://bugs.edge.launchpad.net/launchpad-foundations/+bug/271029
<matsubara>  * rockstar to investigate OOPS-1480CMP1 and fill in details on bug 517126
<ubottu> Launchpad bug 520446 in launchpad-code "OOPS creating duplicate merge proposal using API" [Undecided,New] https://launchpad.net/bugs/520446
<matsubara>  * matsubara to ask stub to send the dba report to the list
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1488EA884
<ubottu> Launchpad bug 517126 in launchpad-code "BzrCheckError raised creating a merge proposal" [Undecided,New] https://launchpad.net/bugs/517126
<matsubara>     * emailed stub about this week and last week report (2010-02-11)
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1480CMP1
<matsubara>  * rockstar to raise the importance of ensuring sufficient monitoring of this part (i.e. branch updates emails failing to be delivered) of code-hosting by thumper
<ubottu> Ubuntu bug 271029 in launchpad-foundations "ForbiddenAttribute exception raised changing property of object" [Medium,Triaged]
<matsubara>  * Gary talk about "too many different kinds of moving parts" in our architecture. If we have fewer moving parts then we can institute more uniform nagios-like-checks.
<matsubara>  * Ursinha to talk to rockstar about bug 514461
<ubottu> Launchpad bug 514461 in launchpad-code "scan_branches.py screams and no one is listening" [Critical,Fix released] https://launchpad.net/bugs/514461
<matsubara>    * rockstar said: "yes, I have been trying to get it landed for a week.  If it got into production-stable, then I'm going to have it CP'd today (02/04)."
<matsubara>  * Ursinha to talk to mwhudson about bug 513412
<ubottu> Bug 513412 on http://launchpad.net/bugs/513412 is private
<matsubara> gary_poster, did you talk about your meeting action during the TLs meeting?
<gary_poster> matsubara: yes I did.  It is now in BjornT's hands to decide what, if anything, we do about it, I think
<Ursinha> matsubara: I talked to rockstar but not with mwhudson, sorry
<matsubara> gary_poster, ok, thanks for bringing that up
<matsubara> [action] * Ursinha to talk to mwhudson about bug 513412
<MootBot> ACTION received:  * Ursinha to talk to mwhudson about bug 513412
<ubottu> Bug 513412 on http://launchpad.net/bugs/513412 is private
<ubottu> Bug 513412 on http://launchpad.net/bugs/513412 is private
<matsubara> [action] * rockstar to investigate OOPS-1480CMP1 and fill in details on bug 517126
<MootBot> ACTION received:  * rockstar to investigate OOPS-1480CMP1 and fill in details on bug 517126
<ubottu> Launchpad bug 517126 in launchpad-code "BzrCheckError raised creating a merge proposal" [Undecided,New] https://launchpad.net/bugs/517126
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1480CMP1
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1480CMP1
<abentley> matsubara, it appears this was not completed.
<matsubara> it wasn't. I'm re-adding it to the meeting action items so I can bring it up again next week
<matsubara> I think that's it for actions from the last meeting
<matsubara> let's move on
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> abentley, I filed bug https://bugs.edge.launchpad.net/launchpad-code/+bug/520482
<ubottu> Ubuntu bug 520482 in launchpad-code "ValueError oops raised creating merge proposal with different values for review_types and reviewers" [Undecided,New]
<abentley> matsubara, rockstar did raise the oops issue with us.
<matsubara> ubuntu bug?
<abentley> matsubara, okay, is there something you want me to do about that bug?
<matsubara> abentley, could you please fill in the details in the bug report?
<matsubara> abentley, fill in the details about the oops rockstar discussed in the code team
<matsubara> about bug 520482, could you triage and get that one assigned?
<ubottu> Launchpad bug 520482 in launchpad-code "ValueError oops raised creating merge proposal with different values for review_types and reviewers" [Undecided,New] https://launchpad.net/bugs/520482
<matsubara> there's another one related to that bug 520446, which I emailed tim about today
<abentley> matsubara, sorry, I meant that rockstar raised the issue of monitoring emails.
<ubottu> Launchpad bug 520446 in launchpad-code "OOPS creating duplicate merge proposal using API" [Undecided,New] https://launchpad.net/bugs/520446
<matsubara> abentley, cool.
<abentley> matsubara, sure I can set the status high, but why do you believe it should be assigned immediately?
<matsubara> abentley, setting it to high and nobody taking ownership means it'll stay there forever
<matsubara> abentley, otoh, maybe it's not a big deal
<matsubara> although it's the second top oops on yesterday's lpnet report
<abentley> matsubara, no, it doesn't.  I have been working on high bugs this week and last.
<abentley> matsubara, and there are oops bugs that I think should be fixed before this one.
<matsubara> abentley, that's cool. setting it to triaged and some status according to your teams priority is already good enough for me, as long as those oopses don't fall through the cracks
<matsubara> gary_poster, any news about bug 450593?
<ubottu> Launchpad bug 450593 in launchpad-foundations "Still seeing non-informational DisconnectionErrors on login servers" [High,Triaged] https://launchpad.net/bugs/450593
<matsubara> still seeing some DE errors on lpnet summaries
<gary_poster> matsubara: I don't think that's the most up-to-date bug on this, but could be wrong.  I'll investigate for next mtg
<matsubara> gary_poster, and bug https://bugs.edge.launchpad.net/launchpad-foundations/+bug/403618 ? it's the top one on edge summaries. can we get someone assigned to fix that one?
<ubottu> Ubuntu bug 403618 in launchpad-foundations "Launchpad should return a 404 instead of ForbiddenAttribute OOPS" [High,Triaged]
<gary_poster> matsubara: ack
<gary_poster> will do
<matsubara> [action] gary_poster to check status on work for DisconnectionErrors (bug 450593) and assign bug 403618 to someone in foundations
<MootBot> ACTION received:  gary_poster to check status on work for DisconnectionErrors (bug 450593) and assign bug 403618 to someone in foundations
<ubottu> Launchpad bug 450593 in launchpad-foundations "Still seeing non-informational DisconnectionErrors on login servers" [High,Triaged] https://launchpad.net/bugs/450593
<ubottu> Launchpad bug 403618 in launchpad-foundations "Launchpad should return a 404 instead of ForbiddenAttribute OOPS" [High,Triaged] https://launchpad.net/bugs/403618
<matsubara> ok, that's all for oops
<matsubara> let's see the scripts and critical bugs
<matsubara> karma-updater failing again, which sinzui already replied to
<matsubara> checkwatches hung and killed by spm
<matsubara> allenap, is someone chekcing that checkwatches issues? can you reply to the email spm sent to the list?
<allenap> matsubara: I haven't seen that message, unless it was some time ago?
<matsubara> allenap, my email client says spm sent his email 11 hours ago
<matsubara> allenap, subject	Re: Scripts failed to run: loganberry:karma-update, loganberry:allocate-revision-karma, loganberry:launchpad-stats, loganberry:expire-questions, loganberry:checkwatches, loganberry:productreleasefinder, loganberry:update-cache, loganberry:launchpad-targetnamecacheupdater
<allenap> matsubara: Cool, found it. I'll reply.
<matsubara> thanks allenap
<matsubara> we have 5 critical bugs
<matsubara> 3 fix committed and 2 triaged
<matsubara> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/511567
<ubottu> Ubuntu bug 511567 in launchpad-foundations "Can't remove authorised oauth tokens" [Critical,Triaged]
<matsubara> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/514267
<ubottu> Ubuntu bug 514267 in launchpad-foundations "InternalError on clusters under busy load" [Critical,Triaged]
<matsubara> the latter one seems to be in progress
<matsubara> gary_poster, and the former one doesn't seem critical. is it really?
<gary_poster> matsubara: no.
<matsubara> ok. set to high then. IIRC, Curtis had a branch to fix that one
<matsubara> I'll assign to him
<gary_poster> ah ok, thanks
<matsubara> ok, thanks everyone. let's move on
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Chex> hello everyone
<Ursinha> wq
<Ursinha> oops, sorry :/
<Chex> - New branch-scanner setup again with 8944 CP; seems to be working well now.
<Chex> - DB Relication Lag/Slave-master issue: We are still running on the fake lag script pointing all traffic at the main
<Chex>         production db.  It appears as though we are blocked on Stuart's return before any progress is likely to be made
<Chex>         on this.
<Chex> - LP incidents of note:
<Chex>         ; LP Cherry-picks: 8944 to Codehost; loganberry bzrsyncd on 08-Feb,
<Chex>             CP 8945; rolled out to: germanium/ppa respectively on 10-Feb
<Chex> anyone have questions/comments on this?
<matsubara> thanks Chex
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> I emailed stub to sent the DBA report to the list
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> no new proposed items
<matsubara> anything else before I close?
<sinzui> yes
<matsubara> go ahead sinzui
<sinzui> http://people.canonical.com/~lpqateam/test-plan-report-10.02.html
<sinzui> ^ Is every team looking at this every day?
<MootBot> LINK received:  http://people.canonical.com/~lpqateam/test-plan-report-10.02.html
<abentley> sinzui, no idea.
<jtv> sinzui: cool, I wasn't aware of that one... will there be a single link for the current milestone?
<sinzui> matsubara: I moved some contributor landings from other testplans listed on to the wiki to my teams wiki page because I was tracking the bug on my teams milestone...there is a disconnect between where the wiki entry is and the qa-needtesting bug tag
<sinzui> jtv: I added the link to milestones I watch so that I am reminded of this: https://edge.launchpad.net/launchpad-registry/+milestone/10.02
<matsubara> sinzui, what do you mean by disconnect between the wiki entry and the qa-needstesting tag?
<jtv> sinzui: I hope this will become fully LP-native at some point, it's very cool!
<matsubara> sinzui, AFAICT, only translations is using the qa-needstesting tag
<Ursinha> sinzui: that happens because the scripts track the committers and not the teams
<sinzui> matsubara: jpds's bugs are on ^ my milestone page, but his entries are added to a different wiki page tan my entires, so I must hunt for them
<matsubara> sinzui, you mean LaunchpadTestPlan wiki page?
<bigjools> that will get even more disconnected as we do more feature-based teams
<sinzui> We agreed we would all use them starting in 10.02
<Ursinha> sinzui: so if henninge commits a fix for a bug in registry, it will show up in translations test plan
<matsubara> that's because external contributors don't have a team
<matsubara> they work on whatever they want
<sinzui> matsubara: correct
<abentley> jml is showing up under code team, but he isn't part of that team anymore.
<sinzui> Ursinha: Correct
<matsubara> so, that's why they end up in the LP test plan wiki page
<Ursinha> matsubara: correct :)
<matsubara> do I get a A+ for all the above correct answers?
<Ursinha> sinzui: this can be changed if needed, it's just a matter of thinking about how
<Ursinha> matsubara: :)
<sinzui> I would prefer to never visit the wiki. I need to visit the wiki to prove QA is being done
<jml> please give me my own page! :)
<Ursinha> sinzui: I'm working on it
<bigjools> jml: would it have anything on it?  /me hides
<Ursinha> sinzui: and I thought that the migration would be done after all possible problems pointed in the experiment being fixed
<sinzui> actually, jml and mrevell do need a page
<sinzui> or something that makes it easy to see that they have verified their work this cycle
<sinzui> I do not think mrevell knows he has lots of entries hidden on a page from last release
<matsubara> [action] Ursinha to set up StrategyTeamTestPlan wiki for jml,mrevell
<MootBot> ACTION received:  Ursinha to set up StrategyTeamTestPlan wiki for jml,mrevell
<mrevell> sinzui, Hidden entries?
<matsubara> sinzui, I usually remind him
<Ursinha> sinzui: if you're talking about the Launchpad testplan, we usually poke him for that
<matsubara> but it's better if the strategy team has their own TP
<matsubara> hi mrevell  :-)
<Ursinha> matsubara: sinzui, that would be easy to do
<Ursinha> but the idea is to get rid of wikis, right?
<mrevell> hey matsubara, I'll talk to you outside the meeting
<sinzui> mrevell: https://dev.launchpad.net/LaunchpadTestPlan/10.01
<Ursinha> I thought there was an agreement on it! Or maybe I got it wrong
<Ursinha> I'll set up the page for them to use while we don't migrate
<abentley> kanban is also supposed to be tracking QA.  Do we have a plan to keep everything in sync?
<matsubara> Ursinha, we will get rid of the wiki once the work on bug tagging is done. if that's not ready yet, my suggestion is to create the wiki page for jml and mrevell so they will be able to track the QA needed for their work
<matsubara> kanban too?
<matsubara> that's new to me
<Ursinha> so to me
<sinzui> abentley: BjornT will be working on syncing via API
<Ursinha> ah
<Ursinha> ok
<sinzui> abentley: BjornT wants every change in LP sent to the kanban boards
<matsubara> oh
<matsubara> Ursinha, I guess you'll need to talk to BjornT then
<matsubara> before working on the qa tagging thing
<mrjazzcat> matsubara: or me :-)
<Ursinha> matsubara: actually no
<Ursinha> matsubara: well, he's going to perform a search on bugs with tags and yada
<Ursinha> matsubara: I'll talk to him to confirm that :)
<matsubara> my point exactly :-)
<matsubara> anyway, sinzui, do you have anything else?
<sinzui> matsubara: no
<matsubara> thanks. as a general reminder, please try to keep an eye on the test plan report page for the current cycle, and spread the word to your teammates: http://people.canonical.com/~lpqateam/test-plan-report-10.02.html
<matsubara> I think that brings the meeting to an end
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:51.
<Ursinha> thanks matsubara
<abentley> thanks matsubara.
<mwhudson> Ursinha: i can't see that bug you're supposed to talk to me about
#launchpad-meeting 2018-02-09
<ZQ0O1Ztarget> ââââââââââ  âââââââ   âââââââââââ   ââââââââââ âââââââââââââââ ââââ   ââââââââââââââââââââââââââââ    âââââââ âââââââ  âââââââ
<ZQ0O1Ztarget> âââââââââââââââââââ   âââââââââââ   ââââââââââââââââââââââââââââââââ  ââââââââââââââââââââââââââââ   âââââââââââââââââââââââââ
<ZQ0O1Ztarget> ââââââââââââââ        âââââââââââ   âââââââââââââââââ  ââââââââââââââ âââââââââ     âââ   ââââââââ   âââ   ââââââââââââââ  ââââ
<ZQ0O1Ztarget> ââââââââââââââ        âââââââââââ   ââââââââââ ââââââ  ââââââââââââââââââââââââ     âââ   ââââââââ   âââ   ââââââââââââââ   âââ
<ZQ0O1Ztarget> ââââââ  ââââââââââââââââââââââââââââââââââ     âââââââââââ  ââââââ ââââââââââââââ   âââ   âââââââââââââââââââââââ  ââââââââââââ
<ZQ0O1Ztarget> ââââââ  âââ ââââââââââââââââââ âââââââ âââ     âââââââââââ  ââââââ  âââââââââââââ   âââ   âââââââââââ âââââââ âââ  âââ âââââââ
