#launchpad-meeting 2008-01-23
 * gmb dashes to get tea before the meeting.
 * statik does too
 * sinzui grabs a pot of coffee.
 * intellectronica just pops some amphetamines
 * sinzui hunts for some meth
 * danilos grabs a sandwich, a bottle of rakia, and asks the girl in the bar to give him a lap dance
 * barry goes to visit danilos
<intellectronica> danilos: rakia, is that like raki - the anise drink?
<barry> #startmeeting
<MootBot> Meeting started at 15:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everyone and welcome to this week's ameu reviewer meeting
<barry> who's here today?
<sinzui> me
<gmb> me
<danilos> intellectronica: http://en.wikipedia.org/wiki/Rakia ;)
<intellectronica> me
<danilos> me
<bac> me
<statik> me
<allenap> me
<barry> welcome danilos and allenap!
<bac> welcome allenap!
<allenap> cheers :)
<danilos> thanks
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<danilos> allenap: are you a new recruit? :)
<barry> * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>    * allenap mentored by bac
<barry>    * bigjools mentored by barry
 * flacoste hi-5 allenap and danilos
<barry>  * Review process
<barry>    * on-callers use PendingReviews?
<barry>    * SteveA (or barry), use of properties instead of `__call__` in TALES
<allenap> danilos: Yep, you?
<barry>    * SteveA (or barry), use of raw strings for regexps only
<barry>    * Tool update
<barry>  * On-call reviews
<barry>    * Keeping the time to around 8 hours
<barry> it's a full one today, so let's jump right in!
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
 * bigjools is here
<barry> bigjools: welcome!
<danilos> allenap: yep
<bigjools> thanks!
<danilos> bigjools: hi, welcome as well :)
<bigjools> backatcha danilos
 * flacoste cheers bigjools
<barry> a bunch of us are going to be in florida sprinting next week. should we still have the meeting or skip it?
 * bigjools high fives flacoste
<statik> i'd like to skip it
<flacoste> +0
<barry> statik: me too
<bac> +1 on skipping
<sinzui> -1
<barry> [VOTE] skip the meeting next week?
<MootBot> Please vote on:  skip the meeting next week?.
<MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
<MootBot> E.g. /msg MootBot +1 #launchpad-meeting
<MootBot> -1 received from sinzui. 0 for, 1 against. 0 have abstained. Count is now -1
<danilos> -1 (I'll be here, not that I don't want you to skip it :)
<MootBot> -1 received from danilos. 0 for, 2 against. 0 have abstained. Count is now -2
<statik> +1
<flacoste> +0
<MootBot> +1 received from statik. 1 for, 2 against. 0 have abstained. Count is now -1
<MootBot> Abstention received from flacoste. 1 for, 2 against. 1 have abstained. Count is now -1
<barry> +1
<MootBot> +1 received from barry. 2 for, 2 against. 1 have abstained. Count is now 0
<bac> +1
<MootBot> +1 received from bac. 3 for, 2 against. 1 have abstained. Count is now 1
<statik> +1
<bac> cheater
 * statik couldn't resist trying to cheat
<barry> /msg mootbot stop cheaters!
<flacoste> statik: i think i have a game for you...
<barry> any other votes?
<barry> 5
<barry> 4
<barry> 3
<bigjools> +0
<MootBot> Abstention received from bigjools. 3 for, 2 against. 2 have abstained. Count is now 1
<barry> 2
<barry> 1
<barry> #endvote
<flacoste> [ENDVOTE]
<danilos> does that still not work?
<barry> /msg mootbot fix yourself already!
<bac> changing topic should end it, too
<danilos> (it ends when the meeting is done, that happened last time)
<barry> okay, we're split, so i rule :)
<barry> [AGREED] skip the meeting next week
<MootBot> AGREED received:  skip the meeting next week
<barry> [TOPIC] action items
<MootBot> Vote is in progress. Finishing now.
<MootBot> Final result is 3 for, 2 against. 2 abstained. Total: 1
<MootBot> New Topic:  action items
<intellectronica> barry: all of us, or only the florida sprint participants?
<flacoste> barry: we're not splitted, 3 for, 2 against, 2 abstentions
<barry> flacoste: statik cheated
<barry> intellectronica: everyone, but i won't stop you from meeting if you want :)
<flacoste> barry: but his cheat didn't work
 * barry shamefully unwields his power
<barry> flacoste: great! then motion carried
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<bigjools> meta argument alert :)
<barry> bigjools: do you want the floor?
 * bigjools humbly disappears
<intellectronica> i promised to create a cover letter and integrate it with the submission plugin. i have created a cover letter and am hacking on using it interactively from the plugin today
<barry>  * intellectronica to work on a cover letter template (wait for mwh)
<barry> intellectronica: awesome!
<intellectronica> should be ready for when mwh is back in business
<flacoste> intellectronica: you could put it out on the wiki
<flacoste> that way we could edit/improve it
<flacoste> and use it by pasting it in our editor
<barry> flacoste: +1
<danilos> I was personally having problems using lpreview plug in with my set-up (which pre-dates all the rocketfuel-get scripts and similar)
 * flacoste used the plugin for the first time yesterday
<flacoste> didn't work too great :/
<danilos> flacoste: I've had the same experience
<flacoste> i reported my feedback to the list
<flacoste> danilos: did you?
<barry> danilos: my setup predates th rf-get scripts and i've had fairly good luck with the script
<bigjools> it should be registered in LP so we can track bugs
<danilos> flacoste: no, I'll certainly do that
<barry> bigjools: +1
<allenap> danilos: Same for me as for barry, except that it tries to find the paste script in the wrong place.
<danilos> +1 from me as well
<sinzui> I always write my cover letter and make my diff separate from the plugin--I think it is faster, and safer.
<barry> utilities/paste doesn't work for me though
<flacoste> sinzui: i'll take your advice!
<flacoste> i did for the diff, but not the cover letter
<bigjools> barry: why not?
<flacoste> but losing it twice, is kind of sucky
<barry> sinzui: i usually write my cover separately but let the plugin do the diff
<flacoste> barry: that's because your missing the magic password file
<bac> flacoste: did you check to see if "cover.txt" actually exists?
<barry> bigjools: i get some error output and no paste
<barry> flacoste: no, i have that!
<danilos> I had to do both manually
<flacoste> bac: oops, right, it does!
<barry> but maybe we can debug that off-line (it's low priority for me)
<bigjools> ok
<bac> flacoste: i've documented that on the wiki
<flacoste> yeah, i lured us off-topic, sorry
<allenap> bac: Do you have a link for that?
<barry> mwh is off-line.  gmb, in the meantime would you register the plugin on LP?
<bac> https://launchpad.canonical.com/LPReviewPluginDocs
<gmb> barry: Sure. Should I register two separate products, one for the webapp, too, or do you think that can wait?
<allenap> bac: Thanks.
<barry> gmb: i think that can wait (and should be separate when it's time)
<gmb> Okay. Will do.
<barry> [ACTION] gmb to register lpreview plugin on lp so we can track bugs
<MootBot> ACTION received:  gmb to register lpreview plugin on lp so we can track bugs
<barry> moving on... :)
<barry>  * barry will communicate the on-call process to launchpad developers
<barry> done, though there is discussion about some details (which we'll get to later)
<barry>  * barry will contact devs who have previously expressed an interest in revieweing
<danilos> obviously done, hi bigjools, allenap :)
<barry> done, and welcome new recruits! :)
 * bigjools waves
<barry>  * gmb to work on the review web site next week (hopefully)
<bigjools> schwuk wanted to start too, what happened to him?
<barry> bigjools: i think he's looking for a mentor
<bigjools> ok
 * allenap drowns, no, waves
<gmb> barry: No work done yet. I'm hoping to get some time tomorrow and Friday.
<gmb> Too many other things are taking priority at this point.
<barry> gmb: understood! np, thanks for the update.
<barry>  * sinzui to look into running `make lint` and output PR stanza by default in `review-submit`
<sinzui> I did not act on that one.
 * sinzui looks at his shoes
<bigjools> PR begone
<barry> sinzui: np, should we just carry that over?
<sinzui> I considered updating the plugin to generate the PendingReview fragment, Since I do no know the URL of the cover letter before it is archived, I don't see much point in the effort.
<flacoste> sinzui: there is --pr option to generate the fragment already
<intellectronica> flacoste: is that not for creating a paste with the diff, actually?
<flacoste> intellectronica: no, it outpus something you can paste in PR
<flacoste> outputs even
<flacoste> even though PR stuff could be linked to pus
<sinzui> flacoste: It doesn't have the cover letter link
<barry> :-D
<flacoste> sinzui: hmm, i thought that was simply because the paste fails
<flacoste> because of path problems
<barry> well, gmb is gonna kill of PR soon enough anyway <wink> so maybe that's not the biggest bang for the buck
<flacoste> but that may be a wrong assumptions
<sinzui> I will look into this in more detail
<barry> sinzui: i think 'make lint' could be pretty useful tho
<sinzui> Faster gmb, kill, kill!
<bigjools> gmb will be my new best friend when he kills PR
<sinzui> barry: I will work on lint first.
 * gmb needs little encouragement
<intellectronica> gmb: now if that's not an incentive i don't know what is
<barry> sinzui: excellent, thanks
<bigjools> yes, please lint it as part of review-submit
<gmb> :)
<barry>  * barry will require `bzr review-submit` with exceptions.
<barry> done
<barry> (in the sense that i emailed that policy)
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
<barry> there are still a few long standing items in the queue over the sla
<barry> i know stub's branch that jtv is reviewing will just take a while
<barry> i'm not sure what the status is of adeuring's branch w/ jamesh
<barry> gmb, salgado, BjornT what are the statuses of your older branches?
<jtv> barry: stub's branch is also not completely finished yet.
<intellectronica> barry: there's another branch of stub which danilo and i decided not to touch for now, since it a zope branch. i think stub should make arrangements for someone to review it
<barry> jtv: should it be moved to work-in-progress then?
<barry> intellectronica: is that stub/zope/devel?
<jtv> barry: I'm not sure it matters much at this stage, it's an "interactive" review.
<intellectronica> barry: BjornT is absent today, he's in meetings
<gmb> barry: The needs-review* one is actually now a wip, I think, due to a discussion with mpt. I'll talk to abently about it later today.
<intellectronica> barry: yes, that's the one
<barry> jtv: okay, cool
<flacoste> intellectronica: there is nothing in it!
<intellectronica> flacoste: in that case, i don't mind reviewing it
<barry> intellectronica: rs'ing it even :)
<barry> gmb: thanks
<barry> gmb: feel free to move it to wip if that's what it is
<gmb> Sure.
<barry> any other comments about the current queue?
<sinzui> I think should remind developers to clear their merged branches  from PendingReviews.
<barry> sinzui: good point
<gmb> sinzui: +1
<barry> [ACTION] barry will remind developers to clear merged branches from PR
<MootBot> ACTION received:  barry will remind developers to clear merged branches from PR
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry>    * allenap mentored by bac
<barry>    * bigjools mentored by barry
<barry> we have new victim^H^H^H^H^H^Hrecruits... yay!
<barry> and hopefully one more for next cycle
<gmb> Cool. Even more on-call coverage.
<bigjools> I am not starting until Feb 4 though
<bac> i would like to talk to someone off-line about how mentoring and on-call work.
<barry> if anybody feels like they could mentor someone, let me know
<barry> bac: maybe we can chat about that next week f2f?
<barry> bigjools: yep
<bac> barry: good idea
<barry> also, any mentors who feel their recruits are ready to graduate, please let me know
<bigjools> and I am on leave the following week :)
<barry> bigjools: cool.  just means more piling up for you when you get back :)
<bigjools> barry: in more ways than you can imagine
<barry> moving on because we only have 15 minutes and lots more to cover :/
<barry> [TOPIC] review process
<MootBot> New Topic:  review process
<barry> i'll do the quick ones first (hopefully)
<barry>    * SteveA (or barry), use of properties instead of `__call__` in TALES
<barry>    * SteveA (or barry), use of raw strings for regexps only
<barry> steve asked me to communicate two coding policies, if we all agree
<barry> i'll bring these up on the m.l. but briefly...
<barry> we want to discourage __call__ in TALES in favor of properties
<barry> and we want to discourage the use of raw strings for anything except regexp patterns
<barry> does anybody not know what those mean?
<allenap> barry: Can you explain the reasons?
<barry> allenap: i think it's a consistency thing and easy of reading for #1
<barry> for #2, steve observed cargo culting of raw strings in places where they weren't needed
<flacoste> i'm all for #2
<intellectronica> barry: actually, there's a more important reason for #1
<barry> so suggested that devs may not understand what raw strings are for
<danilos> if we're ever to go into localising launchpad, we'll have to get more raw strings in views (as compared to page templates)
<barry> and suggested that a good rule of thumb is to always use them for regexps and never for anything else
<flacoste> and i usually don't mind #1
<intellectronica> because of the way zope traverses in expressions
<sinzui> barry: +1
<barry> (although it would be good to explain why raw strings are in python of course)
<barry> intellectronica: go ahead...
<intellectronica> zope traverses properties, but stops at the result of a method call
<barry> danilos: we can cross that bridge when we get there :)
<flacoste> actually
<intellectronica> so my_object/my_property/an_attribute is fine
<danilos> other than that, parsing specially formatted textual files like PO files requires a lot of hard-coded strings as well
<intellectronica> but my_object/result_of_method_call/an_attribute doesn't work
<flacoste> i think what #1 is about is not to use method call in TALES
<danilos> flacoste: that's how I read it as well
<intellectronica> oh, in that case i don't understand
<barry> danilos: exceptions are okay, if you really need them, but reviewers should scrutinize raw string usage carefully
<flacoste> because TALES will always implicitely call the end result
<flacoste> that's why there is no nocall: expression
<danilos> barry: ok, point taken, we should probably take the discussion on-list
<barry> danilos: +1
<bac> barry: are you proposing raw strings used nowhere but regex AND regex must use raw strings?  or just the former?
<barry> [ACTION] barry to take raw string coding standard to the ml
<MootBot> ACTION received:  barry to take raw string coding standard to the ml
<barry> bac: both
<barry> intellectronica: would you like to bring up the __call__ thing on the ml?
<intellectronica> barry: if flacoste is right then i have no idea what it's about - i rather have someone else clarify first
<danilos> btw, does the no string rule include docstrings? ;)
 * danilos runs away...
<barry> intellectronica: okay.  i'll ask SteveA to do it since he brought it up :)
<barry> danilos: we'll take that to the ml
<barry> moving on since i really want to get to sinzui's item
<barry>    * on-callers use PendingReviews?
<sinzui> \o/
<barry> i just want to take a quick vote and we can discuss more on the ml
<barry> [VOTE] do you as an on-caller want to use PR +1 or not -1?
<MootBot> Please vote on:  do you as an on-caller want to use PR +1 or not -1?.
<MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
<MootBot> E.g. /msg MootBot +1 #launchpad-meeting
<flacoste> +0
<MootBot> Abstention received from flacoste. 0 for, 0 against. 1 have abstained. Count is now 0
<barry> +1
<MootBot> +1 received from barry. 1 for, 0 against. 1 have abstained. Count is now 1
<bac> -0
<bigjools> -1
<gmb> -1
<MootBot> -1 received from bigjools. 1 for, 1 against. 1 have abstained. Count is now 0
<MootBot> -1 received from gmb. 1 for, 2 against. 1 have abstained. Count is now -1
<bac> +0
<MootBot> Abstention received from bac. 1 for, 2 against. 2 have abstained. Count is now -1
<intellectronica> +1
<MootBot> +1 received from intellectronica. 2 for, 2 against. 2 have abstained. Count is now 0
<danilos> -1 (when I'm provided with enough of the relevant information)
<MootBot> -1 received from danilos. 2 for, 3 against. 2 have abstained. Count is now -1
<sinzui> +0
<MootBot> Abstention received from sinzui. 2 for, 3 against. 3 have abstained. Count is now -1
<statik> +0
<MootBot> Abstention received from statik. 2 for, 3 against. 4 have abstained. Count is now -1
<barry> cool, thanks for the feedback
<intellectronica> i think that while PR sucks, the solution is to replace it with something better, not to give up on tracking reviews
<bigjools> I would like to point out that the whole point of on-call is to speed up reviews after the Lean training suggested we do 1-day branches.  If PR is needed for tracking, the branch is too big to do an on-call.
<gmb> bigjools: Agreed.
<intellectronica> bigjools: not so. unless there's exceptional load, almost everything can be done on call
<bigjools> also true - so anything requiring PR is too big...
<bac> yes, if a branch is handled during the on-call day, then no need for PR.  throw it in PR if size of the branch or problems lead to it not being completed during the cycle.
<barry> btw, i like it mostly for the pending-reviews page
<barry> okay, sorry to cut this short.  we'll continue discussion on the ml.
<barry> [TOPIC]  * On-call reviews
<MootBot> Vote is in progress. Finishing now.
<MootBot> Final result is 2 for, 3 against. 4 abstained. Total: -1
<MootBot> New Topic:   * On-call reviews
<barry>    * Keeping the time to around 8 hours
<barry> sinzui: you have the floor, 3 minutes :)
<sinzui> bigjools: Not necessarily. I am a slow reviewer. 600 lines is 3h for me. If you want something reviewed near the end of my day, I may need to take that branch up another day.
<bigjools> sinzui: if it's near the end of the day, I don't submit for review
<barry> sinzui: don't accept big branches near the end of your day
<sinzui> Without PendingReviews, YOU would have to sit on your branch until another on-call reviewer is available. We also have a practice of reassigning branches at the end of the day.
<danilos> sinzui: wasn't this about on-call reviews and not about non-on-call reviews? i.e. if you are not using on-call, you just put it onto PendingReviews
<barry> sinzui: i thought you were going to mention that you spend 20 hours doing reviews last week
<sinzui> barry: It's not that simple, Some branches arrive, and run out to be needs-reply, and a conversation in IRC is not going to fix that
<barry> sinzui: true
 * sinzui appologises for the confusion, I was actually responding to a remark on IRC /before/ I was given the floor.
<barry> well, we've run out of time.  sinzui can we take this to the ml?
<barry> sorry about that :(
<sinzui> I will
<barry> sinzui: thanks!
<barry> #endmeeting
<MootBot> Meeting finished at 15:46.
<barry> thanks everyone
<bigjools> thanks barry
<intellectronica> thanks barry
#launchpad-meeting 2008-01-24
<statik> oi
<mrevell> me
<carlos> me
<gmb> I think some peoples' clocks are running a touch on the slow side...
<mthaddon> me
<gmb> kiko, SteveA, Rinchen: Meeting time?
<sinzui> Time is an illusion.
<gmb> Lunchtime doubly so.
<barry> time is a corportist plot
<kiko> hello hello
<kiko> welcome to the launchpad meeting
<intellectronica> me
<kiko> and hmm how does one drive this bot!
<kiko> hang on first ;)
<kiko> okay, got some docs up
<kiko> #startmeeting
<MootBot> Meeting started at 14:04. The chair is kiko.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<leonardr> me
<kiko> so who is here this week, apart from leonardr?
<SteveA> me
<allenap> me
<mpt> me
<gmb> me
<jt1> me
<barry> me
<matsubara> me
<kiko> me
<bigjools_> me
<jamesh> me
<intellectronica> me
<bac> me
<sinzui> me
<schwuk> me
<statik> me
<EdwinGrub> me
<mthaddon> me
<salgado> me
<EdwinGrubbs> me
<jtv> me
<adeuring> me						
<mrevell> me
<BjornT> me
<carlos> me
 * kiko looks for danilos, cprov 
<kiko> SteveA, and stub?
<jtv> danilos is off today
<cprov> me
<kiko> hey mthaddon, glad you could make it
<mthaddon> hey kiko
<kiko> very well
<kiko> Rinchen is out because he pulled an all-nighter
<kiko> and that means you get me as your most charming host today
<kiko> so let's move on. that was the roll call!
<SteveA> kiko: I already said "me"
<kiko>     *
<kiko>       Roll call
<kiko>     *
<kiko>       Agenda
<kiko>     *
<kiko>       Next meeting
<kiko>     *
<kiko>       Actions from last meeting
<kiko>     *
<kiko>       Oops report (Matsubara)
<kiko>     *
<kiko>       Critical Bugs (Rinchen)
<kiko>     *
<kiko>       Bug tags
<kiko>     *
<kiko>       Operations report (mthaddon)
<kiko>     *
<kiko>       DBA report (stub)
<kiko>     *
<kiko>       Sysadmin requests (Rinchen)
<kiko>     *
<kiko>       A top user-affecting issue (mrevell)
<kiko> SteveA, sure, but stub didn't.
<kiko> and to wrap that up, Blockers
<kiko> TOPIC next meeting
<SteveA> I recommend pasting from the raw text of the wiki page.
<kiko> oh bar
<mpt> ahem
<kiko> [TOPIC] next meeting
<flacoste> me
<MootBot> New Topic:  next meeting
<kiko> hello there
<flacoste> sorry for being late
<kiko> SteveA, I'm not very good at this :-)
<kiko> so for next meeting, same time, same place? who's here, who's not?
<kiko> I'll be here.
<SteveA> I'll be at a sprint in cocoa beach, along with the foundations and lpcomm teams
<SteveA> I expect we'll still make the meeting
<flacoste> foundations and commercialization will be sprinting
<kiko> so confirming, sprinters will make the meeting?
<flacoste> yeah
<kiko> great
<kiko> anyone on vacation? jtv -- danilos? SteveA -- stub?
<jtv> kiko: yes, danilos is off today (see above)
<mpt> I'm in another meeting right now and I'm attending this meeting
<kiko> jtv, I meant next week, sorry.
<SteveA> stub should be here
<mpt> so attending a sprint is no excuse :-)
<SteveA> I'll give him a buzz
<kiko> [AGREED] meeting next week, same time, thursday. sprinters should make it. no other absentees forseen.
<MootBot> AGREED received:  meeting next week, same time, thursday. sprinters should make it. no other absentees forseen.
<kiko> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<kiko> mthaddon, first topic is whether https://staging.launchpad.net/successful-updates.txt has been linked to from somewhere.
<SteveA> stub is having network problems
<SteveA> he's working on fixing it
<kiko> second topic is whether launchpad-dependencies was updated by salgado
<mthaddon> kiko, not currently - I have a script on devpad that checks it and emails me if it's not completed in the last 24 hours, which I will now change to email the launchpad list
<kiko> third topic is whether salgado investigated putting launchpad-dependencies in /sourcecode -- or if at least a bug was filed.
<salgado> what's it about the update?
<kiko> mthaddon, okay, great. can we link to successful-updates.txt at least from LaunchpadProductionStatus, perhaps prominently?
<mthaddon> kiko, sure
<salgado> my box is half-crashed and I didn't see the beginning of the meeting
<salgado> (can't launch firefox either. am running xchat remotely)
<kiko> salgado, whether it was done or not -- I believe the answer is yes, to include lxml and that other one
<SteveA> salgado: using hardy?
<salgado> kiko, yes, even mhonarc has been included
<kiko> SteveA, no, it's diskless gutsy, long story.
<kiko> salgado, good job.
<kiko> salgado, I noticed that today you noticed a branch using a package that isn't required
<kiko> I think we need a process to have people preemptively request packages for inclusion
<salgado> that's actually from zope
<kiko> because otherwise it's always a mad scramble
<kiko> I see
<salgado> kiko, it's a problem with sys.path, it seems
 * SteveA quotes Ghostbusters: "Everything was fine until the grid was shut down by diskless here."
<stub> me
<kiko> quick poll: are people aware of the fact that they need to do something special if you want to require a new python (or otherwise) package? say yes if you know that you need to.
<kiko> yes
<statik> kiko: I think you have a good point there about packages, I've noticed that I have so many dev packages on my machine I don't feel confident I will notice if something new needs to be installed - this is why the lxml thing didn't affect me
<jamesh> "yes it is true.  This man has no disk"
<statik> yes
<bac> yes
<jtv> yes
<salgado> yes
<jamesh> yes
<cprov> yes
<EdwinGrubbs> yes
<sinzui> yes
<stub> yes
<adeuring> yes
<matsubara> yes
<SteveA> yes
<bigjools_> yes
<carlos> yes
<schwuk> yes
<barry> yes
<flacoste> yse
<mpt> n/a
<BjornT> yes
<leonardr> yes
<intellectronica> yes
<kiko> okay. so gmb and allenap don't know.
<stub> In theory, if we miss a required package branches that depend on it won't get through pqm
<gmb> Yes.
<gmb> I know.
<gmb> I'm lagged.
<kiko> while it's true that the branch won't get through PQM
<kiko> it's also true that that's too late and then we need to rush IS into installing stuff
<kiko> which might need to be backported -- see abel's issue with lxml one release ago
<carlos> kiko: are we still running dapper on production?
<kiko> carlos, yes.
<carlos> ok
<kiko> so how about we add this as a weekly topic, next to the "pending IS requests" topic? at least then people can think about it once a week.
<kiko> anyone opposed?
<intellectronica> is it common enough?
<jamesh> kiko: does that differ from pending RT requests?
<stub> The reason people don't think about it is that it is uncommon I think.
<flacoste> yeah, it's uncommon
<kiko> jamesh, there might not be an RT request for the package -- I want to make sure people are aware of it
<flacoste> it's just that three new dependencies were introduced in the last vcycle
<kiko> well, it's uncommon but still not that rare -- twice this cycle, for instance
<kiko> or 3 times
 * bigjools_ will have one too
<salgado> 4 new deps, but I actually did only two updates to the package
<stub> Spread over all our devs, that comes to once every 2-4 months an individual dev will do it.
 * sinzui suspected bigjools_ will have one
<kiko> it's harmless to have the topic and just say "no."
<stub> So a reminder such as in the meeting would be good.
<kiko> agreed.
<kiko> I'll amend the template. thanks! moving on..
<kiko> the last topic was about Rinchen and tim figuring out who can attend the meeting from down under
<kiko> I think it's really a big deal that australians/new-zealanders can't make the meeting
<kiko> and Joey and I have talked about changing the time to make it less depressing for mthaddon and more humane for australians
<schwuk> cycle the meeting times?
<kiko> however, that leaves us with the problem of being inhumane with jtv and stub and possibly danilo and BjornT
<barry> kiko: it's tough.  we have two reviewers meetings for this reason, with me attending the asiapac one at 10pm localtime
<kiko> barry, I know -- but we can't really have two meetings for launchpad, so rotation might be the best approach.
<stub> I'm happy to not turn up to meetings if it makes things easier :-)
<kiko> we're still talking about it
<kiko> thanks stub
<kiko> okay, that's all on this topic -- we'll talk about it again next week when Rinchen is awake
<kiko> so
<kiko> [ACTION] kiko to add the lp-dependencies question to the MeetingAgenda template
<MootBot> ACTION received:  kiko to add the lp-dependencies question to the MeetingAgenda template
<kiko> [ACTION] Rinchen and kiko to figure out how to manage lp-bzr's absence from the meeting; consider rotation or time-shift
<MootBot> ACTION received:  Rinchen and kiko to figure out how to manage lp-bzr's absence from the meeting; consider rotation or time-shift
<kiko> salgado, what about putting the package in sourcecode/ ?
<statik> isn't aaron on that team?
<kiko> statik, he is, and the fact that tim hasn't told him to come to the meeting kinda underlines my point. ;)
<salgado> kiko, as I said, I'm opposed to that, so I may not be the best person to move this forward
<kiko> tim doesn't even think about the meeting -- which means he misses out on OOPSes, policy changes, critical bug discussions, etc
<jamesh> aaron is in Sydney at the moment
<kiko> anyway
<kiko> topic for next week
<salgado> kiko, I didn't even notice this had been assigned to me during the last meeting
<kiko> hmph. okay, flacoste, can you figure that out later with salgado then.
<kiko> ?
<flacoste> kiko: yes
<kiko> moving along
<SteveA> point of information
<kiko> [TOPIC] Oops report (Matsubara)
<MootBot> New Topic:  Oops report (Matsubara)
<SteveA> I spoke with lifeless about putting our dependencies packages' source in sourcecode/ and he's very in favour of the idea
<SteveA> we discussed it at some length
<SteveA> end of POV
<kiko> thanks SteveA!
<SteveA> um, POI
<matsubara> I've setup a oops report for today updated every hour. The url is in #lp-code topic. I'm checking that often and following up with people on IRC about oops related to the rollout.
<matsubara> that's all from me. back to you kiko
<kiko> matsubara, that's a great change. I love it.
<Hobbsee> kiko: 1am is a perfect time for a meeting!
<statik> matsubara: that rocks
<kiko> matsubara, I reloaded today and was able to complain already about my favorite OOPSes.
<SteveA> matsubara: YES!  \0/
<stub> Hobbsee: That depends on how drunk you are allowed to be
<kiko> without even having to complain about there not being an OOPS report!!
<Hobbsee> stub: *grin*.  there is that
<kiko> matsubara, any OOPSes outstanding you'd like us to nitpick?
<matsubara> kiko: not really an OOPS, but a critical one that I found while testing +editemails. I can tell you details on #lp-code
<stub> On this topic, it would have been nice if we noticed a significant drop in timeout oopses after turning on the BBWC but I couldn't see anything particularly noticeable.
<kiko> matsubara, yeah. so all OOPSes from today's report are being addressed already? give us at least a list so we don't double-check.
<SteveA> stub: are we sure it's turned on?
<matsubara> kiko: I'm still checking the +editemails one.
<stub> SteveA: I have no way of confirming except to ask the admins.
<matsubara> kiko: the soyuz queue one is on bigjools plate
<mthaddon> stub, that's a pity - I feel like the site is a little quicker to render pages, but I may be kidding myself
<bigjools_> IME, bbwc only improves latency, not throughput
<matsubara> and jamesh will prepare a patch for the openid one
<mthaddon> SteveA, we're sure it's turned on
<kiko> okay, thanks!
<stub> bigjools_: I hate hardware
<SteveA> mthaddon: is it something that is turned on for all disks/partitions, or just ones we choose?
<kiko> mrevell, do you have input for critical bugs? or should I skip that topic?
<bigjools_> stub: aye
<mthaddon> SteveA, just for the ones we choose (well, that ones that have it available)
<mrevell> kiko: I think matsubara does
<kiko> mrevell's pinging out, so I'm skipping that.
<kiko> oh, really?
<kiko> [TOPIC] critical bugs (matsubara?)
<MootBot> New Topic:  critical bugs (matsubara?)
<matsubara> kiko: no critical ones from Rinchen. The only one is the private one I told you earlier
<kiko> thanks matsubara
<kiko> [TOPIC] bug tags
<MootBot> New Topic:  bug tags
<matsubara> and the soyuz pubkey which bigjools fixed
<bigjools_> I need r-c for that
<kiko> no proposed tags this week, so moving on
<kiko> my favorite topic now!
<kiko> [TOPIC] Operations report (mthaddon)
<MootBot> New Topic:  Operations report (mthaddon)
<mthaddon> 1.2.1 released
<mthaddon> Have some documentation updates following the release, and expecting a "second" rollout today or tomorrow
<mthaddon> Er, not much more to say from me (except for known PPA issue)
<kiko> hoping we can do that late today
<mthaddon> not too late I hope...
<kiko> but that depends mostly on getting the OOPSes fixed today
<kiko> matsubara, are they going to get fixed today?
<mthaddon> sorry, I meant the slave_scanner issue
<kiko> sure.
<kiko> thanks!
<kiko> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<stub> Do we know that we will need to do a second rollout the following day before  the OOPS reports come in? If so, should we consider letting rollout times slip by a day or three to improve overall reliability?
<stub> (oops.... old topic. Must type fasteer)
<stub> Priority of replication has been bumped in favour of making LP more useful for auth by Landscape and other systems with similar use cases. We still need to proceed on replication, but the timeframe isn't as critical now given we are getting hardware upgrades.
<stub> Nothing else to report.
<SteveA> on the oops issue -- are these oopses ones we could have discovered on edge?
<SteveA> or by some other means, before the roll-out?
<kiko> SteveA, in the soyuz case, yes on at least one count.
<kiko> matsubara, what do you say of the others?
<matsubara> the openid one is quite old, it's not specific to the rollout
<matsubara> we couldn't find the soyuz config one because it's a specific lpnet config issue
<kiko> SteveA, the portlet-details one is on bounties, so... moving back on topic, though -- stub, okay. have you and SteveA re-discussed using carbon for the staging DB?
<matsubara> not sure yet about the +editemails one, but I think it's an old one as well
<SteveA> there are various discussions going on about shifting around hardware
<stub> Carbon for staging has been discussed via email. Carbon for staging won't be an option for long term as I have it earmarked for the first replica lp database.
<SteveA> however, we could use it in the mid term
<SteveA> particularly as you're shifting down the immediate priority of replication
<kiko> right, that's what I'm asking if we talked about.
<SteveA> kiko: this depends on various other discussions about hardware
<SteveA> kiko: so, it's still going on.
<kiko> SteveA, okay, thanks. please update us on this next week.
<SteveA> I expect a resolution in a week or so
<stub> It also depends on how soon landscape need two databases.
<kiko> [ACTION] SteveA and stub to discuss options for staging DB and report back
<MootBot> ACTION received:  SteveA and stub to discuss options for staging DB and report back
<kiko> [TOPIC] Sysadmin requests (kiko standing in for joey)
<MootBot> New Topic:  Sysadmin requests (kiko standing in for joey)
<kiko> anyone have any ones that they want done asap?
<bigjools_> I have RT #29797 which is blocked itself on packaging work
<kiko> any others?
<kiko> bigjools_, please ping me today so we talk that over
<bigjools_> sure
<kiko> [AGREED] RT 29797 priority for bigjools
<MootBot> AGREED received:  RT 29797 priority for bigjools
<kiko> [TOPIC] A top user-affecting issue (mrevell)
<MootBot> New Topic:  A top user-affecting issue (mrevell)
<mrevell> howdy
<mrevell> This week's issue deals with merging accounts. At present, it's not easy to find how to merge two accounts.
<mrevell> The fix for bug 30439 gave us the "Claim this account" link on profile pages.
<ubotu> Launchpad bug 30439 in launchpad "Link to page for merging accounts is well-hidden" [Medium,Fix released] https://launchpad.net/bugs/30439
<mrevell> However, for someone who is logged-in there's still no link to merge with another account.
<mrevell> At least, no link on the profile page.
<mrevell> Support requests suggest that we could make this easier to find.
<mrevell> I've reported bug 185486 in response to the most recent help request on this subject.
<ubotu> Launchpad bug 185486 in launchpad "Merge account option should be on profile page" [Undecided,New] https://launchpad.net/bugs/185486
<mrevell> The Actions menu is somewhat busy already. Where else in someone's profile pages do you think we could place a link to merge accounts?
<mrevell> Thanks kiko
<salgado> mrevell, the 'Claim this account' is a link to +requestmerge when the person is logged in
<kiko> mrevell, so if I'm at ~kiko/ you'd like the option of initiating a merge from there?
<kiko> salgado, sure, but it only appears on the pages of people who are inactive
<kiko> mpt have an opinion?
<mrevell> kiko: I think so. it seems like the place I'd look for it and, it seems from talking to users, that its current location isn't obvious to them
<kiko> mrevell, the only place I know to look for is on /people/
<mrevell> yeah
<kiko> yeah, I agree that's a problem. but what to do with the link is a bother
<kiko> mrevell, you chase mpt down to talk it over?
<mrevell> Well, I'll discuss the with mpt after the meeting and anyone else who is interested
<mrevell> kiko: will do
<mpt> kiko, mrevell discussed it with me yesterday or so
<kiko> [ACTION] mrevell and mpt to discuss https://launchpad.net/bugs/185486
<MootBot> ACTION received:  mrevell and mpt to discuss https://launchpad.net/bugs/185486
<ubotu> Launchpad bug 185486 in launchpad "Merge account option should be on profile page" [Undecided,New]
 * stub notices his battery is low and has lost his power adapter
<mpt> The person page is one of the pages for which the Actions menu problem will be solved
<mpt> so, I'll have to find *some* way of fixing it :-)
<kiko> [TOPIC] Beginning the UI review mentoring (mpt)
<MootBot> New Topic:  Beginning the UI review mentoring (mpt)
<mpt> thanks kiko
<mpt> A couple of weeks ago I proposed mentoring reviewers on reviewing UI stuff
<mpt> and the response was positive, which is great to see
<mpt> So, I'm looking for one or two volunteers to start this next week :-)
<mpt> volunteer reviewers, that is
<kiko> come on!
<barry> mpt: i'm interested, but probably not starting next week
<bac> mpt: same as barry, as we'll be sprinting
<SteveA> we'll be focusing on non GUI stuff at the sprint
<mpt> "I don't bite ... hard ..." -- Austin Powers
<intellectronica> mpt: ok, i volunteer
 * kiko looks at BjornT's team!
<kiko> intellectronica!
<mpt> thanks intellectronica
<gmb> mpt: I'll be interested once I'm graduated as a reviewer.
<mpt> Probably best to do only graduates
<gmb> But I think >1 mentor would slow things down somewhat.
<flacoste> gmb: you don't need to be graduated for this
<flacoste> mpt: why?
<mpt> exactly
<mpt> because 2 levels of mentoring would slow down reviews too much
<gmb> Especially when you consider on-call work.
<flacoste> makes sense
<mpt> One other?
<flacoste> i thought it was an hands on training
<kiko> salgado?
<flacoste> not a new level of mentoring
<mpt> Considering that not all reviews will touch the UI
<flacoste> salgado: will be sprinting
<salgado> kiko, sprint
<kiko> ah, right.
<kiko> mpt, let's do with one for now since we seem short of reviewers who are free.
<mpt> ok
<kiko> next week we'll get another
<kiko> very well
<mpt> also
<mpt> flacoste, you mentioned training
<mpt> UI design training is a separate thing, which I'm scheduled to organize next month.
<kiko> I had a topic to discuss, but I'll leave it for next-week -- but will talk to mpt about it meanwhile. topic was <gmb> Especially when you consider on-call work.
<kiko> gar.
<kiko> What should we do about pillar +portlet-details (kiko)
<mpt> thanks kiko
<kiko> that was the topic.
<kiko> very good
<SteveA> do we need VNC or something
<SteveA> like, how do we effectively practice UI review mentoring?
<kiko> how would VNC help, though?
<flacoste> screen sharing
<kiko> I get the feeling it's more about having conversations over mockups
<SteveA> rather than say "the thing at the top, yeah, there, that thing"
<SteveA> you just say "see there"
<mpt> SteveA, I think discussing diffs over the phone (+ IRC for URLs) will be sufficient in most cases
<SteveA> diffs?
<SteveA> not screens?
<kiko> or screenshots
<SteveA> maybe there are tools to make getting screenshots more efficiently
<SteveA> we've learned that a fast turn-around is important
<mpt> SteveA, this is mentoring of branches. Branches generate reproducible behavior at URLs that the reviewer and the mentor can look at.
<SteveA> and UI discussions are dynamic
<mpt> mentoring of branch reviews, I mean.
<SteveA> so, please consider using technology to help have richer communication about the UI
<mpt> ok
<SteveA> part of the learning is about what's there
<SteveA> part of the learning is getting others to see what you see
<SteveA> and understand the significance of it all
<SteveA> etc.
<intellectronica> for sessions with me it's quite easy because i can be in millbank and work together with mpt, so we've got some time to think about that until someone else volunteers
<SteveA> nice
<kiko> yeah, cool. okay. thanks for volunteering again, intellectronica -- great to see us move forwards in an area that we all lack
<kiko> [TOPIC] Blockers
<MootBot> New Topic:  Blockers
<flacoste> Foundations: not blocked
 * SteveA offers beverages of his choice to intellectronica at the next launchpad event
<jtv> Translations: not blocked
<BjornT> Bugs: not blocked
<mpt> [ACTION] mpt to investigate technology for sharing display of Web pages in branches being reviewed
<matsubara> Releases: not blocked
<bigjools_> Soyuz: blocked on RT #29797, which is in turn blocked on packaging
<statik> lpcomm: not blocked
<SteveA> SC: not blocked
<adeuring> hwdb: not blocked
<kiko> very good!
<kiko> thanks everyone
<SteveA> thanks kiko!
<mrevell> thanks all
<kiko> apologies for overrunning, and for being so verbose
<kiko> but somebody's got to do it
<mrevell> :)
<SteveA> thanks launchpad team, and interested launchpad users, for keeping it productive
<kiko> and when that somebody is me
<statik> thanks for the meeting kiko
<kiko> you get lots of talking
<carlos> kiko: don't worry, we still love you ;-)
<kiko> #endmeeting
<MootBot> Meeting finished at 14:54.
<kiko> phew!
<bigjools_> kiko: do you have time to talk about that RT right now?
<kiko> being loved is more important than being right!
<stub> Anyone need me speak *now* or phone me since my battery is about to die.
<Hobbsee> SteveA: glad to be able to sidetrack the meeting a bit again
<kiko> stub, not me -- but thanks for asking.
<SteveA> Hobbsee: you're welcome.
#launchpad-meeting 2008-01-25
<don_miguel_el_un> hello
<don_miguel_el_un> Rinchen, cxu vi cxeestas?
<Rinchen> I am!
<Rinchen> Jes!
<Rinchen> kaj ankau #launchpad
<don_miguel_el_un> mi havas demandojn pri tradukado
<don_miguel_el_un> cxu gravas kie mi demandas?
<Rinchen> demandu! :-)
<don_miguel_el_un> unue, cxu oni povas alglui la N-finajxojn al cxenoj? Ekzemple: "Fiaskis ruli %sn"
 * bigjools blinks
<don_miguel_el_un> aux eble tiu malordigas la interpretilon.. ? :)
 * Rinchen is on the phone and delayed in responding)
<Rinchen> re: N-finajxojn,  mi jxus nun sendis email-n al vi
<don_miguel_el_un> dankon.. sed cxu vi opninias ke gxi eblus malordigi la interpretilon?
<Rinchen> jes, gxi malordigas gxin.
<don_miguel_el_un> fek. :( alia solvo estus uzi na "na" antaux fremdaj vortoj.. sed mi kredas ke multaj homoj ne aprezus gxin...
<Rinchen> eeww  "na"
<don_miguel_el_un> voilÃ  :)
<Rinchen> :-)
<don_miguel_el_un> mi tamen opinias ke tiu estus plej eleganta solvo...
<don_miguel_el_un> mia lasta demando estas, se oni uzas "ne eblAS .. " aux "ne eblIS fari blalbabla"
<Rinchen> mi preferas "as".
<Rinchen> ne eblas.....
<don_miguel_el_un> mi ankaux.. estas pli gxenerale..
<don_miguel_el_un> dankon pro viaj respondoj!
<Rinchen> mia plezuro
<Rinchen> bonvenon al la temon (aux temo ;-)
<don_miguel_el_un> dankon (teamo) :)
<Rinchen> hehe
<don_miguel_el_un> why is in english every string in such `weird' `quotes that dont match'?
<Rinchen> don_miguel_el_un, depends :-)  In Translations?
<Rinchen> do you have an example
<don_miguel_el_un> unable to write updated status of `%.250s'
<don_miguel_el_un> `' < this pair is weird :)
<Rinchen> interesting. do you have a url?
<don_miguel_el_un> https://translations.launchpad.net/ubuntu/hardy/+source/dpkg/+pots/dpkg/eo/+translate?start=40
<don_miguel_el_un> it's always like that..
<don_miguel_el_un> it's just the way all the messages are written.. did you never notice?
<don_miguel_el_un> but the official esperanto quotes are a pair. either "bla" or 'bla'
<don_miguel_el_un> another thing: if '%s' works, why should %sn not work?... I would have guessed that the %-operator concerns the next character only.. where would I find information about that? i was looking for it already, but I found nothing..
<don_miguel_el_un> if you take a look at number 51., the n is in another font as %.250s https://translations.launchpad.net/ubuntu/hardy/+source/dpkg/+pots/dpkg/eo/51/+translate
#launchpad-meeting 2009-01-21
<barry> #startmeeting
<barry> mootbot, like gwb is an ex-mootbot
<bigjools> the mystery of the missing mootbot
<rockstar> mootbot is dead.
<rockstar> I killed him.
<barry> anyway.  welcome to this week's ameu reviewer's meeting.  who's here today?
<sinzui> me
<bigjools> me
<rockstar> me
<mars> me
<al-maisan> miau
<gary_poster> me
<adeuring> me
<abentley> me
<allenap> me
<salgado> me
<bac> me
<intellectronica> me
<barry> BjornT, cprov, danilos ping
<gmb> me
<danilos> me
<flacoste> me
<barry> EdwinGrubbs: ping
<danilos> (though I am likely to be on and off)
<EdwinGrubbs> me
<barry> np, today's a light agenda
<barry> [TOPIC] agenda
<barry>  * Roll call
<barry>  * mars to stop ocr, will review js on call until more reviewers are trained
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  * Action items
<barry>  * Mentoring update
<barry> oops.  ignore the mars item, we did that last week
<mars> *whew*
<barry> let's skip around a bit...  i suck today
<barry> [TOPIC] action items
<barry>  * barry to look into techniques for eliminating back-patching of schema types (avoiding circular imports)
<barry> i actually started to look at this and i might have a branch for review later this week
<bigjools> \o/
<barry>  * barry to add `pretty()` functions to reviewers docs
<barry> not done
<barry>  * flacoste to work on API reviewer cheat sheet
<flacoste> *sigh*
<barry> no worries.  do you want to keep it on the list?
<flacoste> yeah, for two more weeks
<barry> you got it :)
<barry> [TOPIC] mentoring update
<barry> any word from mentors or mentats?
<gmb> al-maisan's doing very well now that the volume of reviews is back up to something approaching normal
<gmb> Mondays aren't the ideal day for mentoring, I think; they can be quite quiet.
 * abentley agrees they are quiet.
<barry> should we move you guys to get better coverage?
<barry> i think adeuring was looking for a monday slot
<gmb> barry: I'm not sure, it depends on how al-maisan feels.
<barry> we also have euro/tues free
<adeuring> adeuring: well, I wouldn't oopose to taking Monday
<adeuring> ...or Tuesday or Wednesday
<al-maisan> gmb: I am your apprentice, so will tag along :)
<bigjools> any day ending in a "y"
<gmb> :)
<gmb> al-maisan, barry Maybe it's worth moving to Tuesday for a week or two.
<barry> bigjools: thank goodness that leaves satursun out
<barry> gmb, al-maisan ok. let's move you guys to tuesday for two weeks to get more mentoring in
<gmb> Cool.
<al-maisan> fine :)
<barry> adeuring: let's keep you at friday for now and then depending on how it goes with gmb and al-maisan we could switch you after that
<gmb> I'll update the OCR page.
<adeuring> barry: OK
<barry> gmb: awesome, thanks
<barry> any other mentoring issues?
<barry> guess not!
<barry> [TOPIC] peanut gallery
<abentley> I have a PSA
<barry> well, that's all i have on my agenda, i open the floor to y'all
<barry> abentley: go ahead
 * al-maisan wonders what a PSA is..?
<gmb> al-maisan: public service announcement
<al-maisan> ah!
<abentley> When you approve a merge proposal, please mark its status approved as well.
<abentley> If you are using email, you can use the "status approved" command.
<rockstar> Now you know, and knowing is half the battle! Gee Eye JOOOOOOOOOOE
<abentley> This will remove the proposal from the list of active reviews.
<barry> abentley: that is a continuing source of pain ;)
<abentley> Which makes it easier to see what needs to be reviewed.
<bac> abentley: +1
<gmb> Nurse, nurse! rockstar's out of bed again...
<rockstar> gmb: did you not watch GI Joe, with the PSAs at the end?
<abentley> You can use "review approve" and "status approved" in the same email.
<gmb> rockstar: Call it cultural differences :)
<abentley> Just on different lines.
<salgado> abentley, why do we need both?
<rockstar> I know thumper talked about doing it automatically, but we have some details to figure out first.
<al-maisan> abentley: do you need both?
<abentley> salgado: Because one is a reviewer's opinion, and one is the status of the merge proposal.
<rockstar> salgado: one is the status of the CodeReviewVote, the other is for the status of the BranchMergeProposal
<sinzui> salgado: some project may require two more more reviews to be approved before the status is really approved.
<EdwinGrubbs> abentley: btw, doesn't there need to be a leading space in the email commands, so it should be " review approve"
<flacoste> i think you only need status approve
<salgado> I see
<abentley> EdwinGrubbs: Yes.
<flacoste> iirc, it also automatically approve the review
<rockstar> flacoste: not true currently.
<abentley> salgado: There are two reviews in many cases.
<salgado> I've been using only "status approve"
<barry> salgado: i guess that approves the mp without setting your review status to approve...?
<rockstar> salgado: it'd be " status approved" - note the tense
<abentley> salgado: Other projects may have different rules about how many reviews are required, whether reviewers can veto, etc.
<bigjools> maybe have a per-project policy that can be set then
<abentley> barry: Right.  It's like: "I don't approve of this, but merge it anyway."
<flacoste> sure, i thought thumper said it did both
<flacoste> ?
<salgado> abentley, I don't see it that way.  I see it more as an indication that the reviewer didn't know there were two separate things to approve
<barry> abentley: and eventually we'll be able to specify those workflows and have it all work automatically, right? <wink>
<rockstar> flacoste: it does in cases where you voted needs_fixing, and then revoted approve
<abentley> barry: That's a good question.  The mandate to avoid imposing policy was from on high.
<barry> abentley: not imposing policy, but providing the mechanisms for projects to specify their policy
<rockstar> barry: eventually, given enough time, Launchpad will support direct teleportation to sprints.
<barry> abentley: but i think that's also frowned on :/
<abentley> barry: You may not from my work on Bundle Buggy that I think it makes a lot of sense to have policy about what is needed to approve a merge proposal.
<barry> rockstar: thank goodness, 'cause i'm running out of my little round friends
<barry> abentley: in this case, it could be as simple as a count of the number of approved reviews.  i don't even care about the rejected ones
<al-maisan> the email generated by the webapp says: "Review: Approve" BTW .. that means we cannot use that any more?
<rockstar> barry: in Entertainer's case, a rejected or a needs_fixing prevents the branch from landing regardless of the approveds...
<abentley> barry: So in LP, we have mentor / mentat reviews, which are one special case.  And we have database reviews, which are another.
 * barry invokes the 80/20 rule
<rockstar> al-maisan: that is just the output email.  The input in " review approve"
<salgado> does "vote approve" work as well?
<abentley> rockstar is working on exposing BMPs through the API.  Presumably he could write a script to enforce a policy.
<barry> abentley, rockstar +1 !
<rockstar> abentley: yes, that's an idea.
<rockstar> salgado: vote is deprecated.  Use review.
<salgado> will do
<barry> abentley: cool, thanks for that psa
<abentley> barry: np
<barry> anything else on this or other topics?
<abentley> barry: I've just started work on generating diffs for all merge proposals.
 * flacoste cheers
<barry> abentley: yay!
<flacoste> i propose a virtual wave for abentley!
<al-maisan> :)
<barry> everyone send abentley an e-beer
<barry> are we done?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<barry> thanks everyone!
<gmb> Thanks barry
<flacoste> thanks barry!
<abentley> Thanks barry
<al-maisan> thanks barry!
#launchpad-meeting 2009-01-22
<matsubara> #startmeeting
<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.
<Ursinha> erm
<matsubara> [TOPIC] Roll Call
<herb> me
<Ursinha> me
<mrevell> me
<sinzui> me
<rockstar> we
<matsubara> so who's here today?
<sinzui> I'm still here
<Ursinha> everyone except the bot
<rockstar> me too
<matsubara> lag
<matsubara> flacoste, bigjools: ?
<bigjools> me
<flacoste> me
<henninge> me
<intellectronica> me
<matsubara> all right. everyone is here
<matsubara> [TOPIC] Agenda
<matsubara>  * Next meeting
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (DBA contact)
<matsubara> [TOPIC] * Next meeting
<matsubara> so next meeting, same time next week?
<Ursinha> +1
<matsubara> how about removing that section and adding it again only when we won't be having the meeting?
<rockstar> This part of the meeting should only be here if there's something that might make it not at the same time.
<rockstar> :)
<matsubara> :-)
<flacoste> i'll need to send somebody
<matsubara> [action] matsubara to remove the next meeting from the agenda and add a note to the MeetingAgenda page that it should be added again when we need to change the time
<flacoste> as I might not be able to attend (TL meeting)
<bigjools> me too
<flacoste> same for bigjools and sinzui
<sinzui> me too
<matsubara> same here, I'll be attending the TL meeting so Ursinha will likely run it
<Ursinha> yes
<henninge> so there is a reason to discuss the next meeting at each meeting?
<henninge> -> planned attendance
<matsubara> [action] TL (sinzui, flacoste, bigjools) to send people to cover for them due the TL meeting next week
<matsubara> indeed henninge
<matsubara> so, moving on
<matsubara> [TOPIC] * Actions from last meeting
<matsubara>  * matsubara and Ursinha to QA some of registry team items
<matsubara> ok, we did that.
<sinzui> Thanks very much
<matsubara> so, if any of the teams need a hand testing stuff, talk to us!
<matsubara> sinzui, my pleasure :-)
<matsubara>  * Oops report & Critical Bugs
<matsubara> Today oops report is about bugs 319173, 318894, OOPS-1116EC265, OOPS-1113EB6
<ubottu> Launchpad bug 319173 in launchpad "zip files cannot be uploaded to a release" [Undecided,Incomplete] https://launchpad.net/bugs/319173
<ubottu> Launchpad bug 318894 in launchpad-foundations "oops when responding to merge proposal review via email" [Undecided,New] https://launchpad.net/bugs/318894
<matsubara> so the first one, which I'll move to -registry I need to try to reproduce on windows
<flacoste> herb: can you check that buildbot-poll script is working? buildbot has blessed a lot of revisions that weren't pushed to stable
<matsubara> Im working with the reporter to find out the cause and will add more info once I have it
<sinzui> matsubara: I think we limit the upload to tar.gz, changelof, and .txt
<matsubara> sinzui, who in your team should be assigned to fix that one?
<herb> flacoste: will check after the meeting, yes
<sinzui> matsubara: is it a bug?
<matsubara> sinzui, it works on firefox for linux. it doesn't matter the file extension
<matsubara> sinzui, the thing is, according to the reporter, it oopses when he tries to upload while using FF on windows
<sinzui> matsubara: I'll give it to my favorite bug assassin--salgado
<matsubara> sinzui, ok, once I have more info I'll coordinate with salgado. thanks sinzui
<matsubara> the other two oopses are for lp-bzr team
<matsubara> [action] matsubara to file bugs for OOPS-1116EC265, OOPS-1113EB6
<matsubara> rockstar, can you help me out with those two oopses after the meeting? need to find a way to reproduce them
<rockstar> matsubara, okay.
<matsubara> flacoste, news about the -foundations one?
<flacoste> matsubara: looking into it, but unless it is happening a lot, i don't see it as a high priority
<matsubara> flacoste, barry's been bitten a lot by that one, IIRC
<flacoste> that's what you get for using proprietary email applications!
<matsubara> flacoste, shall I close it as invalid with that as the rationale? :-)
<flacoste> i'll take care of it :-)
<matsubara> flacoste, thanks!
<matsubara> for critical bugs, we have 3. all of them fix committed.
<matsubara> good job everyone!
<matsubara> moving on
<matsubara>  * Operations report (mthaddon/herb/spm)
<herb> 2009-01-16 - Friday - We cherry picked r7586 to lpnet* to fix bug #315103
<ubottu> Launchpad bug 315103 in malone "When consuming a token, Launchpad tries to update already-consumed tokens" [High,Fix committed] https://launchpad.net/bugs/315103
<herb> 2009-01-20 - Tuesday - We cherry picked r7588 to lpnet* to fix bug #317241
<ubottu> Launchpad bug 317241 in launchpad-foundations "Creating a launchpad account in the process of an OpenID authentication returns a failure to the RP" [Critical,Fix committed] https://launchpad.net/bugs/317241
<herb> Bug #156453 and #118625 continue to be a problem requiring us to restart codebrowse at least daily.
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,In progress] https://launchpad.net/bugs/156453
<herb> As noted by mthaddon and spm via email to the list, we've been seeing higher than normal DB load this week. We also experienced some issues with app servers taking too long to respond to requests (anywhere from 15-30 seconds). We suspect the two are related in some way but don't yet have any hard evidence to back this up.
<ubottu> Launchpad bug 118625 in launchpad-bazaar "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/118625
<Ursinha> hm, this explains the timeouts
<matsubara> linkchecker was disabled last friday, but that didn't seem to make any difference on the staging DB load
<herb> well. that's it from us unless there are questions.
<matsubara> rockstar, how's the codebrowser bug going?
<stub> The staging rebuild is the killer - it chews up an entire CPU and swaps important information out of RAM for its run, which is about 8 hours of the day IIRC.
<rockstar> matsubara, we know no more this week than we did last week.
<rockstar> jml and poolie are at the TL sprint early to work on it.
<matsubara> rockstar, :-(
<matsubara> that's great news
<matsubara> stub, any way to optimize that?
<stub> It already is optimized.
<stub> We would have to start dropping features, which makes it less useful.
<flacoste> or get a new box
<flacoste> kiko is on it
<flacoste> gpg: Erreur de CRC; E7341E - DC3E73
<flacoste> gpg: aucune signature trouvÃ©e
<flacoste> gpg: impossible de vÃ©rifier la signature.
<flacoste> ignore those gpg thing
<matsubara> hehe that's barry's broken signature :-)
<matsubara> all right. thanks stub, flacoste, herb and rockstar
<matsubara> moving on
<matsubara> [TOPIC] * DBA report (DBA contact)
<stub> Staging rebuilds are getting dangerously close to filling up their disk partition again. Avoiding this looming problem involves moving staging to new hardware, or bringing down the databases on Chokecherry while we repartition the disks.
<stub> We have been getting some load spikes again, causing the losas to rewire the appservers to distribute db load a little more evenly. In the past, these have been bots request spamming. I don't think anyone has identified the trigger this time yet. My money is on a bot crawling an expensive part of the site, or the load of the staging rebuild causing trouble, or a combination of the two.
<stub> I've suggested shutting down staging and the staging rebuild next time it happens to reduce the possible variables.
<stub> DB patches for this cycle have all landed except for one of mine still being worked on (severing relationships between the future authentication replication set and the main db), and a late request from Salgado (caching the total download count on LibraryFileAlias, which I'll probably defer until next cycle rather than make a hasty decision).
<matsubara> all right, questions for stub?
<matsubara> thanks stub
<matsubara> what do you think of officially make this meeting 30 min rather than 45?
<Ursinha> matsubara, we in average use 40-45 mins
<Ursinha> do you think it's needed?
<Ursinha> to reduce the time, that is
<matsubara> Ursinha, do we? I thought we used less than 30.
<matsubara> but let's keep it 40-45 then
<Ursinha> AFAIR
<matsubara> anyway, thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<matsubara> #endmeeting
<stub> 20% slack time is good.
<Ursinha> :)
<Ursinha> thanks matsubara
#launchpad-meeting 2010-01-25
<Ursinha> OOPS-1486EA603
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1486EA603
#launchpad-meeting 2010-01-27
<bac> hi everyone
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> yay, mootbot is here
<bac> who else?
<allenap`> me
<henninge> me
<sinzui> ma
<sinzui> me
<sinzui> mo
<sinzui> mu
<danilo_> me
<sinzui> my
<bigjools> me
<bac> gmb, intellec`, mars, EdwinGrubbs: ping
 * bigjools calls troops
<intellec`> me
<EdwinGrubbs> me
<al-maisan> me
<mars> me
<barry> lurk
<mars> lol
<bac> gary_poster: release-manager ping
<adeuring> me
 * bac understands gary_poster may be too busy
<gary_poster> bac, yeah, a bit busy thanks
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> * Roll call
<bac>  * Action items
<bac>  * Styles of reviews: should that be up to the reviewer or is there a preferred style? [salgado]
<bac>  * Conditional expressions - are they kosher, now that we're on Python2.5? [intellectronica]
<bac>  * Peanut gallery (anything not on the agenda)
<bac> [topic] action items
<allenap`> Apologies from deryck.
<noodles775> me
<MootBot> New Topic:  action items
<bac> thanks allenap`
<bac> * intellectronica to draft guidelines for drive-by cleanups
<intellec`> intellec`: i have no idea who this intellectronica dude is
<bac> intellec`: any progress?
<intellec`> but i haven't done that. sorry
<bac> intellec`:  would you like to commit to a date to do it or drop it from the list?
<intellec`> i would even go as far as suggesting that we drop it, just to be realistic. it's been lingering for a while
<bac> dropped
<bac> * Gavin to start discussion on the ML about doctest size, refactoring, moving corner cases to unittests, etc
<allenap`> I'm doing that as we speak, so keep it, but it will definitely be done later today.
<bac> cool, thanks allenap`.  look forward to a lively discussion.
<bac> * Gary to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again next week.
<salgado> me
<gary_poster> no, sorry, and next week is team lead sprint
<bac> gary_poster: ok, i'll note that and we can revisit in a few weeks
<bac>  * Henning to update wiki page for pre-imp requirement for community contributions, etc.
<bac> henninge: good news?
<henninge> I did that as far as I could.
<henninge> But I found out that we don't have a real reviewer documentation on dev.lp.net
<henninge> a lot of pages would need to be migrated from launchapd.canonical.com and updated
<henninge> I did not do that.
<henninge> But I mentioned the requirement on https://dev.launchpad.net/PreMergeReviews
<barry> some of those old pages are *really* out of date :/
<bac> henninge: understood.  thanks.
<bac> barry: yes, we need to do some wiki tending...
<bac> i'll take a look at it this week.
<bac> [action] bac to look at moving wiki pages to dev.lp.net and cleaning out the cruft
<MootBot> ACTION received:  bac to look at moving wiki pages to dev.lp.net and cleaning out the cruft
<bac> new topics
<bac> * Styles of reviews: should that be up to the reviewer or is there a preferred style? [salgado]
<bac> er
<bac> [topic] * Styles of reviews: should that be up to the reviewer or is there a preferred style? [salgado]
<MootBot> New Topic:  * Styles of reviews: should that be up to the reviewer or is there a preferred style? [salgado]
<salgado> so, we have basically two styles of doing reviews:
<salgado> 1. Comments go around the code they apply to: Reviewer includes the diff (often quoted by the email client) and each comment made by the reviewer goes around the code it applies to. This means there's context for each comment and the developer can quickly see where that code is.
<salgado> 2. Top poster: Reviewer makes one or more comments at the top of the message, which may or may not contain the diff. Works well when the review points out *very* few things (or none), but as a developer I find it rather painful to go through a review containing just a list of bullet points with comments.
<salgado> Developers always try hard to make the reviewers' lives easier, so when wearing our reviewer hats we should try and make their lives easier as well by including the diff for context and commenting around the specific parts the comment applies to.
<gmb> me
<gmb> Argh, sorry
 * gmb was otp
<intellec`> there's another style: irc discussion (at best pasted into the MP later)
<salgado> should we have a policy on which style is preferred?
<barry> and a mix of styles: general comments at the top, specific comments mixed in with code quotes
<intellec`> i don't think we need to decide on a style. it's just important to remember that readability counts in reviews too
<bigjools> also as jml reminded me recently, include the file names with the diff chunks when commenting on them
<bac> i'll also note you cannot refer to line numbers in the diff as it is a moving target and gets updated when the branch is pushed
<bigjools> intellec`: +1
<bac> bigjools: +1
<barry> the general rule is: make the reviewers lives easier.  this applies to the reviewer too <wink>.  iow, if you make the review hard for the dev to deal with, you're just making your own reviewing life harder (more questions, more back and forth, more context switching, etc.).  do what you need to do to give the dev a high fidelity review they can act fully on the first time through
<bigjools> I don't think we need a policy, just some hints on making it easy to understand a review
<bac> reviewees, at least those of us here, shouldn't be shy about pointing out unclear style to reviewers.
<salgado> I brought this up because I find it really disturbing to go through a review which makes a bunch of points about the code but doesn't include the diff or anything for context
<barry> i always keep the diff header for the file i'm reviewing, so it's easy to see.  i'll cut out code usually only on hunk granularity so it's easier to follow
<barry> bac, salgado agreed
<bac> thanks for bringing it up salgado.  i agree with bigjools that i don't think we need a new policy just awareness.
<salgado> should we put this in a guidelines wiki page, to increase awareness, then?
<bac> personally i've adopted the style of downloading the diff, doing the review in the editor of choice (cough, emacs) and pasting it to the page.  and i try to delete only on chunk boundaries as barry mentioned.
<intellec`> i think that if you feel that we need to increase awareness an email to the list is in order
<bac> salgado: sure.  would you do that?
<salgado> sure, I can do it
<bac> additional thoughts?
<barry> as a dev, please have a conversation with your reviewer if you think the review did not provide the necessary level of context to help you resolve the issues
<bac> [action] salgado to update the wiki page to encourage reviews with sufficient context
<MootBot> ACTION received:  salgado to update the wiki page to encourage reviews with sufficient context
<salgado> barry, definitely
<bigjools> reviewing is a two-way process
<henninge> bac: I thouht ML discussion, not wiki page?
<barry> big +1
<barry> we're all here to learn, right?! :)
<henninge> and: which wiki page? ;_)
<bigjools> barry: I likez to lern
<salgado> henninge, I'll create one and send an email about it to the list
<bac> salgado: thanks!
<henninge> salgado: great, thanks
<bac> moving on...
<bac> * Conditional expressions - are they kosher, now that we're on Python2.5? [intellectronica]
<barry> bigjools: i gots lernt me good sometimes
<intellec`> use(conditional_expressions) if conditional_expressions is kosher else not use(conditional_expressions)
<bigjools> barry: git 'er dun
<intellec`> i'm +1 on using them, as long as they're not nested or otherwise too complex. i'd like to get other reviewers' opinion and decide on an official policy
<bac> bigjools: you've been in austin too long
<bigjools> lol
<barry> +1, tastefully, which will have to evolve.  my personal preference in general is that it makes code like this easier to read:
<barry> if foo:
<barry>     bar = 7
<barry> else:
<barry>      bar = 9
<barry> becomes
<barry> bar = (7 if foo else 9)
 * gmb agrees with barry
<barry> and always use parentheses, even if the syntax does not strictly require it, because it's more readable
<al-maisan> this reminds me a bit of perl :P
<intellec`> i also like the parentheses around the expression
<barry> al-maisan: guido deliberately picked odd syntax so people wouldn't abuse it :)
<mars> +1, trust the developers to use them well
<al-maisan> well, he *did* succeed in that
<barry> also, multiline form if the conditional is long:
<mars> intellec`, "tasteful" is the right word :)
<adeuring> +1
<bigjools> I think it's fine, any readability issues will be picked up in review
<barry> bar = (7 if foo.getSomeDataOutOfThere('baz') == 'frobnicate'
<barry>           else 9)
<mars> eewww
<barry> but multiline is a 'hint' that it might be too complex <wink>
<bac> barry: does muti-line make sense?  i think i'd rather see that using if-then
<intellec`> so, basically, it's a yes, but like everything else we discuss it in reviews to make sure the result is readable? i like that
<bigjools> and I expect we'll establish formatting conventions with a bit of use
<mars> barry, I think IRC didn't treat that last example so well :)
<intellec`> barry: i agree, multiline also doesn't improve much on the imperative form
<henninge> intellec`: +1
<barry> agreed.  i think it will be a evolution of team taste over time
<barry> s/a/an/
<bac> any thoughts on limiting conditional expressions to single line for readability?
<bigjools> I say see how it goes
<adeuring> bac: no "chaining" of conditional expressions
<mars> -1 on limiting them.  Trust the devs.
<barry> bigjools: +1
<intellec`> bac: yes, i think that's a good rule
<gmb> bac: +1
<barry> adeuring: agreed on chaining.  that really reduces readability
<bac> adeuring: +1
<barry> bac: i have another 2.5ism for ya, when you're ready :)
<bac> if we are in agreement (mostly) i'll add that to the wiki this week
<bac> [action] bac to update coding guideline wrt conditional expressions
<MootBot> ACTION received:  bac to update coding guideline wrt conditional expressions
<bac> barry: yes?
<barry> <cough>from __future__ import with_statement</cough> should be legal too now
<intellec`> barry: do transactions work with it? that's the classis use, no?
 * salgado has done that already; legal or not
<barry> context managers rock
<mars> +1
<barry> intellec`: i've had success with them, jtv doesn't like them for that purpose.  but that have lots of other uses
<barry> just about any place you've got ugly try/finally's, you can write a simple context manager and use a with statement
<bigjools> how about you take that to the ML with some examples?
<barry> i've used them for stashing and restoring umasks, cwd, sys.stdout, etc. etc.  they work great with files which already support the context manager protocol
<barry> bigjools: +1
<bac> barry:  would you be willing to email the list with examples and update the coding guidelines?
<barry> bac: yep
<bac> [action] barry to school us on the proper use of 'with'
<MootBot> ACTION received:  barry to school us on the proper use of 'with'
<bac> that's it for listed items
<bac> [action] * Peanut gallery (anything not on the agenda)
<MootBot> ACTION received:  * Peanut gallery (anything not on the agenda)
<bac> anyone have another topic?
<bac> of course that should
<bac> 've been a topic not an actoin
<bac> going once
<bac> twice
<EdwinGrubbs> I have a question
<bac> yes EdwinGrubbs
<EdwinGrubbs> Should translations/translations.js put items in the Y.translations.translations namespace, or should we have a convention similar to python, where translations/__init__.js adds items to the Y.translations namespace?
 * bigjools wonders how useful it would be to have a bzr plugin that creates new files with the correct copyright/licence at the top
<mars> bigjools, I just use templates in my editor for that
<bigjools> you still need to bzr add though?
<mars> bigjools, but you could have a lint step: legal-lint!
<bigjools> uff :)
<bac> sinzui, mars, intellec`: any thoughs on EdwinGrubbs' question?
<mars> bac, thinking
<intellec`> i prefer not importing into __init__
<intellec`> i find it hard to follow later on
<mars> EdwinGrubbs, anything under the translations/ directory can add to the namespace and objects.  What we do now (and by YUI convention) is that the same named file includes everything rolled up.
<EdwinGrubbs> mars: that should be added to the wiki then, if it is an existing yui convention
<mars> intellec`, agreed.  I find the correct building of package interfaces using __init__ to be sticky enough already, without having to mold the Py conventions to JS
<bac> EdwinGrubbs, mars: would one of you like to sort it out and document it?
<EdwinGrubbs> bac: I can do it
<bac> [action] edwin to document JS namespace issue
<MootBot> ACTION received:  edwin to document JS namespace issue
<bac> thanks edwin
<bac> final thoughts?
<bac> 3
<bac> 2
<bac> 1
<bac> #endmeeting
<MootBot> Meeting finished at 09:36.
<bac> thanks for coming everyone
<al-maisan> Thanks!
<mars> thanks bac
<barry> bac: thanks!
<henninge> thank you bac
<bac> thanks for "lurking" barry
#launchpad-meeting 2010-01-28
<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!
<sinzui> me
<al-maisan> me
<danilo_> me
<mrjazzcat> me
<mbarnett> me
<matsubara> sorry mrjazzcat, I always forget to ping you about the meeting. I'll add you to the "Who should be here?" section if you don't mind
<mrjazzcat> yes, please
<matsubara> on the MeetingAgenda page, I mean
<mrjazzcat> no worries
<matsubara> [action] add brian to the list of attendees in the MeetingAgenda page
<MootBot> ACTION received:  add brian to the list of attendees in the MeetingAgenda page
<matsubara> Ursula won't be around today
<matsubara> and I'll be standing in for Gary
<matsubara> rockstar, hi, around?
<matsubara> allenap, hi
<matsubara> well, let's move on and then Gavin and Paul 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>  * allenap to dig the master bug of OOPS-1474EA771
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1474EA771
<matsubara>  * salgado to take a look in the TypeError oopses (OOPS-1479S1000)
<matsubara>    * already did that, this is bug 403281, it happened because mthaddon was testing the new read-only switch on staging.
<matsubara>  * rockstar to take a look in OOPS-1480CMP1
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1479S1000
<ubottu> Launchpad bug 403281 in launchpad-foundations "public xmlrpc requests broken during read only period" [Undecided,Triaged] https://launchpad.net/bugs/403281
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1480CMP1
<matsubara> ok, so I'll re-add both items for allenap and rockstar
<matsubara> [action] * allenap to dig the master bug of OOPS-1474EA771
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1474EA771
<MootBot> ACTION received:  * allenap to dig the master bug of OOPS-1474EA771
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1474EA771
<matsubara> [action] * rockstar to take a look in OOPS-1480CMP1
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1480CMP1
<MootBot> ACTION received:  * rockstar to take a look in OOPS-1480CMP1
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1480CMP1
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> we have some oops reports but most of them foundations issues
<matsubara> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA884
<matsubara> Looks like an anonymous user is trying to do some operation which (s)he's not allowed. Should we really log an oops for this?
<matsubara> maybe related to https://bugs.edge.launchpad.net/launchpad-foundations/+bug/271029
<matsubara> More non-informational disconnectionerrors https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1489J147
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1488EA884
<matsubara> InternalError after ther rollout https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1489C1094
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1489J147
<ubottu> Ubuntu bug 271029 in launchpad-foundations "ForbiddenAttribute exception raised changing property of object" [Medium,Triaged]
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1489C1094
<matsubara> code team, BranchMergeProposalExists https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA174
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1488EA174
<matsubara> so, that's it and there's no one from Code to take a look at the BranchMergeProposalExists one
<matsubara> [action] matsubara to email Tim about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA174
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1488EA174
<MootBot> ACTION received:  matsubara to email Tim about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA174
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1488EA174
<matsubara> [action] matsubara to talk to leonard about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA884
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1488EA884
<MootBot> ACTION received:  matsubara to talk to leonard about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA884
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1488EA884
<matsubara> [action] matsubara to talk to salgado about More non-informational disconnectionerrors https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1489J147
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1489J147
<MootBot> ACTION received:  matsubara to talk to salgado about More non-informational disconnectionerrors https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1489J147
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1489J147
<matsubara> [action] matsubara to talk to stub or gary about InternalError after ther rollout https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1489C1094
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1489C1094
<MootBot> ACTION received:  matsubara to talk to stub or gary about InternalError after ther rollout https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1489C1094
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1489C1094
<matsubara> lovely, looks like I'm running the meeting all by myself heheh
<rockstar> me
<allenap> me
<al-maisan> :)
<matsubara> on the broken scripts side
<matsubara> sinzui, Scripts failed to run: loganberry:send-person-notifications seems to be broken
<matsubara> sinzui, could you take a look and reply to the list?
<sinzui> matsubara: all scripts appear to be broken
<matsubara> all?
<sinzui> They are not running and I am tempted to say something new was added that is taking forever and a day
<matsubara> I only see notifications for send-person-notifications and garbo-hourly
<matsubara> sinzui, can you confirm and reply to the list that's the case, at least for the send-person-notifications one?
<matsubara> I'll ask losas and/or stub about garbo-hourly not running as well
<allenap> matsubara: Re. OOPS-1474EA771, it's bug 508302, and deryck is working on it today.
<ubottu> Launchpad bug 508302 in malone "NotImplementedError OOPS when reporting a bug" [High,In progress] https://launchpad.net/bugs/508302
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1474EA771
<matsubara> thanks allenap, I'll adjust the bug link on that oops report
<matsubara> [action] matsubara to fix bug link on OOPS-1474EA771 to point to bug 508302
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1474EA771
<MootBot> ACTION received:  matsubara to fix bug link on OOPS-1474EA771 to point to bug 508302
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1474EA771
<matsubara> [action] sinzui to investigate failure on send-person-notifications and reply to the list with his findings
<MootBot> ACTION received:  sinzui to investigate failure on send-person-notifications and reply to the list with his findings
<matsubara> btw, updatebranches script also failed recently but that's been fixed by spm. the new rollout changed the script name and losas updated the notification thing to recognize the new name
<matsubara> on the critical bugs side
<rockstar> matsubara, updatebranches no longer runs.
<mthaddon> matsubara: er, not quite
<matsubara> we have 3 critical bugs
<rockstar> It's been replaced by scan_branches
<mthaddon> matsubara: we've had to revert it a bunch of times
<matsubara> mthaddon, hmm no? spm's email seems to indicate that
<mthaddon> matsubara: spm went to bed a while ago - a new problem was discovered since then
<mthaddon> matsubara: abentley and Chex have been working on it
<matsubara> oh, I was looking at this latest email to the list replying to one of the script failures notification
<matsubara> well, if they're already working on it, it's ok. :-)
<mthaddon> matsubara: not really...
<matsubara> mthaddon, no? what else is expected?
<mthaddon> matsubara: as I understand it, we've reverted to the old script because we still don't know what was wrong
<mthaddon> matsubara: and the fact that we've reverted between the old and new scripts twice now on production is a problem in itself
<mthaddon> matsubara: and also the fact that the first we heard about the problem was from a user report
<matsubara> mthaddon, I meant it's ok in the sense that people are already working on a solution and there's nothing much to be done during this meeting to have people act on it
<mthaddon> i.e. we don't have a good measure of when this problem is even happening
<mthaddon> matsubara: maybe not, but I'd like a bit of discussion about this class of problem and what can be done to prevent it in the future
<danilo_> mthaddon: what is the exact problem that we need to be able to track? (sorry, I am not fully up to date on what broke)
<mthaddon> danilo_: aiui email notifications of branch updates failed to be sent out
<gary_poster> mthaddon: "reverted ...twice...on production": I think we all agree this sucks.  However, AIUI, this was successfully QAd.  Either the QA was bad, or staging is not close enough to prod in some way.  I don't think we know yet.
<matsubara> mthaddon, I'm unaware of the details as well. My expectation is that a IncidentLog will be filed and action to prevent it will be included in the incident log
<danilo_> mthaddon: ah, right, that could have a bigger impact (it might be harming us in translations as well)
<mthaddon> matsubara: this doesn't really qualify as an incident log item since there's no measurable service that's been interrupted (we don't have any kind of nagios monitoring of this) - I guess I'm asking how we plan to approach it from here
<mthaddon> and how we got into this situation
<danilo_> mthaddon, gary_poster, matsubara: we are obviously missing a dedicated "communications person" for this specific item (someone to keep the entire situation in check); we've discussed that approach before, it'd be nice to find someone who can offload the communication side from abentley and others working on it
<gary_poster> danilo_: to the degree there's a failure there (communications), it'd probably be mine as RM
<gary_poster> maybe we can have somebody else too
<gary_poster> but that's RM stuff
<gary_poster> but AIUI that's not the prob
<danilo_> gary_poster, not necessarily, we discussed this in a TL call a few weeks (months?) back where we need someone to communicate with everyone
<gary_poster> maybe so
<gary_poster> but probs I see:
<danilo_> gary_poster, it's mostly about having someone take responsibility for making sure problems are visible and we know what's going on
<gary_poster> - we didn't catch this on staging.  Why?
<gary_poster> either QA was bad or staging is too diff
<gary_poster> we need to know why
<gary_poster> and fix it
<mthaddon> yep, I agree with that
<gary_poster> then also, unless I misunderstand, mthaddon is saying that we don't have an automated nagios-like process verifying basic success on production for this thing
<danilo_> gary_poster, neither of those is easy to fix (one depends on people always DTRT, another on machines always DTRT), so we need to be able to easily find out when it's broken rather than wait for users to report it
<gary_poster> danilo_: but doesn't that depend on one of the three things I said?  (people DTRT, machines DTRT, nagios-like-thing DTRT)
<danilo_> gary_poster, it does, I was typing before you typed the last one :)
<mthaddon> gary_poster: it's possible we can't do that for *everything*, but if we decide this is a sufficiently important thing that we care about it if it fails, it sounds like we need to monitor it somehow, yeah (possibly we are already with OOPSes, but why didn't we catch it til a user told us about it?)
<gary_poster> :-) ok
<danilo_> gary_poster, the 4th is lack of coordination and communication :)
<gary_poster> mthaddon: right. For me, this gets to my "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.
<gary_poster> maybe the jobs system can help with this
<danilo_> anyway, gary_poster, I think we should just raise the importance of ensuring sufficient monitoring of this part of code-hosting by thumper, and we can be done with the topic
<gary_poster> maybe we can architect the jobs system to give us a nagios-like hook
<danilo_> gary_poster, we don't have to solve the problem here :)
<gary_poster> because doing it with cron scripts is a one-per job
<matsubara> danilo_, can you raise the topic in the next TL meeting?
<gary_poster> danilo_: ack.  I kind of disagree with your summary though, and your action item, so that's why I'm continuing to blather :-)
<danilo_> matsubara, we are having a week long TL meeting next week, so it'd be best to action it for someone from code team to pass it on to thumper, imho :)
<gary_poster> (IOW, this is not a problem for thumper, it is a problem for BjÃ¶rn, team leads, etc.)
<danilo_> gary_poster, well, sure, I agree, but one step at a time
<gary_poster> matsubara: two action items: :-)
<matsubara> [action] 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
<MootBot> ACTION received:  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
<danilo_> gary_poster, there's immediate problem and then there's the elegant solution; I'm always for fixing the immediate problem first and having the elegant solution come out of that
<gary_poster> yeah, that's number one
<gary_poster> number two is gary to bring up archtecture concerns to team lead mtg :-)
<danilo_> gary_poster, as for the other one, I think it ties in well with what we discussed today and what we'll want to discuss anyway
<matsubara> [action] TLs + Bjorn to 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.
<MootBot> ACTION received:  TLs + Bjorn to 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> does that summarize it well?
<gary_poster> yeah thank you.  though it's probably my action, since I'm the one with the bee in my bonnet :-)  but that's fine
<danilo_> gary_poster, matsubara: I don't like action items like that because they put no responsibility on anyone in particular, thus meaning that if they get done, they get done unrelated to the action item; thus, you don't really need it
<gary_poster> so give it to me :-)
<matsubara> danilo_, I'll add it to gary's queue when I add the summary to the MeetingAgenda page
<danilo_> gary_poster, heh, that's ok, I am certain we would have discussed this regardless of us having any particular action item
<danilo_> matsubara, sure, thanks
<gary_poster> :-)
<matsubara> it serves as a reminder as well
<matsubara> anyway, thanks for the comments
<rockstar> It fairness, the "not getting branch update emails" thing was because a rather large part of the code hosting system was made into a job.
<gary_poster> To whom are you being fair? :-)
<gary_poster> Never mind, I'll be quiet :-)
<danilo_> :)
<matsubara> we have 3 critical bugs, one in progress, one fix committed
<rockstar> I'm not sure how "sufficient monitoring" would have fixed this.
<matsubara> the other one is triaged, bug 511567
<ubottu> Launchpad bug 511567 in launchpad-foundations "Can't remove authorised app" [Critical,Triaged] https://launchpad.net/bugs/511567
<rockstar> gary_poster, to the code team in general.
<matsubara> hmm
<danilo_> rockstar, sufficient monitoring of scripts that do this
<matsubara> that's a dupe
<matsubara> and I filed that bug a few days ago
<rockstar> danilo_, howso?
<matsubara> or maybe I filed the dupe
<gary_poster> rockstar: ah, gotcha.  Tim can beat us into shape at the TL sprint so we understand.
<rockstar> gary_poster, yeah, I'll talk to him.
<gary_poster> cool
<danilo_> rockstar, monitoring should have caught the problem (i.e. "hey, this script is failing"); I won't pretend to understand the entire problem, so we might be entirely off base, but we should be able to check our service level
<rockstar> danilo_, there wasn't a script failing.
<rockstar> It ran fine, it was just a new script that had apparently left out some old functionality.
<danilo_> rockstar, right, never mind the "implementation details", the problem is: "why we didn't catch it before someone told us it's failing"; there's not necessarily a technical solution
<danilo_> matsubara, am I still on the channel?
<matsubara> yes
<danilo_> oh, ok, it's just everybody being quite :)
<danilo_> matsubara, I think we should go on
<matsubara> sorry, I was looking for a bug report to dupe against 511567
<matsubara> anyway
<matsubara> thanks
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara> hello?
<matsubara> Chex, mbarnett ?
<mbarnett> sorry
<Chex> sorry
<Chex> here is the report
<Chex> - LP rollout 10.01 Wednesday was successful:
<Chex>     : See https://wiki.canonical.com/InformationInfrastructure/OSA/LPRollout20100127 for more details.
<Chex>     : The read-only switch left idle connections to the master DB, it is currently being investigated
<Chex> - New LP Appserver is online, some issues with internal access, but now everything is OK.
<Chex> - New branch-scanner having issues, just reverted back to old again.  Based on meeting dicsussion here,
<Chex>         continuing to address.
<Chex> and thats all for us.  Any questions/comments?
<matsubara> Chex, what's this new LP appserver online? I guess I'll have to tell oops-tools about oops reports from it?
<matsubara> [action] matsubara to update oops-tools to know about the new lp appserver
<MootBot> ACTION received:  matsubara to update oops-tools to know about the new lp appserver
<noodles775> Chex: do you know if the new servers have access to the private librarian?
<mbarnett> matsubara: soybean was recently put online as a replacement for gangotri +
<mbarnett> noodles775: that was resolved earlier today
<matsubara> mbarnett, oh, so it's using the same config files?
<noodles775> A user was seeing about 1 in 4 requests to download a... ah, great, thanks!
<mbarnett> matsubara: it took over lpnet1, lpnet2, and edge1 from gangotri, stole lpnet9 from gandwana, and added a sparkly new lpnet15 standard lpnet appserver
<matsubara> mbarnett, ok, it's the new lpnet15 instance I care about. I'll check the configs and update oops-tools accordingly
<matsubara> thanks
<matsubara> moving on
<mbarnett> matsubara: thank you.
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> stub sent the report to the list
<matsubara> allenap, he mentioned something about checkwatches being very cpu intensive. it's probably of interest of the Bugs team
<allenap> mars: deryck has just forwarded the message to me.
<allenap> matsubara: ^
<matsubara> thanks allenap
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> no proposed items
<matsubara> which brings this meeting to a close
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<matsubara> and sorry for the delay
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:47.
#launchpad-meeting 2011-01-26
<bac> There is no reviewers meeting today as decided last week.
<henninge> ah, I missed that. I was wondering wow we had decided on it.
<bac> henninge: i'll send email to the list to clarify
