#launchpad-meeting 2008-02-27
<mrevell> #startmeeting
<MootBot> Meeting started at 08:58. The chair is mrevell.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<mrevell> Welcome to February's Launchpad users meeting!
<mrevell> [TOPIC] Roll call
<MootBot> New Topic:  Roll call
<mrevell> Let's get an idea of who's here for the meeting. If you're here to take part, say me.
<mrevell> me
<mrevell> Okay, let's assume you're shy :)
<mrevell> We'll move straight onto user questions, as it appears there aren't many people here for the meeting
<mrevell> [TOPIC] User questions
<MootBot> New Topic:  User questions
<mrevell> We don't have any user questions on the agenda, so if you have a question or suggestion or comment for the Launchpad team, go ahead!
<mrevell> okay, if you do have a question or comment for the Launchpad team, you can find someone from the team just about 24 hours a day in #launchpad. Otherwise mail feedback@launchpad.net.
<mrevell> #endmeeting
<MootBot> Meeting finished at 09:03.
<jamesh> mrevell: that was short
<hexmode> k
<mrevell> jamesh: Yeah, if no one says "me" in the roll call I tend not to drag it out.
<statik> me
<barry> #startmeeting
<MootBot> Meeting started at 15:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everyone and welcome to this week's ameu reviewer's meeting
<barry> who's here today?
<BjornT> me
<intellectronica> me
<statik> me
<bac> me
<BjornT> gmb has problems with his internet connection atm
<barry> BjornT: cool, thanks
<bigjools> me
<jtv> me
<flacoste> me
<danilos> me
<barry> salgado: ?
<bac> allenap is off today i think
<salgado> me
<barry> schwuk: ?
<schwuk> me
<schwuk> sorry - was concentrating on another channel
<gmb> me
<bigjools> his first Soyuz review probably put him off ;)
* barry changed the topic of #launchpad-meeting to: agenda
<schwuk> bigjools: :P
<gmb> Sorry - I've been having connectivity issues
* barry changed the topic of #launchpad-meeting to:  Launchpad Meeting Grounds | Channel logs: http://irclogs.ubuntu.com/ | Meeting Logs: Logs available at http://kryten.incognitus.net/mootbot/meetings/
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
 * barry needs more coffee
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>    * sabdfl request: make sure enums to be in the same interface files as the schemas where they are expressed.
<barry>    * thumper - unwrapping import statements (line wrapping that is)
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<barry> same time and place?  anyone know they won't be here?
 * bigjools will be sprinting
<bigjools> but I might make it
<barry> k, thanks
<bac> sprinting too
 * jtv same
<BjornT> quite a lot of people will be sprinting next week
<bigjools> good point
<barry> which sprint is it?
<salgado> team lead sprint?
<bigjools> Team Leads and Soyuz
<salgado> oh, soyuz too?
<bigjools> yarp
<barry> should we still have a meeting then?
<bigjools> Soyuz Guy #3 (tm) is starting next week
<flacoste> and bzr
<flacoste> not that we have any bzr people in this meeting
<sinzui> me me me
<barry> flacoste: right.  i think mwhudson is the only guy who's gonna be at the next asiapac meeting ;)
<barry> well, i guess we'll still have the ameu meeting.  if nobody shows up, it'll be blissfully short :)
<barry> [TOPIC]  * Action items
<MootBot> New Topic:   * Action items
<barry>  * (continued) intellectronica to put cover letter draft on wiki
<barry> i think this was done, right?
<intellectronica> barry: yup
<bigjools> url?
<intellectronica> https://launchpad.canonical.com/ReviewRequestTemplate
<barry> intellectronica: awesome!  can you email the link?
<bigjools> can we link off PR to that too - I have enough bookmarks already :)
<barry> bigjools: +1
<barry> intellectronica: do you mind adding that link and emailing it to the launchpad list?
<intellectronica> barry: sure, i'll do that
<barry> thanks!
<flacoste> shouldn't sumit-review
<flacoste> modified to use that template?
<barry> [ACTION] intellectronica to email link to new review template and add a link to PR
<MootBot> ACTION received:  intellectronica to email link to new review template and add a link to PR
<barry> flacoste: let's get some feedback on it, but then, probably so
 * bigjools just added it to PR
<barry> great, thanks!
<barry>  * (continued) sinzui to look into outputting PR stanza by default in `review-submit`
<sinzui> I submitted my change to automatically output the PR block. I wait for mwhudson's approval.
<barry> sinzui: rock on!
<barry> [TOPIC]  * Queue status
<MootBot> New Topic:   * Queue status
<barry> general queue is clear
<barry> and only 3 needs-review branches in the pink
<barry> queue looks pretty good, any comments?
<intellectronica> the general queue is clear, but we've had to reject a branch of jml's
<barry> intellectronica: ah yes, i see it.  has jml been notified?
<intellectronica> i think something went wrong with his submissions, since there are quite a few of them on the mailing list with no wiki entries
<intellectronica> yes, danilo and i wrote to him
<barry> intellectronica: great, thanks
<barry> any other comments about the queue?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> [TOPIC]  * Mentoring update
<MootBot> New Topic:   * Mentoring update
<barry> nothing from me here...
<barry> 5
<sinzui> I think schwuk needs to get more reivews. I think he has had only two since he started.
<bac> mentoring with gavin is going well, but slow.  please allocate him some branches if you clear out the general queue.
<barry> sinzui, bac good points, thanks
<bac> sinzui: i think gavin has done two also
<barry> so we should favor mentorees when assigning general queue branches?
<sinzui> +1
<bac> +1
<intellectronica> +1
<intellectronica> but does it happen often enough?
<schwuk> sinzui: I'm going to try going on call this Friday, so I should get more then.
<sinzui> schwuk: Fab
<bigjools> as long as we mentorees don't get bombarded with branches
<bac> if gavin does any reviews next week i may need to ask one of you to mentor it, since i'll be sprinting.
<barry> [AGREED] favor (but don't overwhelm) mentorees when assigning general queue branches
<MootBot> AGREED received:  favor (but don't overwhelm) mentorees when assigning general queue branches
<gmb> bac: I'm happy to mentor if needs be.
<intellectronica> bigjools: unlikely. it really doesn't happen very often these days
<bac> gmb: thanks
<bigjools> intellectronica: true - most of them are done on-call
<barry> i'll need someone to help mentor schwuk during pycon, but that's not for a few weeks yet
<barry> er, sorry, bigjools
<bigjools> we can sort that out nearer the time
<barry> yep!
<barry> anything else?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> [TOPIC]  * Review process
<MootBot> New Topic:   * Review process
<barry>    * sabdfl request: make sure enums to be in the same interface files as the schemas where they are expressed.
<barry> so mark was pretty clear that we reviewers need to be more aware of where interfaces are defined
<barry> i moved an interface from person.py to teammembership.py because it was in the wrong place
<barry> so he just wanted me to communicate to you to keep an eye out for these things while reviewing code
<barry> (over)
<sinzui> barry: That reminds me that there was never an announcement that ISchemas can be defined in browser.*
<barry>    * thumper - unwrapping import statements (line wrapping that is)
<bac> barry: did you mention it to the developer who put it in person originally?
<barry> bac: i did not
<barry> bac: i think mark's point was more that reviewers need to be on guard for this
<bac> barry: true, but it might have been a good "teachable moment."
<barry> sinzui: i don't remember that decision specifically
<flacoste> sinzui: it's still status quo on this i think
<barry> bac: true
<flacoste> barry: i'm probably the one at fault here, since I took care of the move of all generic launchpad ones
<flacoste> barry: i probably put it person.py to avoid a cyclic import problem
<flacoste> or maybe i'm just fabulating
<salgado> or maybe it was me
<sinzui> bzr annotate
<barry> flacoste: no it makes some sense, because it was actually /used/ in person.py
<barry> but it was easy to avoid the circular import
<barry> sinzui: if it's worth it (i don't think it is)
<sinzui> I don't think it is worth it
<barry> or if you're curious :)
<barry> anything else on this topic?
<barry> ...
<barry>    * thumper - unwrapping import statements (line wrapping that is)
<bigjools> a big hairy +1 from me for that
<barry> so in the meeting agenda thumper suggests putting multi-line imports each on a separate line
 * barry hasn't actually talked to him about htis
<barry> it occurs to me too that __all__ has the same issue
<flacoste> i think this is crack
<salgado> -1
<salgado> that's crack
<flacoste> this is to avoid conflicts
<intellectronica> it's a nice idea, but the risk is that when merging we'll get too many imports that aren't being used
<flacoste> but these are trivial conflicts
<barry> bug salgado said he didn't like this in a recent review of mine
<flacoste> live with it
<intellectronica> also, these conflicts are easy to solve
<danilos> -0
<bigjools> it's not the conflicts that are the problem
<flacoste> and it uses a lot of screen estate
<bigjools> it's the diff
<salgado> I can live with that in the __all__, but not in imports
 * barry agrees with salgado
<bigjools> working out wtf changed when 4 lines are reformatted
<gmb> bigjools: using meld will solve that one.
<gmb> (or something similar)
<flacoste> who cares about these changes?
<flacoste> we have make lint to see if they are spurious
<salgado> bigjools, make lint should tell you if the changes are correct or not
<bigjools> fair point
<barry> [VOTE] one __all__ entry per-line but not per multiline import
<MootBot> Please vote on:  one __all__ entry per-line but not per multiline import.
<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> -1
<MootBot> -1 received from flacoste. 0 for, 1 against. 0 have abstained. Count is now -1
<salgado> -1
<MootBot> -1 received from salgado. 0 for, 2 against. 0 have abstained. Count is now -2
<gmb> -1
<MootBot> -1 received from gmb. 0 for, 3 against. 0 have abstained. Count is now -3
<BjornT> i don't care much either way, as long as we're consistent. if we're going to change the coding style, we should change all imports to conform with it. i don't thing that's worth the trouble
<sinzui> -1
<MootBot> -1 received from sinzui. 0 for, 4 against. 0 have abstained. Count is now -4
<bac> -1
<MootBot> -1 received from bac. 0 for, 5 against. 0 have abstained. Count is now -5
<BjornT> -1
<MootBot> -1 received from BjornT. 0 for, 6 against. 0 have abstained. Count is now -6
<bigjools> +0
<MootBot> Abstention received from bigjools. 0 for, 6 against. 1 have abstained. Count is now -6
<barry> okay, i think you all misunderstood the sense of my question, but we'll just say "i know what you mean" :)
<barry> the -1's are /against/ one-line per import
<barry> so...
<barry> -1
<MootBot> -1 received from barry. 0 for, 7 against. 1 have abstained. Count is now -7
<intellectronica> -1
<MootBot> -1 received from intellectronica. 0 for, 8 against. 1 have abstained. Count is now -8
<schwuk> -1
<MootBot> -1 received from schwuk. 0 for, 9 against. 1 have abstained. Count is now -9
<barry> [AGREED] thumper's suggestion of one-line per import is rejected
<MootBot> AGREED received:  thumper's suggestion of one-line per import is rejected
<barry> [TOPIC] free-for-all
<MootBot> Vote is in progress. Finishing now.
<MootBot> Final result is 0 for, 9 against. 1 abstained. Total: -9
<MootBot> New Topic:  free-for-all
<bigjools> <Wayne> Denied </Wayne>
<barry> i'm done, anybody have anything not on the agenda?
<salgado> nope
<bac> one quick thing
<sinzui> I'd like to suggest that when large branches are submitted, they are looked over for how they can b broken into smaller branches
<jtv> sinzui: shouldn't that happen before?
 * barry looks sheepish
<sinzui> I had a looks a one of celso's branches, and saw four separate deliverables.
<bac> i noticed 'rocketfuel-branch' no longer updates trunk.  this led to a much larger than expected diff i generated to review.  just mentioning
<bigjools> it's down to the dev to manage this - if the review doesn't like it the branch should be rejected.  The rules have been well announced.
<bigjools> s/review/reviewer/
<BjornT> jtv: it should, yes. but people will submit large branches anyway.
<barry> bigjools: +1
<sinzui> bigjools: True, but the chances of getting parts reviewed and landed is better than a giant branch
<BjornT> for big branches, i think the reviewer should have to explain why the branch couldn't be split up
<bigjools> sinzui: that's why we have the 800 line rule though isn't it?
<sinzui> bigjools: I was able to review two parts of celso's large branch and he landed them before you and schwuk got the backend and frontend pieces
<schwuk> sinzui: what about the time expended helping get the branch split? That's taken from other reviews.
<gmb> Maybe review-submit should wc -l the diff and warn the dev before they submit something oversized.
<sinzui> schwuk: I spent 10 minutes to find the parts
<BjornT> schwuk: i think the idea is that the reviewer will learn how to split up branches, so he won't do the same mistake in the future.
<flacoste> sinzui: if it makes it that future branch are smaller that's good
<sinzui> My core point is that during the preimp, the bug/spec needs to break the branches down to sane sizes
<bigjools> branch size is something I try to stay aware of during the branch's whole lifetime so I am not surprised when I submit it
<bigjools> sinzui: +1
<sinzui> I think in celso's case, he could have delivered the parts through out the week instead of on one day
<bigjools> pre-imp should discuss this as part of the "ready to code" criteria
 * sinzui 's branch in pending-reviews is special. there are no code or test changes.
<flacoste> and
<flacoste> i'd like to recall a point
<flacoste> big branches needs an arrangement with a reviewer
<flacoste> *before* they are submitted
<flacoste> i think we should just reject branches over 800k as a matter of policy
<flacoste> 800 lines
<gmb> flacoste: +1
<gmb> Especially for oncall work.
<flacoste> and leave the dev to find a reviewer
<LarstiQ> 800k lines or 800 lines?
<sinzui> So 800+ in the general queue is forbidden?
<bigjools> +1
<gmb> It dies up a reviewer for far too long.
<barry> flacoste: i would support that (even as a recent offender) IF lpreview complained bitterly about > 800 line diffs
<gmb> s/dies/ties
<bigjools> gmb: it can kill them too :)
<flacoste> larger than 800 lines is ok
<gmb> barry: It should be fairly easy to patch lpreview to do that.
<barry> let there be a --isuck flag
<flacoste> if you have a reviwerer that commited to it
 * gmb is looking at the source now.
<flacoste> this has been a policy for some time now
<flacoste> but we didn't really enforce it
<flacoste> now is probably time to do it
 * sinzui branches lpreview for 800 line slap test
<bigjools> so > 800 with prior agreement with a reviewer only?
<flacoste> lpreview will only submit a 800 lines patch if the -r option is used
<flacoste> yes
<gmb> sinzui: lpreview/__init__.py:313 would be an ideal place for the slap code.
<flacoste> bigjools: yes
<bigjools> flacoste: sounds good to me
<barry> sinzui or gmb: who wants the action item on this one? hack lpreview to enforce (with manual override) 800 line limit?
<flacoste> idea being that the reviewer will be able to help split the branch earlier
<gmb> barry: I'll take it.
<barry> gmb: thanks!
<flacoste> barry: no manual override
<flacoste> the manual override is the -r option
<sinzui> no manual
<barry> [ACTION] gmb to hack lpreview to enforce 800 line limit
<MootBot> ACTION received:  gmb to hack lpreview to enforce 800 line limit
<flacoste> -r being the reviewer who agreed to review the branch
<barry> flacoste: +1
<BjornT> flacoste: using -r has a disadvantage, though.
<sinzui> if the review is not specified and the diff is > 800 lines, die
<schwuk> should lpreview also have a -mentor argument?
<flacoste> BjornT: what is it?
<schwuk> or at least a -cc
<BjornT> it's not uncommon to ask a reviewer for a review, without telling him how big the diff is
<gmb> schwuk: Yes. I think there's abug for that already.,
<flacoste> lol
<flacoste> BjornT: right!
<flacoste> BjornT: what's your suggestion?
<BjornT> flacoste: manual override :)
<barry> BjornT: --isuck
<BjornT> this shouldn't happen often, so supplying an extra argument shouldn't be a problem
<sinzui> I think the implicit meaning of -r should suffice
<barry> sinzui: i think BjornT has a point though: i might add -r without being warned about branch size
<bigjools> I regularly use -r to direct the mail to the reviewer though
<bac> i think even if -r is specified there should be an explicit acknowledgment the branch is too big
<gmb> sinzui: Ah, but people use that when subitting stuff for PR...
<BjornT> sinzui: how often do you ask how big the diff is before accepting to review a branch?
<barry> i'd rather, first get the warning
<bigjools> you need a new option
<gmb> bac: +1
<barry> okay, we're out of time for this meeing!  gmb it's in your court now
<gmb> "You're submitting a 1200 line diff for review. Don't be silly now. Are you sure? [y/N]"
<gmb> barry: Okay.
<barry> #endmeeting
<MootBot> Meeting finished at 15:45.
<barry> thanks everyone!
<BjornT> sinzui: branches over 800 should not be common, so no need to optimize for that case. a bit extra work shouldn't be a problem.
<bigjools> thanks barry
<schwuk> thanks barry
<bac> thanks baw
#launchpad-meeting 2008-02-28
<mwhudson__> oof
<thumper> oof?
<Rinchen> foo spelled backwards?
<Rinchen> well, I show 18:00
<Rinchen> #startmeeting
<MootBot> Meeting started at 18:00. The chair is Rinchen.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<Rinchen> [TOPIC] Roll Call
<thumper> me
<mrevell> me!
<MootBot> New Topic:  Roll Call
<bac> me
<Rinchen> me :-)
<sinzui> me
<danilos> me
<EdwinGrubbs> me
<BjornT> me
<matsubara> me
<danilos> Rinchen: you turned the agenda around again? :)
<mwhudson> me
<Rinchen> danilos, just for you :-)
<Rinchen> bac?
<Rinchen> bigjools, cprov ?
<bac> ^^^
<Rinchen> gmb, herb mthaddon ?
<mthaddon> me
<cprov> me
<gmb> me
<mars> me
<Rinchen> salgado, ?
<salgado> me
<Rinchen> stub, ?
<thumper> abentley: ?
<danilos> Rinchen: I've pinged carlos and jtv
<schwuk> me
<abentley> me
<Rinchen> danilos, thanks
<BjornT> intellectronica: ?
<intellectronica> me
<danilos> Rinchen: ah right, jtv mentioned that he'll be travelling
 * bigjools is here for 5 minutes
<Rinchen> Steve and kiko are in another meeting so I'm going to press on...
<stub> me
<salgado> mars, did you say me already?
<mars> salgado, me?
<Rinchen> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (Matsubara)
<Rinchen>  * Critical Bugs (Rinchen)
<Rinchen>  * Bug tags
<Rinchen>  * Operations report (mthaddon/herb)
<carlos> me
<Rinchen>  * DBA report (stub)
<adeuring> me
<Rinchen>  * Sysadmin requests (Rinchen)
<Rinchen>  * New packages required (salgado)
<Rinchen>  * A top user-affecting issue (mrevell)
<Rinchen>  * Doc Team report (mrevell)
<Rinchen> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<Rinchen> I think we should be able to do next week's meeting.
<Rinchen> The Team Leads will be together but that shouldn't stop us :-)
<Rinchen> So that would be 6 March, same time, same place
<Rinchen> any objections or known absences?
<Rinchen> [AGREED] Next meeting 6 March, same time, same place
<MootBot> AGREED received:  Next meeting 6 March, same time, same place
<Rinchen> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<Rinchen> repost: salgado to investigate adding turbogears for codebrowse and germinate
<Rinchen> repost: danilos to investigate profiling and Rosetta team to prepare proposal for next week to fix remaining timeouts
<Rinchen> repost: mthaddon - discuss updating devpad rocketfuel archives to packs and do so if lifeless approved.
<salgado> Rinchen, not done yet
<Rinchen> [ACTION] repost: salgado to investigate adding turbogears for codebrowse and germinate
<MootBot> ACTION received:  repost: salgado to investigate adding turbogears for codebrowse and germinate
<danilos> Rinchen: still on it, got some pretty reports now, but not yet discussed with the team
<mpt> me
<jtv> me too
<mpt> (Sorry, had Internet troubles)
<Rinchen> [ACTION] repost: danilos to investigate profiling and Rosetta team to prepare proposal for next week to fix remaining timeouts
<MootBot> ACTION received:  repost: danilos to investigate profiling and Rosetta team to prepare proposal for next week to fix remaining timeouts
<Rinchen> no worries and welcome
<mthaddon> Rinchen, on the agenda for the coming week
<Rinchen> [ACTION] repost: mthaddon - discuss updating devpad rocketfuel archives to packs and do so if lifeless approved.
<MootBot> ACTION received:  repost: mthaddon - discuss updating devpad rocketfuel archives to packs and do so if lifeless approved.
<Rinchen> gmb - investigate Bug 193983
<ubotu> Launchpad bug 193983 in malone "Oops deactivating account when the account has a conjoined bugtask assigned to it" [Undecided,Fix committed] https://launchpad.net/bugs/193983
<Rinchen> kiko and cprov - discuss bug 193656
<ubotu> Launchpad bug 193656 in soyuz "Process-death-row procedure became very slow" [Critical,Triaged] https://launchpad.net/bugs/193656
<Rinchen> the rest are completed
<gmb> Rinchen: That bug has now had a fix comitted.
<Rinchen> great thanks gmb
<cprov> Rinchen: not done, sorry. I hope we will have time to discuss it together in London next week.
<Rinchen> cprov, ok, I'm going to raise that again quickly during the critical bugs :-)
<Rinchen> [ACTION] repost: kiko and cprov - discuss bug 193656
<MootBot> ACTION received:  repost: kiko and cprov - discuss bug 193656
<ubotu> Launchpad bug 193656 in soyuz "Process-death-row procedure became very slow" [Critical,Triaged] https://launchpad.net/bugs/193656
<cprov> Rinchen: okay, cool
<Rinchen> [TOPIC] Oops report (Matsubara)
<MootBot> New Topic:  Oops report (Matsubara)
<matsubara> Today's oops report is about bugs 196253, 196661, 196669, OOPS-788EB21, OOPS-788EC5
<ubotu> Launchpad bug 196253 in launchpad "OOPS importing pgp key" [High,New] https://launchpad.net/bugs/196253
<ubotu> Launchpad bug 196661 in launchpad-answers "Email reply triggered a ProgrammingError" [Undecided,New] https://launchpad.net/bugs/196661
<ubotu> Launchpad bug 196669 in launchpad "Change mirror owner to someone who doesn't have a preferred email set crashes the +review form" [Undecided,New] https://launchpad.net/bugs/196669
<matsubara> bout OOPS-788EB21, carlos is on it already. I'll file a bug and assign to him.
<matsubara> ACTION: matsubara to file a place holder bug for OOPS-788EB21 and assign it to carlos w
<matsubara> ho is already investigating it.
<matsubara> Any volunteers to fix 196253?
<matsubara> salgado, 196669 is for you me thinks.
<Rinchen> [ACTION] ACTION: matsubara to file a place holder bug for OOPS-788EB21 and assign it to carlos who is already investigating it.
<MootBot> ACTION received:  ACTION: matsubara to file a place holder bug for OOPS-788EB21 and assign it to carlos who is already investigating it.
<matsubara> flacoste, can you take a look at the oops in 196661 and check if it was fixed by 191074? If yes, I'll set the status to Invalid.
<salgado> matsubara, that sounds like a low priority one to me
<matsubara> I need to investigate OOPS-788EC5, it seems related to bug 195809
<ubotu> Bug 195809 on http://launchpad.net/bugs/195809 is private
<matsubara> ACTION: matsubara to investigate OOPS-788EC5 and confirm if it's related to 195809, if not file a new bug.
<Rinchen> [ACTION]  matsubara to investigate OOPS-788EC5 and confirm if it's related to 195809, if not file a new bug.
<MootBot> ACTION received:   matsubara to investigate OOPS-788EC5 and confirm if it's related to 195809, if not file a new bug.
<matsubara> salgado: please set the status and add a rationale. thanks!
<Rinchen> matsubara, flacoste isn't around at the moment. Perhaps an email to him?
<salgado> matsubara, as you wish. ;)
<matsubara> Rinchen: ok. I'm done then. thanks
<salgado> matsubara, btw, you dupper!
<Rinchen> [ACTION] matsubara to email flacoste about oops in 196661  and check if it was fixed by 191074
<MootBot> ACTION received:  matsubara to email flacoste about oops in 196661  and check if it was fixed by 191074
 * salgado always wanted to say that
<Rinchen> [TOPIC] Critical Bugs (Rinchen)
<MootBot> New Topic:  Critical Bugs (Rinchen)
<Rinchen> [LINK] https://bugs.edge.launchpad.net/soyuz/+bug/192713
<Rinchen> bigjooles, how is this going?
<MootBot> LINK received:  https://bugs.edge.launchpad.net/soyuz/+bug/192713
<ubotu> Launchpad bug 192713 in soyuz "PPA packages fail to upload but build successfully" [Critical,In progress]
<Rinchen> er bigjools :-)
<Rinchen> I'm thinking about the electricity of the moment there
<mrevell> :)
<Rinchen> [LINK] https://bugs.edge.launchpad.net/soyuz/+bug/193656
<Rinchen> cprov, there's been no action on this for a week.
<MootBot> LINK received:  https://bugs.edge.launchpad.net/soyuz/+bug/193656
<ubotu> Launchpad bug 193656 in soyuz "Process-death-row procedure became very slow" [Critical,Triaged]
<cprov> Rinchen: I will assume it, we need another apt backport , this time in gutsy
<matsubara> salgado: is it a dupe?
<Rinchen> cprov, expecting the backport this week or next?
<salgado> matsubara, it is, with a single p
<cprov> Rinchen: yes, I know, that's my fault.
<matsubara> salgado: I mean, the distro mirror one?
<Rinchen> [LINK] https://bugs.edge.launchpad.net/malone/+bug/196125
<Rinchen> bjornt, how is this going?
<MootBot> LINK received:  https://bugs.edge.launchpad.net/malone/+bug/196125
<cprov> Rinchen: ASAP, mvo has it working in his PPA it's just a matter of copying it to gutsy and update lp-dep
<BjornT> Rinchen: i think it's considered a non-issue. i'll clarify with stub and update the bug report.
<Rinchen> cprov, ok, thank you
<Rinchen> BjornT, great! I like not having critical bugs :-)
<Rinchen> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<Rinchen> there are no proposed tags
<cprov> Rinchen: btw, do we recommend -backports to be enabled in our development environment ?
<Rinchen> cprov, I'm not aware of any recommendation either way there
<stub> You will need it for PG 8.3, so yes
<Rinchen> cprov, however I do use backports
<cprov> salgado: do you know ?
<cprov> salgado: or is it better to copy it from -backports to our lpdebs archive ?
<Rinchen> cprov, salgado - why don't we cover that in salgado's section
<salgado> cprov, well, we don't recommend it, but if we need anything from backports then we'll have to force people to do so
<Rinchen> [TOPIC] Operations report (mthaddon/herb)
<MootBot> New Topic:  Operations report (mthaddon/herb)
<mthaddon> Have migrated to new DB server(s) for production/demo
<mthaddon> Staging migration still in progress, expected complete tomorrow
<mthaddon> Will be updating documentation to match
<mthaddon> Expecting to work on packs updating on devpad this week
<mthaddon> That's it from me unless there are any questions
<thumper> yay packs
<Rinchen> mthaddon, packs tomorrow then?
<Rinchen> I also see that herb has the caching for bac due tomorrow. Is that still on schedule?
<mthaddon> Rinchen, I don't know if it'll be that quick, but sometime before next week's meeting
<Rinchen> I'll ask about that again in the RT section.
<Rinchen> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<stub> New hardware appears to be running happily. Timeouts have dropped, but please don't get lazy :-)
<stub> My PostgreSQL 8.3 support branch has landed, so people wanting to can play with Launchpad on PostgreSQL 8.3. DatabaseSetup has been updated.
<stub> Migration of Launchpad to PostgreSQL 8.3 goes:
<stub> 1) Developers running PostgreSQL 8.3
<stub> 2) Staging running PostgreSQL 8.3
<stub> 3) PQM running PostgreSQL 8.3
<stub> 4) Launchpad production database running PostgreSQL 8.3
<stub> There are no fixed or vague timeframes yet. We want to minimize the time taken to complete steps 2-4, whilst giving staging enough time to show up any issues, to avoid PG version specific code to slip through.
<stub> This means I don't think we should start step 2 until we have a version of PG 8.3 we are confortable trusting on production. In the past this has been the first or second point release.
<stub> That is all.
<Rinchen> stub, do we have a rough date for the future point releases?
<stub> Not really - it depends on how quicky bugs get fixed, and if there are any high priority ones that need doing sooner rather than later.
<stub> I would expect before hardy though, which is a natural point to make the switch over.
<Rinchen> hmm. Well, please do keep us informed. Thanks.
<stub> (as it avoids the need to get dapper backports)
<Rinchen> [TOPIC] Sysadmin requests (Rinchen)
<MootBot> New Topic:  Sysadmin requests (Rinchen)
<Rinchen> mthaddon, herb - RT 29897 - caching for bac
<mthaddon> thx, noted
<Rinchen> it was needed a week ago or so and currently has tomorrow as a new due date. It's blocking my closure of 1.2.2
<Rinchen> Thanks.
<Rinchen>  Is anyone blocked on an RT or have any that are becoming urgent?
<Rinchen> I take that as a good sign :-)
<Rinchen> [TOPIC] New packages required (salgado)
<MootBot> New Topic:  New packages required (salgado)
<salgado> if any of the branches you're working on right now  depends on any library which is not part of the launchpad-dependencies package, come talk to me
<salgado> stub, shall I make new packages depending po pg8.3?
<salgado> for hardy, that is
<salgado> that way we may be able to get some people testing. :)
<stub> salgado: PG 8.3 is available on gutsy too. It might be premature though to load up everyones boxes - opinions?
<cprov> salgado: okay, I'd rather add the new python-apt package in lpdebs repo and require the specific version in the lp-dep package
<cprov> salgado: it will be only required while we are using gutsy, hardy's version is good to go.
<salgado> cprov, can you give some background on this?
<salgado> stub, yeah, I also think it's too early to do that
<Rinchen> stub, I would not want to have technology risk our milestone goals for the next few cycles. Avoiding any issues there would help us meet our objectives.
<cprov> salgado: yes, python-apt version in gutsy has a memory leak in debExtract() method we use in upload-processor
<salgado> cprov, okay, let's talk about this later, then. I don't think this should be discussed in the meeting
<cprov> salgado: sure
<schwuk> we're having problems with python-apt under hardy in the hardware testing client as well
<schwuk> in fact we've stopped using it
<Rinchen> [ACTION] cprov and salgado to discus python-apt packaging in lpdebs
<MootBot> ACTION received:  cprov and salgado to discus python-apt packaging in lpdebs
<Rinchen> salgado, done?
<salgado> yep
<Rinchen> thanks
<cprov> schwuk: seriously ? let's chat about it later, okay ?
<Rinchen> [TOPIC] A top user-affecting issue (mrevell)
<MootBot> New Topic:  A top user-affecting issue (mrevell)
<mrevell> Couple of things have cropped up this week.
<mrevell> 1. We've had what appears to be an unusually high number of people who, it seems, don't understand that they are subscribed to the launchpad-users list.
<schwuk> cprov: cr3 has been doing the work - he's your best bet
<mrevell> The launchpad-users sign up page is quite explicit in telling people that it's not for ShipIt requests etc, thanks to Kiko's big warning. Any suggestions for what else we could do to warn people that they're signing up to a mailing list will be gratefully received :)
<mrevell> 2. You've probably noticed the thread on launchpad-users about the use of real names in the Launchpad Beta Testers team. This has stirred some passions amongst a small but vocal number of the beta test team. The real names issue will, I believe, come up next week.
<mrevell> that's all from me, unless anyone wants to talk about these
 * Rinchen has emailed SteveA and Kiko about the real names item.
<mpt> Do ShipIt user tests on people who don't have English as their first language
<mpt> That would find the problem fairly quickly, I think :-)
<mrevell> mpt: Think we could do this in Prague?
<mpt> maybe
<mrevell> although UDS people are unlikely to be ShipIt users
<mpt> Yes, we might need to pull people off the street
<intellectronica> mpt: are you certain that these people are coming to the list from shipit?
<LarstiQ> mrevell: got a link to more info on the real names issue?
<mpt> intellectronica, not certain, one of them this morning didn't know what "Ubuntu" was
<mrevell> intellectronica: Some of them we can say certainly are, as they mention. others just seem a little lost and, as mpt says, one person didn't even know what Ubuntu was
<mrevell> LarstiQ: I'll dig it out
<mpt> LarstiQ, in this month's archive it's all the "RE: [Fwd: hggdh2 deactivated by matthew.revell]" messages
<intellectronica> it may be worth following up on a few of the cases. find someone that can talk to them in their language and understand how and why they found themselves on the list
<Rinchen> poolie has mentioned that it might be to the beta test item on the front page I added this cycle
<mrevell> LarstiQ: https://lists.ubuntu.com/archives/launchpad-users/2008-February/003234.html
<Rinchen> however I have some doubts about that because if you can read the instructions on how and why to signup, it should be obvious to follow the unsub instructions in the emails
<mrevell> Rinchen: There isn't a link to the mailing list in the help page that links to though. Interesting idea, though.
<Rinchen> I wonder if a LoCo has encouraged folks to sign-up
<mrevell> I'll certainly mail some of the people to see if we can find out what's going on.
<intellectronica> Rinchen: exactly. i find it a bit suspicious. could it be that someone is subscribing them and they just click the link in the confirmation email, for example?
<Rinchen> mrevell, if you have time, you might email a few of them asking how they got on the list.
<mrevell> Rinchen: Yeah, I'd love to know what's going on.
<Rinchen> I can't help relating -users recent activity to a social networking list.  "Go signup and get karma"
<Rinchen> anyway, thanks mrevell
<mrevell> thanks all
<Rinchen> and new for this week...
<Rinchen> [TOPIC] Doc Team report (mrevell)
<MootBot> New Topic:  Doc Team report (mrevell)
<mrevell> Two opportunities to stun you into silence with my whit
<mrevell> err. wit
<mrevell> Anyway
<Rinchen> and charm :-)
<mrevell> Hello, welcome to the first doc team report!
<mrevell> The Launchpad Documentation Team now has 19 direct members and I'm planning to hold the first team meeting in week 2 of the 1.2.3 cycle. During that, I plan to find out what everyone wants from the team and how we can move forward.
 * thumper claps
 * mrevell bows
<mrevell> Additionally, this week I've been working on the new Launchpad user guide. You can see drafts of the "Your account" section at:
<mrevell> https://help.launchpad.net/YourAccount/NewAccount/Draft
<mrevell> https://help.launchpad.net/YourAccount/Branding/Draft
<mrevell> https://help.launchpad.net/YourAccount/ImportingYourPGPKey/Draft
<mrevell> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair/Draft
<mrevell> https://help.launchpad.net/YourAccount/Karma/Draft
<mrevell> https://help.launchpad.net/YourAccount/Merging/Draft
<mrevell> I'll be posting a new Teams section for review to the list shortly.
<mrevell> As always, I'm very grateful for any feedback. Even from mpt ;-)
<Rinchen> ouch
<mrevell> Next up on my list are the Projects and Bug Tracker sections of the documentation. I'll also be working on a new draft of the 2008 LP tour and working on an initial summer 2008 marketing plan with Gerry Carr while I'm in London next week.
<mrevell> hehe
<mrevell> :)
<gmb> Damned with faint praise there, mpt.
<Rinchen> mpt gets that a lot, you notice?
<mrevell> Damn, joke backfired.
<mrevell> Ah, I'm safe
<mpt_> Another thing that might help with #1 is to remember the Referer: for each person who turns up at the launchpad-users@ subscription page, and goes on to subscribe
<mrevell> Right, anyway, so if there are any help or docs issues that you have, please ping or mail me! Or grab me next week.
<mpt_> Then if they (even weeks later) post to launchpad-users@ showing that they don't want to be there, we could go back and look to see where they came from
<intellectronica> mpt_: we should already have this in our logs
<Rinchen> thanks mrevell for the doc report. I'm excited to see how the doc team progresses.
<mrevell> mpt_: That would be really cool. barry can we get that info out mailman easily? Or is it at the web server level?
<mrevell> Thanks for your ears.
<carlos> intellectronica: I don't think is easy to map apache logs with user subscriptions...
<flacoste> i suck
<gmb> Random...
<intellectronica> carlos: no, but we can see how people arrive at the page
<flacoste> completely forgot about this meeting
<carlos> intellectronica: sure, but that would be a huge list
<Rinchen> [IDEA] use referrer on -users to see where the subscriptions are coming from
<MootBot> IDEA received:  use referrer on -users to see where the subscriptions are coming from
<stub> intellectronica: If that is all you want, then we probably already have it with the apache log reports.
<intellectronica> stub: that was exactly what i said :)
<stub> awstats or whatever we use atm
<mpt_> Possibly it would involve altering the subscription form to contain a hidden input field equal to the Referer
<mrevell> Do we have a stats programme running on the mailman web interface?
<intellectronica> carlos: i doubt that it would be a long list. there will be a few common sources. webalizer or awstats will even make nice graphics showing which ones
<carlos> intellectronica: my point is that you cannot get from where did a user reach the mailing list
<carlos> just a list from where all users come
<intellectronica> carlos: no, not specific users. to do that we'll have to record the information, you're right
<stub> mrevell: Don't know as I can't remember the URL to the stats pages, but it is easy enough for the admins to add if it isn't there already.
<mrevell> stub: Cool, I'll ask one of the IS chaps.
<Rinchen> mrevell, done?
<mrevell> yup, thanks
<Rinchen> thanks
<Rinchen> [TOPIC] Blockers
<MootBot> New Topic:  Blockers
<Rinchen> [AGREED] Releases Team: mpt blocked on foundations. Email discussion in progress.
<MootBot> AGREED received:  Releases Team: mpt blocked on foundations. Email discussion in progress.
<thumper> Code team: not blocked
<jtv> Translations: Not blocked.
<cprov> Soyuz team: not blocked
<flacoste> Foundations: Not blocked
<adeuring> hwdb: not blocked
<Rinchen> bac?
<BjornT> Bugs Team: a bit blocked on getting feedback about requirements from kiko
<Rinchen> [AGREED] Bugs Team: a bit blocked on getting feedback about requirements from kiko
<MootBot> AGREED received:  Bugs Team: a bit blocked on getting feedback about requirements from kiko
<bac> Commercialization team: not blocked
<Rinchen> the agreed makes it stand out in the summary
<Rinchen> thanks
<Rinchen> and thus ends another on-time meeting
<mrevell> thanks all!
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
<Rinchen> #endmeeting
<MootBot> Meeting finished at 18:42.
<carlos> thanks
<jtv> Rinchen: thank you
<carlos> cheers
<intellectronica> thanks, Rinchen for a great meeting
<thumper> Rinchen: thanks
<schwuk> thank Rinchen
 * sinzui notes that one should not use the can spray glue next to the can of air to fix a sticky keyboard.
<Rinchen> intellectronica, yeah I only made one goof  :-)
<intellectronica> Rinchen: that's not goofing. that's what we call "personal style"
<Rinchen> intellectronica, ah I see!
 * mwhudson off to make coffee
 * gmb off to eat food
<danilos> Rinchen: my guess would be that most shipit users are coming from loginservice-email-sent.pt (i.e. after they have created an account, launchpad-users list is mentioned there)
<adeuring> </quit leaving
<cprov> salgado: let's have a phone call to talk about the python-apt dependency ?
<jtv> danilos: we could at least check if those people have accounts...
<jtv> if they don't, something really weird is going on.
<jtv> like spammers filling out the form hoping it'll send their messages to people.
<danilos> jtv: well, they might not be activated yet, because that page specifically advises them to read their email and then activate their accounts
<Rinchen> danilos, interesting....
<jtv> danilos: but those in-progress accounts would still show up somewhere, right?  It'd give us even more information.
<danilos> jtv: yeah, but I don't want to discuss too much details, then somebody will ask me to do it :)
 * jtv shuts up
<danilos> :)
<salgado> cprov, can it be tomorrow?
<cprov> salgado: okay, np, I will ping you tomorrow.
<salgado> cprov, you might want to subscribe to bug https://bugs.edge.launchpad.net/meta-lp-deps/+bug/193324, btw
<ubotu> Launchpad bug 193324 in meta-lp-deps "Require dpkg and lzma dependencies on launchpad-dependencies pacakge" [Undecided,New]
<cprov> salgado: right, thanks
#launchpad-meeting 2009-02-25
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
<gmb> me
<gmb> ... and apparently no-one else...
<bac> me
<mars> me
<gary_poster> me
<danilos> me
<flacoste> me
<rockstar> me
<salgado> me
<adeuring> me
<sinzui> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> * Roll call
<barry>  * Reviewers to enforce bug<->branch linking for all non-trivial branches (intellectronica)
<barry>  * Determine official preference, if any, of Storm usage: And(expr, expr) vs. expr & expr, Gary
<barry>  * Determine why _get_store uses protected spelling, and if we think it should, Gary
<barry>  * Merge proposals and cover letters (barry)
<barry>  * Using OCR for JavaScript reviews (mars)
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  * Mentoring update
<barry>  * Action items
<BjornT> me
<bigjools> me
<barry> intellectronica: ping
<barry> i guess we'll skip his topic for now
<barry> [TOPIC]  * Determine official preference, if any, of Storm usage: And(expr, expr) vs. expr & expr, Gary
<MootBot> New Topic:   * Determine official preference, if any, of Storm usage: And(expr, expr) vs. expr & expr, Gary
<barry> gary_poster: you're up
<gary_poster> Storm supports both imported And/Or (e.g., ``And(expr, expr[, expr]*)``) and overloaded binary operators (e.g., ``(expr) & (expr) [& (expr)]*``).
<gary_poster> See https://storm.canonical.com/Manual#AND .
<gary_poster> In our codebase I see And/Or, not binary operators.
<gary_poster> I have a branch going through review that uses the binary operators.
<gary_poster> My opinions...
<gary_poster> Positives for binary operators:
<gary_poster> - no imports
<gary_poster> - readable
<gary_poster> Negatives for binary operators:
<gary_poster> - a hack (they should be able to overload boolean operators but Python does not support)
<gary_poster> - because of hack, precedence is wrong (e.g., ``Class.foo==42 & Class.bar=='kumquat'`` does not work; you need ``(Class.foo==42) & (Class.bar=='kumquat')``).
<gary_poster> Maybe some will not find it as readable and stick "less readable" in the negatives.
<gary_poster> So, what is status of using overloaded binary operators for combining Storm expressions?  Preferred, rejected, allowed, or allowed-while-we-evaluate?
<gary_poster> (done, in case it wasn't clear :-) )
<barry> gary_poster: sorry i think they're less readable :)
<danilos> agreed
<gmb> Ditto.
<barry> gary_poster: and the precedence problem worries me
<BjornT> -1 on using binary operators
<gary_poster> gary_poster: cool.
<bigjools> precendece is my main issue
<adeuring> -1 -- the precende problem can cause nightmares...
<gary_poster> (nightmares--well, not really, at least IME--you just get a clear failure)
<gary_poster> ok, so done?
<barry> gary_poster: i think so, sorry ;)
<gary_poster> np
<intellectronica> me (sorry for lateness - new wireless router)
<allenap> me
<barry> intellectronica: we'll come back to your topic
<barry> [TOPIC]  * Determine why _get_store uses protected spelling, and if we think it should, Gary
<MootBot> New Topic:   * Determine why _get_store uses protected spelling, and if we think it should, Gary
<danilos> intellectronica: it has some serious latency, you might want to consider going back to the old one
<gary_poster> Last week we stated that we should not have public methods spelled as protected methods (_*).
<gary_poster> I noticed that our SQLBase bits seem to rely on ``_get_store``.
<gary_poster> This method can be convenient even when using Storm spelling.  It is shorter to use than the full utility call, and it specifies which store and flavor to use.
<gary_poster> I'm guessing that changing this means changing our SQLBase code?
<gary_poster> I'm inclined to put changing this as a bug report in LP.
<gary_poster> Agree/appropriate/possible?
<gary_poster> (Or maybe I misunderstand about this being needed by our SQLBase stuff?)
<gary_poster> (done)
<barry> gary_poster: have you seen abentley's branch?
<danilos> is this not about storm code?
<gary_poster> barry: no
<flacoste> so i asked jamesh
<flacoste> and he said that the only reason for having an underscore there
<flacoste> is that it's not part of the SQLObject API
<flacoste> but I don't think we care now
<barry> abentley has a new storm base class for convenience.  i think jml was reviewing that but i don't know the status of it
<barry> it provides a convenient way to get the store
<barry> flacoste: i think you're right.  plus we want to get rid of the sqlobject api anyway don't we? :)
<flacoste> well
<flacoste> sometime in the future
<flacoste> but it's a lot of work
<flacoste> and not that practical either
<flacoste> and the bare storm API is a pain
<gary_poster> heh
<flacoste> so SugarStorm is nice
<barry> we can do it piecemeal too right?
<flacoste> more or less
<barry> right, that's what i'm thinking
<flacoste> because of the incompatibility between the resultset interface
<rockstar> flacoste, bare Storm needs improvements, but if we avoid those improvements, that's a tragedy.
<flacoste> and we use these for unions
<flacoste> i have great hope for abentley's SugarStorm
<flacoste> or watherver it's called
<gary_poster> agree with rockstar.  If this is a Storm thing, then let's change this in Storm.  This seems like it should go lower than SugarStorm
<flacoste> we should probably make it easy to combine SQLObject and Storm ResultSet
<flacoste> so that we aren't block by the incompatibility
<flacoste> because when you start converting one object
<barry> flacoste: +1 if possible
<flacoste> which uses UNION
<flacoste> it becomes an never-ending tasks
<flacoste> I once tried converting Person to use only the Store API
<flacoste> and gave up because the branch was inflating faster than Argentina's inflation
<gary_poster> heh
<rockstar> :)
<barry> flacoste: 70 hits for 'union|UNION' in lib/c/l/database
<bigjools> I got caught by the union thing
<bigjools> would be great to fix that
<barry> flacoste: well, person might not be the best first choice :)
<flacoste> well, i was there
<flacoste> and it started fine :-)
<barry> :-D
<flacoste> and needed to use storm for some thing
<flacoste> anyway
<gary_poster> ( well, the Person anecdote was intended as an example of Storm API not being as convenient, right?)
<barry> so, back to gary's specific question: what to do about _get_store()?
<salgado> gary_poster, flacoste, will we still want obj.get_store() after stub's landed his sso branch?  it includes some IStore adapters for our classes
<gary_poster> salgado: if we *have* to have these helper static methods anyway, and they are so easy to use, shouldn't we just use them?
<gmb> herb: Okay, can you apply https://pastebin.canonical.com/14232/ and then apply https://pastebin.canonical.com/14233/ please?
<gmb> Heh.
<gary_poster> gmb: hee hee
<gmb> Wrong channel.
<abentley> salgado: I certainly prefer class methods over zope stuff where either solution works.
<gary_poster> agree
<salgado> fair enough.  I prefer that too
<gary_poster> so to change this is this in our code base or in Storm?  flacoste ?
<gary_poster> 'cause if it is in Storm, may or may not happen ...
<abentley> gary_poster: niemeyer was not receptive to my suggestions.
<gary_poster> abentley: yes, definitely observed
<barry> abentley: did jml finish the review of your branch?
<abentley> barry: No.  He asked for changes, I submitted a revised version, then nothing.
<barry> abentley: i'll ping him tonight about it
<barry> abentley: but you should too :)
<abentley> barry: I've got plenty of other stuff to work on, so I'm not fussed.
<barry> gary_poster: have we resolved your topic? ;)
<gary_poster> barry: not really, unless we say that, because there wasn't much clamoring of agreement with me that this ought to be changed, we should just ignore it.
<gary_poster> but then, can I use _get_store?
<barry> gary_poster: you can always add an alias for get_store() and use that
<gary_poster> My branch does.  flacoste thouht it was reasonable at the time.
<barry> e.g.:  get_store = _get_store
<barry> sounds good to me
<salgado> should it not be getStore(), though?
<gary_poster> and we tack that on to all our classes?
<barry> salgado: dang, yeah :/
<barry> gary_poster: you had another topic?
<gary_poster> heh, yeah.  one sec, lemme get the paste
<gary_poster> I miss the old bzr review plugin a bit because it enforced our policies.
<gary_poster> In particular, the lint is not being used regularly, and the information about pre-impl call is often missing in reviews I've done.
<gary_poster> I have a quick example about the ``make lint`` issue.
<gary_poster> I noticed when I had to manually switch my most recent branch over from devel to db-devel, and merge, that ``make lint`` had apparently not been run for many of the branches.
<gary_poster> I had to do a lot of cleaning up on the merged code to make ``make lint`` happy.  The majority of the complaints were real.
<gary_poster> We're building generic bzr tools AIUI (bzr send), but our policies are not generic, and enforcing them is valuable.
<gary_poster> I'm inclined to want a lp-specific bzr plugin that defers the heavy lifting to the bzr send plugin code, but is more specific to what we want.
<gary_poster> I also wonder if ec2test could help with the linting, but that's not as clear to me.
<gary_poster> The general idea would be that, if you use -s to submit to PQM, it would make sure that ``make lint`` was happy.
<gary_poster> However, with the old review plugin, there was a way to say "yeah, yeah, make lint is on crack for that complaint."  We would need that here too.
<gary_poster> We could put it in command line options but would prefer to have it in a file.  Not sure where the file would go.  But that's an implementation detail.
<gary_poster> So: IRT my general observation of having regressed a bit in our process because of missing automation for linting and message regexes: agree/disagree?
<gary_poster> And then furthermore, if you agree that we have regressed, what should we do to improve?
<gary_poster> (done)
<bigjools> can we fix lpreview to just use lpsend?
<gmb> There's no reason we can't hack the existing review plugin to do lint + cover letter and then hand off to bzr send.
<gmb> Well, I don't *think* there's any reason, anyway.
<barry> gary_poster: that dovetails with my topic.  if we used the standard cover letter template for mps at least people would have to willfully ignore linting and pre-imps
<gary_poster> gmb: that's the kind of thing I'm talking about, yeah
<bigjools> gmb: great minds think alike
<gmb> abentley would know better than I.
<abentley> gmb: Yes there is.  There's no way to specify a message body
<gmb> abentley: That's what I was afraid you were going to say.
<abentley> gmb: It's not that 'bzr send' couldn't, it's that it's not implemented yet.
<barry> abentley: i wonder if there was some $EDITOR hack we could use for that
<gmb> barry: send just passes over to the MUA, so I'm not sure that would work.
<abentley> barry: If we want to force everyone to use mail_client=editor, perhaps.
<barry> abentley: yeah, that's what i meant.  and it would just be for lp branches, so location.conf could override
<intellectronica> abentley: i use gmail, and so i benefit from jamesh's plugin. having to use EDITOR will make like hard for me
<barry> abentley: not that i have any concrete ideas.  just wonderin'
<sinzui> I would disable such a feature because I start my cover letter when I create my branch
<gary_poster> barry: yeah, some kind of automated/enforced-ish standard template would be fine with me too.  It's not as tight as the lpreview approach, but something is better than nothing, and might be sufficient
<danilos> it'd be nice for lpsend to actually work with my name first, I have to manually paste the cover letter anyway
<barry> sinzui: so do i
<abentley> danilos: Work with your name?
<BjornT> danilos: +1 :)
<gary_poster> so the temolate thing seems like an insufficient idea
<mars> danilos, +1 as well :)
<BjornT> abentley: some of us get a unicode error when using lpsend
<abentley> BjornT: Not from send, from Launchpad, right?
<danilos> abentley: right
<BjornT> abentley: right
<abentley> So that's not a send bug, and AIUI, work has been done to fix it this cycle.
<abentley> I've said before, but I guess I have to say again, I think bzr send should support a hook that we can use to plug in the process stuff from lpreview.
<barry> abentley: what are you waiting for? :)
<gary_poster> abentley: (I don't remember hearing that before) +1
<abentley> barry: a free moment.
<barry> abentley: those are so overrated
<gary_poster> ok, so maybe this is another one of those "...and we descend into silence" moments, this time because we agree that something needs to be done but don't have the time.
<gmb> abentley: Is there a bug for updating send to add that hook?
<abentley> gmb: I don't know.
<barry> gary_poster: yep. seems like time is better spend on send rather than lpreview though, so that's something
<mars> gary_poster, a very astute observation :)
<gary_poster> :-)
<barry> gary_poster: will you check to see if there's a bug open on adding a hook for bzr send?
<gary_poster> barry: ok
<barry> [ACTION] gary_poster will check to see if there's a bug open for adding a hook to 'bzr send' and submit one if there isn't
<MootBot> ACTION received:  gary_poster will check to see if there's a bug open for adding a hook to 'bzr send' and submit one if there isn't
<gary_poster> barry: IRT my previous topic: sorry, but I was not clear.  so can I just use _get_store for now, and move on?
<barry> gary_poster: add a getStore() alias if possible and use that
<gary_poster> ...ok
<barry> thanks
<gary_poster> sure, thanks everybody
<barry> [TOPIC]  * Merge proposals and cover letters (barry)
<MootBot> New Topic:   * Merge proposals and cover letters (barry)
<barry> so along the lines of gary_poster 's last topic...
<barry> i notice that not everyone is using the standard cover letter template.  some people don't use any template
<barry> should we enforce that?  (updating the template if necessary)
 * mars hides
 * gary_poster hides
<barry> not blaming anyway, just wondering!
 * danilos hides behind gary
<gary_poster> :-)
<gary_poster> lol
 * BjornT doesn't know where the standard template is located
<barry> if the template isn't useful or overkill, let's say so
<danilos> I don't know where it is either, though
<abentley> I don't think we should enforce a template.  There are lots of times it doesn't make sense.
<barry> https://dev.launchpad.net/QuickCoverLetterTemplate
<BjornT> i think we should get bzr send to use the template. then people will automatically use it, unless they explicitly choose not to
<barry> well, the diff output could be removed now
<mars> BjornT, +1
<barry> abentley: i think the template usually makes sense though
<mars> a new plugin for bzr send that adds a --template option?
<gary_poster> I must admit, I kind of like using lp TTW to request reviews
<gary_poster> but you know, if "we don't do that" that's ok
<barry> gary_poster: you could still use the template :)
<gary_poster> but seems a bit of a shame, since we have a TTW interface
<mars> gary_poster, that's a different problem - communicating a project's review preferences through the web API
<abentley> barry: I don't.  I find I'm usually writing the same thing under several headings.
<mars> oops, nix the 'API' from that last statement
<gary_poster> barry: sure...which is where?  and how is policy for *that* plugged in?
<gary_poster> (I mean, in the TTW interface)
<gary_poster> oh sorry
<barry> abentley: really?  maybe there's some confusion about what's intended for each section?
<flacoste> i preferred the old template
<flacoste> and i still use it
<barry> gary_poster: well, i just mean that you could paste the cover letter into the text area
<flacoste> i run bzr write-cover-letter
<abentley> Well, a bit, but it generally just gets in the way of a natural description of the change.
<flacoste> and then :r cover.txt
<gmb> flacoste: Me too.
<flacoste> when bzr send fires my editor
<gmb> Well, for non-trivial branches, anyway.
<mars> :r ?
<flacoste> mars: i see you aren't enlightened
<flacoste> vim powers!
<danilos> mars: it's likely just some vi crap, ignore it :)
<mars> lol
<mars> ah
<barry> dang, we're almost out of time.  let's drop this for now because i'd like to give mars's topic a shot
<barry> [TOPIC]  * Using OCR for JavaScript reviews (mars)
<MootBot> New Topic:   * Using OCR for JavaScript reviews (mars)
<mars> barry, I'll be brief
<barry> mars: thx
<mars> Hi everyone
<mars> Last Monday the AJAX team decided to expand the scope of JavaScript reviews in Launchpad.
<mars> Any OCR should be able to pick up a JavaScript review, if they feel comfortable doing so.  We just ask that the review be unofficially mentored by one of the sprint attendees.
<mars> These people were at the AJAX sprint, or on the AJAX team, and can mentor a JavaScript review: flacoste, mars, sinzui, Edwin, cprov, noodles, intellectronica, rockstar, danilo, and jtv
<mars> Also, feel free to ask me if any questions come up during the review.
<mars> that's all
 * allenap discovers that TTW means Table-Top Wargaming
<gary_poster> lol
<gary_poster> Through-the-web was how I've heard it used, and my intent :-)
<bigjools> I thought it was ruder
<barry> mars: thanks
<barry> any comments on mars's request or should we break?
<sinzui> I don't qualify to be a YUI/Windmill reviewer. I just abandoned using windmill to  test YUI + GMap. I'm back to despising YUI for reinventing everything to make mashups nigh impossible.
<gary_poster> write it down someplace
<allenap> Sounds like a good request.
<intellectronica> barry: mention my item, since i don't think it requires much discussion :)
<mars> sinzui, fair enough
<barry> intellectronica: ah, sorry
<sinzui> PS. I hate GMap too
<barry> [TOPIC]  * Reviewers to enforce bug<->branch linking for all non-trivial branches (intellectronica)
<MootBot> New Topic:   * Reviewers to enforce bug<->branch linking for all non-trivial branches (intellectronica)
<mars> sinzui, I would love it if you could write a ranting email about that statement though
<barry> intellectronica: +1 :)
<gary_poster> intellectronica: (1) I assume up mean --fixes=lp:XXX?
<gary_poster> (2) how do we check that?
<barry> gary_poster: or you can do it TTW :)
<intellectronica> gary_poster: either that, or you can do it ttw
<gary_poster> ah ok
<intellectronica> heh
<barry> heh
<gary_poster> :-)
<sinzui> mars: I was going to bring it up in the meeting, but my thoughts are not collected.
<intellectronica> and you can check it ttw, or do it after the fact
<mars> gary_poster, require a hook in pqm-submit, --no-fixes has to be explicitly set for this branch?
<mars> kinda like explicitly setting --no-lint
<barry> okay, so apologies for going over.  thanks everybody and have a good day
<intellectronica> mars: the thing is, --fixes is on commit, not on pqm submit
<intellectronica> thanks barry
<barry> #ENDMEETING
<MootBot> Meeting finished at 09:49.
<abentley> intellectronica: Not every branch related to a bug fixes that bug.  Some are incremental branches.
<intellectronica> abentley: i agree. but they can still be linked to the bug
<abentley> intellectronica: They can't be --fixes.
<mars> sinzui, ok, but do let me know when you have something put together.  I'd love to read it.
<intellectronica> abentley: right, but they can be linked ttw with a comment explaining what is their relation to the bug
<sinzui> mars I certain will
#launchpad-meeting 2009-02-26
<matsubara> #startmeeting
<MootBot> Meeting started at 09:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<henninge> me
<Ursinha> me
<matsubara> Ursinha, flacoste, bigjools, intellectronica, herb
<bigjools> me
<herb> me
<matsubara> bac, ping
<flacoste> me
<Ursinha> matsubara, already answered
<intellectronica> me
<matsubara> rockstar, hi
<rockstar> me
<rockstar> matsubara, hi
<bac> me
<matsubara> ok, stub can join later. everyone else is here.
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (DBA contact)
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>  * stub to investigate the fix to avoid staging restore problems
<matsubara>  * matsubara to chase rockstar about a fix for OOPS-1138CEMAIL12
<matsubara>     * asked jml about this. It's bug 326056 and had importance raised.
<matsubara>  * cprov and bigjools to investigate OOPS-1145EA14
<matsubara>  * Ursinha to file bugs:
<matsubara>     * Bug 333072: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1143EB189
<ubottu> Launchpad bug 326056 in launchpad-bazaar "OOPS on BadStateTransition when reviewing code by mail" [High,Triaged] https://launchpad.net/bugs/326056
<matsubara>     * Bug 333071: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1145EA14
<ubottu> Launchpad bug 333072 in soyuz "AttributeError OOPS on Build:+index" [Undecided,Invalid] https://launchpad.net/bugs/333072
<ubottu> Launchpad bug 333071 in soyuz "AssertionError OOPS on +copy-packages" [High,Triaged] https://launchpad.net/bugs/333071
<bigjools> 333072 is invalid
<matsubara> bigjools, any news about 333071?
<bigjools> yes, it's not too serious, we've set it for 2.2.3
<bigjools> it's a corner case in the copying
<bigjools> despite the doom-mongering error message
<matsubara> ok. thanks bigjools
<matsubara> [action] matsubara to chase stub about staging restore problems
<MootBot> ACTION received:  matsubara to chase stub about staging restore problems
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
 * matsubara hands Ursinha the mic
 * Ursinha looks
 * rockstar runs
<Ursinha> registry, foundations, code and bugs: oopses for you
<Ursinha> Registry:-
<Ursinha> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1153E919
<Ursinha> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1153A1135 (or foundations, not sure)
<Ursinha> Foundations:-
<Ursinha> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1153D667
<Ursinha> Code:
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153E919
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153A1135
<Ursinha> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1152XMLP1
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153D667
<Ursinha> Bugs:
<Ursinha> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1152EA162
<Ursinha> ~
<Ursinha> rockstar, ha!
<Ursinha> rockstar, have you seen this one: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1152XMLP1?
<rockstar> Ursinha, looking at all of them now.
<Ursinha> rockstar, you can just look at code's one :)
<Ursinha> sinzui, hi
<Ursinha> sinzui, I'm not sure if https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1153A1135 is foundations or registry
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153A1135
<matsubara> Ursinha, looks like registry
<intellectronica> Ursinha: strange. do you see lots of those?
<bac> Ursinha: yes, looks like registry
<Ursinha> intellectronica, no, actually not
<Ursinha> intellectronica, but never saw one of those before
<Ursinha> so better bring to attention
<matsubara> intellectronica, Ursinha that one looks like caused by the rollout
<sinzui> Ursinha I don't know the answer either. I will look into it and assign it. I suspect salgado-afk is working on
<Ursinha> matsubara, even in the time it happened?
<intellectronica> matsubara: i also thought so
<intellectronica> but it is quite early
<Ursinha> intellectronica, I've discarded the rollout possibility because of its timestamp
<Ursinha> sinzui, thanks for that
<matsubara> yeah, too early to be caused by the rollout.
<Ursinha> intellectronica, can you take a look then, please?
<rockstar> Ursinha, I'll have to investigate our oops.  It's the XML-RPC server, and it requires the sacrifice of a virgin goat.
<matsubara> check OSAs incident log to see if something happened during that time
<intellectronica> so, this isn't really a bugs oops, but i don't know whether it's rollout-related or not. fwiw it's more than three hours before rollout, so it's hard to see how it would be related
<Ursinha> rockstar, oh, I have a bunch here in my backyard if you need some
<rockstar> Ursinha, :)
<Ursinha> intellectronica, I'll do what matsubara suggested
<matsubara> [action] ursinha to check OSAs incident log to help identify cause of OOPS-1152EA162
<MootBot> ACTION received:  ursinha to check OSAs incident log to help identify cause of OOPS-1152EA162
<Ursinha> thanks intellectronica and matsubara
<matsubara> [action] rockstar to investigate xmlrpc oops OOPS-1152XMLP1
<MootBot> ACTION received:  rockstar to investigate xmlrpc oops OOPS-1152XMLP1
<Ursinha> flacoste, hi
<henninge> Translations is happy, that POFile:+translate dropped from the timeout top ten now ..
<henninge> btw
<henninge> ;)
<Ursinha> henninge, indeed, congrats to translate team :)
<Ursinha> translations
<Ursinha> there he is :)
<henninge> Ursinha: thank you, I will pass it on.
<Ursinha> sinzui, about the other oops
<stub> Sorry - on a call and didn't realize the time
<sinzui> bac: can you look at it.
<bac> Ursinha: they seem to be related (acting for sinzui today)
 * sinzui is in another meeting
<flacoste> hmm
<flacoste> i'd say registry
<bac> yes, i think registry for both
<flacoste> Ursinha are you talking about OOPS-1153A1135?
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153A1135
<Ursinha> bac, hi :) so, can you take a look in both oopses? do you need me to file bugs about them?
 * Ursinha looks
<bac> Ursinha: yes i'll look at them both
<bac> i can open the bugs
<bac> unless you need the karma
<Ursinha> flacoste, no, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1153D667
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153D667
<Ursinha> bac, haha, no
<flacoste> Ursinha: that's also a registry query
<Ursinha> [action] bac to file bugs and take care of https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1153E919 and https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1153A1135
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153E919
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153A1135
<matsubara> [action] bac to file bugs for OOPS-1153E919 and OOPS-1153A1135
<MootBot> ACTION received:  bac to file bugs for OOPS-1153E919 and OOPS-1153A1135
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153E919
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153A1135
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153E919
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153A1135
<bac> wow, y'all are insistent today!  :)
<Ursinha> :)
<Ursinha> flacoste, hm.
<Ursinha> thanks
<Ursinha> bac, can you take a look at that too?
<bac> which?
<Ursinha> promise not to paste the oops again
<Ursinha> bac, https://devpad.canonical.com/~jamesh/oops.cgi/1153D667
<Ursinha> I tried :)
 * bac looks
<bac> yes
<Ursinha> bac, thanks
<Ursinha> that's all from me from the oops land
<matsubara> [action] bac to also file a bug and take care of OOPS-1153D667
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153D667
<MootBot> ACTION received:  bac to also file a bug and take care of OOPS-1153D667
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1153D667
<matsubara> ok, thanks everyone.
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<Ursinha> there's one critical bug, though
<Ursinha> argh
<Ursinha> bad bad timing
<herb> shall I wait for the critical bug?
<Ursinha> herb, just a second, let me check with henninge
<matsubara> danilo is handling the critical bug, so won't duplicate what's in the bug report.
<matsubara> it's bug 334787
<Ursinha> matsubara, okay, if you say so
<ubottu> Launchpad bug 334787 in rosetta "Ubuntu packagers are not translation editors (assertion error)" [Critical,In progress] https://launchpad.net/bugs/334787
<matsubara> let's move on
<Ursinha> go ahead herb, thanks
<herb> 2009-02-20 - We had an issue that may have caused some users to experience intermittent outages on Launchpad. I worked with joey and flacosted to find the issue. joey's notes were sent to the list. I would be interested in hearing any updates we might have on this issue.
<herb> 2009-02-21 and 2009-02-22 - It appears we had bit of buggy code land on edge that caused a performance problem on both edge and production. The revision was backed out and I believe the code has been fixed.
<herb> 2009-02-26 - We rolled out 2.2.2 based on r7763
<herb> We continue to see problems relating to bug #156453 and bug #118625. So much so that we're going to start bouncing codebrowse regularly to hopefully head off any issues. I want to emphasize that this will be masking the problem and we really do need to find the root cause and fix it.
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Triaged] https://launchpad.net/bugs/156453
<ubottu> Launchpad bug 118625 in launchpad-bazaar "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/118625
<herb> Bug #260171 continues to creep up regularly (every few days). This is already morked as high and I know that mwhudson's plate is full with codebrowse issues, but can we get an update on this one?
<ubottu> Bug 260171 on http://launchpad.net/bugs/260171 is private
 * herb somehow managed to change flacoste into a verb.
<danilos> matsubara, Ursinha: I am running tests on the critical bug fix, will let you know once it has landed
<flacoste> i saw!
<bac> i've been flacosted!
<matsubara> danilos, thanks
<Ursinha> thanks danilos
<matsubara> rockstar, can you bring up the codebrowse issue to the code team?
<rockstar> matsubara, everyday.  :)
<matsubara> rockstar, thanks :-)
<rockstar> Codebrowse is being ACTIVELY worked on.  It'd be nice if we knew what the issues is.  Right now, we're just fixing things and hoping that was the problem.
<herb> rockstar: let the losas know if there is anything we can do to help.
<rockstar> herb, we certainly will.
<stub> Should we be bringing in any outside help to intrument, test and diagnose the issue?
<matsubara> herb, anything happened to the DB during the time of this OOPS-1152EA162?
<matsubara> or maybe stub might know ^
<herb> matsubara: nothing in the incident log.
<stub> matsubara: That is one of the connection reaper scripts kicking in
<herb> matsubara: I think that's also on the void between LOSAs.
<herb> ah, there we go.
<stub> We kill connections idle in a transaction more than a few hours (and should be more agressive), and appserver connections that have been in a transaction for more than 2 minutes.
<Ursinha> stub, I see
<matsubara> stub, ok. so if we start seeing too many of those, we have a problem somewhere and a few is kinda normal?
<stub> The notification gets sent to the error-reports list (where we can confirm that this is indeed what happened)
<matsubara> stub, aha. that's better. I'll chase the lp-errors for that one
<matsubara> s/lp-errors/lp-errors list/
<stub> If we see many of them, we have a problem. One is probably a problem - appserver requests taking two minutes on the db means we need to investigate why the normal timeout mechanisms didn't work.
<matsubara> [action] matsubara to look lp-errors list to determine cause of OOPS-1152EA162
<MootBot> ACTION received:  matsubara to look lp-errors list to determine cause of OOPS-1152EA162
<matsubara> right. thanks for the explanation
<stub> -1 second non-sql time, 0 seconds total time indicates a problem at the appserver? The request never got started?
<matsubara> I'll file a bug about that one and we can discuss there
<stub> hmm... might be a reconnection bug - perhaps the previous request handled by that thread got killed?
<stub> I don't know if we Retry on DisconnectionError exceptions, or if it is a good idea in all cases.
<matsubara> ok
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> and thanks herb and stub
<stub> New hardware exists and is being brought online by IS. I've realized I might need to tweak the db maintenance scripts (upgrade.py, security.py etc.) to cope with a third replica - I think it only copes with a single master and slave at the moment.
<stub> Staging can be moved by the LOSAs as soon as the hardware is available and they have time, which will move that load from the production systems.
<stub> I assume the rollout went fine as far as the db upgrade procedure goes.
<herb> I assume it did too. I didn't hear any complaints from my colleagues.
<matsubara> stub, great news! with the new hardware we won't have the staging restore problems anymore?
<herb> stub: what's the plan with the 3rd replica?
<stub> The staging restore problems should no longer be a problem.
 * herb feels like he missed something
<stub> herb: We can start by pointing half the appservers at the new slave when it is online. We really should get a connection pool/load balancer thingy though running like pgbouncer, pgpool 1 or 2.
<herb> stub: gotcha
<stub> herb: I realized just now though that upgrade.py won't apply patches to a third replica, which would be bad. So that needs to be fixed.
<herb> yeah. that's important.
<stub> Or actually, slonik may take care of all that. I need to confirm anyway.
<stub> I forget and it is too late for my brain :)
<stub> erm... late as in evening
<matsubara> all right. I guess that's all unless there are questions for stub
<matsubara> thanks stub
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 09:42.
<intellectronica> thanks matsubara
<flacoste> hey
<flacoste> matsubara: question
<flacoste> do we need a new roll-out?
<flacoste> and i think it applies to everyone here
<flacoste> anyone requires a new roll-out?
<matsubara> flacoste, I was on vacation and need t ocheck that
<matsubara> but I think there's at least danilos' bug to re roll
<bac> flacoste: i don't know of any issues for us
<danilos> matsubara, flacoste: yes
<stub> I thought it was policy to let enough bugs through qa to require a rerollout?
<flacoste> we're getting better at QA stub
<flacoste> even the code team weren't that late this cycle :-)
<matsubara> ok, so we'll need a re-roll for translations. need to check for the other teams, but so far, there's nothing on the radar
<stub> We need a counter somewhere - 'Launchpad has been running for n days without need to a release critical patch'
<Ursinha> stub, :)
<matsubara> I think that's all then. thanks everyone
<Ursinha> thanks matsubara
#launchpad-meeting 2010-03-03
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> Hi, welcome to the Launchpad Reviewers Meeting serving Europe and the Americas.  Who is here?
<rockstar> me
<noodles775> me too
<abentley> also me
<deryck> me
<henninge> me
<allenap> me
<bigjools> me
<bac> sinzui, EdwinGrubbs: ping
<bigjools> or should I say, moi aussi
<EdwinGrubbs> me
<sinzui> me
<bac> danilos: ping
<bac> Registry Team is here!
<adeuring> me
<intellectronica> me
<bac> gary_poster: ping
<gary_poster> bac: me
<bac> flacoste: ping
<flacoste> me
<bac> TLs ping your peeps
<mars> me
<henninge> bac: I did ping my TL
<salgado> me
<henninge> ;)
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bigjools> soyuz here
<al-maisan> me
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>    * YUI namespacing for lp specific items should start with lp (rockstar)
<bac>  * Peanut gallery
<bac> [topic] outstanding actions
<MootBot> New Topic:  outstanding actions
<bac> [topic] * gary_poster to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again 3-Mar.
<MootBot> New Topic:  * gary_poster to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again 3-Mar.
<bac> any progress gary_poster?
<gary_poster> let's take it off the list, and I'll ping when I do it
<gary_poster> that would be a no :-)
<bac> gary_poster: ok.
<bac> [topic] * salgado to update the wiki page to encourage reviews with sufficient context.
<MootBot> New Topic:  * salgado to update the wiki page to encourage reviews with sufficient context.
<salgado> oh, crap.  haven't done it yet
<salgado> sorry
<bac> np.  i keep meaning to harass people with items on mondays but i keep forgetting.
<bac> [topic] bigjools to start ML discussion about community reviewers and committers.  (done 24-Feb)
<MootBot> New Topic:  bigjools to start ML discussion about community reviewers and committers.  (done 24-Feb)
<bac> thanks bigjools -- you're our star today
<bigjools> I don't suck!
<bigjools> next action on you to talk to legal?
<bac> and on a related note:
<bac> [topic] * bac to seek opinion of IS and Legal wrt community reviewers and committers. (due 10-Mar).
<MootBot> New Topic:  * bac to seek opinion of IS and Legal wrt community reviewers and committers. (due 10-Mar).
<bac> i agreed to do this task yesterday but haven't gotten to it yet.
<danilos> bac, do you want it to be an action or a topic?
<bac> martin pool made the reasonable request that we/I write a statement on the wiki about the fact we're looking into the issue in the interim
<bac> [action] bac to update wiki re: interim status of community reviewers and committers
<MootBot> ACTION received:  bac to update wiki re: interim status of community reviewers and committers
<bac> danilos: i use -topic- for old items and -action- for new ones.  not that it matters much as mootbot is mostly useless
<bac> new stuff
<bac> [topic]  YUI namespacing for lp specific items should start with lp (rockstar)
<MootBot> New Topic:   YUI namespacing for lp specific items should start with lp (rockstar)
<bac> rockstar has sacrificed his morning bike ride to be with us today
<rockstar> Yes, but I would half-assed the ride anyway.
<deryck> he'd only get hit by a car anyway ;)
<deryck> hi rockstar
<bigjools> step away from the car deryck
<deryck> heh
<rockstar> So the current rule in YUI namespacing for launchpad is to start with the app it's being used on.
<danilos> rockstar, good morning, I'd be +1 on your suggestion
<danilos> (not that I heard it fully :)
<rockstar> I think that's a little inconsistent with the way we precede lazr-js widgets with lazr.
<rockstar> So I propose that javascript namespaces start with lp.
<mars> rockstar, do you have an example of the old way, and the new way?
<rockstar> That way, if/when we start using third party widgets (yes please), there's no confusion which ones, are lp specific.
<intellectronica> +1
<intellectronica> what about existing code?
<rockstar> mars, no, unless you count what we have as the old way, and what I have sitting in a branch as the new way.
<rockstar> intellectronica, I assume we migrate as we can.  There are already open bugs that EdwinGrubbs filed because namespaces are wrong is some places already.
<bac> it's a lovely suggestion rockstar.  i wish you'd made it about a month ago...  :)
<rockstar> I should also mention that I'm in the process of doing away with lib/canonical/launchpad/javascript.
<bac> EdwinGrubbs: how many of those bugs have been done?
<intellectronica> rockstar: you rock
<EdwinGrubbs> bac: I know that I did the one for the registry. I don't know about any of the other ones except that rockstar worked on one which I reviewed, so the inconsistencies between the ways we completed it are fortunately being brought to the meeting.
<intellectronica> star
<rockstar> bac, we talked about this change at the lazr-js sprint, but apparently it got changed before it made it to the reviewers.
<bac> any other thoughts?
<rockstar> I'd be happy to help other teams get their javascript in order.
<bigjools> yes please :)
<bac> rockstar: thanks
<rockstar> (specifically the teams that have no javascript)
<rockstar> :)
<noodles775> lol
<bigjools> lol
<bac> so, it looks like we're in favor of the change.
<bac> thanks for the idea and bringing it up rockstar
<deryck> I'm +1 and we still have the other renaming for bugs to do anyway.
<rockstar> deryck, I'll just comment on your bugs with the new change.
<deryck> rockstar, excellent, thanks!
<bac> rockstar: can i get you to update he existing bugs EdwinGrubbs opened and open new ones for the apps that have already been converted?
<rockstar> bac, yeah,  I committed to that at the UI meeting when I first proposed this.
<rockstar> Also, updating the style guide.
<bac> [action] rockstar to update bugs to reflect new naming convention and will update the style guide
<MootBot> ACTION received:  rockstar to update bugs to reflect new naming convention and will update the style guide
<bac> [topic] peanuts
<MootBot> New Topic:  peanuts
<bac> anything to discuss that wasn't on the agenda?
<noodles775> New reviewer to join me for Thurs Euro?
<noodles775> Now with al-maisan leaving soon, I'll be all on my own again :)
<noodles775> (leaving launchpad that is)
<abentley> Do we have a ui-reviewers team?
<rockstar> noodles775, do you really get busy on Thursday in Euro?
<noodles775> The last two weeks yes, pretty much my whole day (handing a queue to you), but the week before was only one, so it varies.
<mars> abentley, we are discussing about how to graduate more UI reviewers.  Curtis is practically ready to graduate, he just hasn't assumed the crown yet :)
<bac> noodles775: most slots only have single-person coverage
<noodles775> bac: just checked, yeah right, only Monday and Weds have 2. OK.
<abentley> mars, that seems only tangentially related to my question.
<bac> https://dev.launchpad.net/ReviewerSchedule
<bigjools> noodles775: jelmer wants to start reviewing and he might collar to be a mentor
<noodles775> Sounds great!
<bigjools> collar you, that is
<bac> abentley: UI reviewers are marked under the "specialties" column on the wiki i posted
<bac> abentley: other than that no real team
<mars> abentley, then the answer is no: we do not have a team
<mars> abentley, the list of reviewers ann process can be found here: https://dev.launchpad.net/UI/Reviews
<abentley> bac, mars: I would like to be able to request a ui review from the ui-reviewers team.
<mars> ah, interesting idea
<abentley> Its non-existence makes that hard :-)
<bac> abentley: ok, so you're talking about a team in launchpad for use in merge proposals.
<abentley> bac, yes.
<bac> abentley: so the answer is "not now" but it seems easy enough to do
<abentley> bac, having a team might overlap with that wiki page.
<abentley> But it might also be a nice way to find a ui reviewer.
<bac> abentley: would you like to coordinate getting that team established?
<rockstar> abentley, I'm your ui reviewer.  Never forget that.  :)
<abentley> rockstar, :-)
<abentley> bac, sure.
<mars> abentley, we can discuss it at the next UI call, if you wish
<abentley> mars, okay.
<bac> [action] mars to discuss UI reviewers team on UI call
<MootBot> ACTION received:  mars to discuss UI reviewers team on UI call
<bac> any other topics?
<bac> ok, thanks for coming everyone.
<rockstar> Why would we need to discuss making a UI reviewers team?  Couldn't we just JFDI?
<bac> #endmeeting
<MootBot> Meeting finished at 09:29.
<danilos> thanks bac
<al-maisan> thanks!
<mars> rockstar, I don't think throwing a UI review at a team will necessarily stick.  "If everyone owns it, no one owns it"
<mars> Unless we all agree to pick up team reviews
<rockstar> mars, well, it'll stick as well as throwing a code review at a team.
<intellectronica> rockstar: i agree with mars. making you chase a real person is going to help make sure the review actually gets done promptly
<rockstar> We've never just "thrown" the UI at a team.  It's assigned to a team, and then we go find a member of that team to do it.
<rockstar> Er, "thrown" a review at a team.
<mars> well, you do throw it at them, but you know there is someone over there looking for things to catch :)
<intellectronica> rockstar: the problem is that assignment means something very specific in Launchpad. it means 'this person is going to do that'
<rockstar> mars, if someone were to just assign a review to me, it's not likely I would do it.  I'd expect them to come to me and say "Hey, I assigned this review to you.  Can you do it?"
<intellectronica> if that person is not really a person then it's confusing
<mars> rockstar, right.  There is a social convention, or contract, there.  The UI reviewers team has not actually talked about said contract yet, so how would we know what to do when other people, not ourselves, invoke it?
<rockstar> We do this on a regular basis with canonical-launchpad
<intellectronica> rockstar: good point
<intellectronica> but we always also go find a reviewer
<rockstar> Team or Individual, there's already an existing social contract.
<mars> rockstar, but not between "anyone in launchpad" and the UI Reviewers team
<mars> if you just created that team tomorrow, and assigned a review to it, nothing would happen
<noodles775> But if you assigned a review to it, pinged someone and they weren't able to do it, other people would be aware of the need?
<mars> because we, the UI reviewers, don't know what to do yet.  Who should pick up the review?  Who can safely ignore it?
<rockstar> Creating the team allows you to see who you can track down.
<mars> noodles775, maybe, depends if that happens already.  Is creating a team just paving cowpaths?  Or creating a new contract?
<rockstar> I can safely ignore any review that no one specifically asked me to review.  If you don't track down a specific reviewer, obviously your review isn't a high priority.
<mars> rockstar, true, but so does the UI Reviewers wiki page.  And the page tells you what skill people have.
<rockstar> mars, we don't need a wiki to make people honest.  I know I haven't graduated (a theme that constantly irks me).
<rockstar> I'll make sure to say something like "you'll need to get another review from <graduated-reviewer>"
<rockstar> We already have "social contracts" that work fine, and ARE working.
<mars> rockstar, so the reason I think we should talk about this a bit at the meeting is so we all know what to do when we get notified that someone assigned a review to the UI Reviewers team.  You may know, but I, for example don't.
<rockstar> mars, what do you do when someone assigns a code review to canonical-launchpad?
<mars> If you know, great, then you can tell everyone on the team about during the the UI call :)
<mars> rockstar, absolutely nothing
<rockstar> mars, now you know, and knowing is half the battle.
<rockstar> We're not changing anything here.  We're not doing anything new.
<mars> rockstar, so why have the team at all then?  What does it do?
<mars> If no one does anything when it is assigned to the team, then what is the point?
<rockstar> mars, what's the point of canonical-launchpad then?
<abentley> mars, It allows me to flag the fact that it needs ui-review before I know who my ui-reviewer is.
<mars> abentley, ah!  ok, *that* makes sense.
<mars> rockstar, so the point of canonical-launchpad is just a placeholder as well.  Just a flag of intent.
<mars> rockstar, abentley, you see, I thought you meant that some action on our part was implied by assigning a review to the ui-reviewers team.
<abentley> mars, currently people are not notified when their team is requested to perform a review, but there has been pushback about that, so we may change it.
<mars> That is not the case
<mars> abentley, ah
<mars> So, I don't think you can just assume everyone will know to do the same thing in the new ui-reviewers team as what happens with canonical-launchpad.  You have to spell it out.  It's a new team, with a new contract.  (That just happens to be the same as what we do for canonical-launchpad.)
<rockstar> mars, yeah, so it's not new.  Do we have any UI reviewers who aren't also code reviewers?
<mars> rockstar, nope
<mars> rockstar, wait, /me checks
<rockstar> mars, here's a compromise.  Let's not "talk" about it at the UI reviewers meeting.  Let's just say "we're creating a group, you're in it, do what you do with code reviews"
<rockstar> Done.
<mars> rockstar, sure, since we already talked about it here :)
<mars> rockstar, you should at least ask for agreement from the other team members though.  You can lay it all out on a silver platter, but don't shove it down people's throats :)
<mars> rockstar, fwiw, mrevell is a UI reviewer, but not a code reviewer.
<mars> rockstar, mind if I add the UI call topic in your name?
<rockstar> mars, probably ought to do it in your name.
<mars> ok
<mars> done
 * mrjazzcat is away: Auto-away after 30 mins idle (gone at 3rd Mar, 09:22:12)
<bac> hi mwhudson, thumper, rockstar
<thumper> bac: hi
<mwhudson> bac: hi
<bac> how's your morning thumper?
<thumper> pretty good
<bac> #startmeeting
<MootBot> Meeting started at 15:31. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> hi michael
<rockstar> hi
<bac> hi rockstar
<rockstar> bac, I guess I'm doing double duty today.  :)
<bac> a twofer
<bac> rockstar: heck you should just lead the meeting
<rockstar> bac, :)
<bac> the only excitement from this morning was rockstar's proposal for changing (again -- :) ) the JS naming conventions
<rockstar> bac, in my defense, this was what was originally intended.  :)
<bac> rockstar: you want to summarize your idea?
<rockstar> Okay, so basically all YUI namespacing for lp specific modules now starts with lp.
<rockstar> So for the code team, our modules would be namespaced as "lp.code.whatever"
<rockstar> The code team has more specifics to the namespace, but those aren't lp wide.
<bac> the previous new convention had just been "code.whatever", right?
<bac> there wasn't much discussion since everyone thought it was a reasonable idea
<bac> abentley brought up the idea of creating a launchpad-ui-reviewers team in LP for use in assigning a reviewer in a MP
<mwhudson> both those things make sense to me
<bac> mars was going to bring it up on the UI reviewers call.  after the meeting ended there was some discussion about whether it made sense or not, but i couldn't hang around for the outcome
<bac> i guess we'll learn more next week
<rockstar> (the outcome is that we're going to talk about creating a team instead of JFDI'ing  :)
<bac> and from the mailing list discussion about community involvement in reviews and landing i took the assignment to check with legal and IS as to whether it is feasible or not from a corporate standpoint
<bac> rockstar: yeah, it seemed a bit wankish but i guess there is no need to create a team if in the end it's not going to be useful
<bac> so, that was basically all we discussed.  nothing too controversial.
<bac> either of you have anything to talk about?
<mwhudson> i thought rob's mail on the the community reviewer thread expressed my position pretty well
<bac> hey, i have a question.  i see in merge proposals the "reviewed version" is being set of us.  was that a recent fix?
<mwhudson> bac: yes
<bac> mwhudson: cool
 * bac tries to remember what exactly rob's point was
<mwhudson> well, partly that it was a strange limit to try to hold, given that there is plenty of community in ubuntu-core-dev
<mwhudson> but i didn't really want to restart the discussion here :)
<bac> no, thanks for that
<bac> well, that's all i've got
<mwhudson> me too
<bac> thanks for coming.
<bac> #endmeeting
<MootBot> Meeting finished at 15:44.
#launchpad-meeting 2010-03-04
<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
<allenap> me
<mrjazzcat> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<matsubara> Chex, rockstar, bigjools, sinzui, danilos: hi
<matsubara> Ursinha, hi
<rockstar> me
<bigjools> hello
<Ursinha> me
<Ursinha> hi
<danilos> hi
<matsubara> apologies from Gary, he's in a meeting and I'll be the foundations contact for today
<Chex> me
<matsubara> ok, everyone is here
<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>     * rockstar to investigate failure on update_branches script and reply to the email.
<matsubara> no new failures since last week, so I guess it sorted out by itself
 * rockstar nods
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<sinzui> me
<Ursinha> it's me
<Ursinha> so
 * sinzui did not see the rollcall
<Ursinha> three issues to point
<Ursinha> matsubara: bug 403281 seems an old bug, and I saw a bunch of oopses yesterday caused by this problem, could you set the importance, please?
<ubottu> Launchpad bug 403281 in launchpad-foundations "public xmlrpc requests broken during read only period" [Undecided,Triaged] https://launchpad.net/bugs/403281
<Ursinha> matsubara: also, I've filed bug 531695, but not sure if that's foundations
<ubottu> Launchpad bug 531695 in libgraph-perl "libgraph-perl v0.81 is not compatible with libheap-perl v0.80" [Undecided,New] https://launchpad.net/bugs/531695
<Ursinha> it seems a rollout issue
<Ursinha> hmm, that's not right
<matsubara> hmm
<matsubara> hehe
<Ursinha> bug 531965
<ubottu> Launchpad bug 531965 in launchpad-foundations "During the rollout, database changes caused old code to oops" [Undecided,New] https://launchpad.net/bugs/531965
<Ursinha> oops :)
<Ursinha> matsubara: what do you say?
<matsubara> [action] matsubara to discuss with foundations bug 403281 and set importance on it
<MootBot> ACTION received:  matsubara to discuss with foundations bug 403281 and set importance on it
<ubottu> Launchpad bug 403281 in launchpad-foundations "public xmlrpc requests broken during read only period" [Undecided,Triaged] https://launchpad.net/bugs/403281
<Ursinha> cool
<sinzui> I think bug 531965 is a soyuz issue
<ubottu> Launchpad bug 531965 in launchpad-foundations "During the rollout, database changes caused old code to oops" [Undecided,New] https://launchpad.net/bugs/531965
<Ursinha> sinzui: but that isn't oopsing anymore
<bigjools> no it's not a soyuz issue
<matsubara> there's also bug 403281 which is either Code or foundations
<matsubara> errr
<matsubara> wrong bug number
<Ursinha> sinzui: all occurrences I could find happened during the rollout
<matsubara> I meant bug 531687
<ubottu> Launchpad bug 531687 in launchpad-code "Accessing a merge proposal during the rollout (ie R/O mode) oopsed" [Undecided,New] https://launchpad.net/bugs/531687
<matsubara> rockstar, can you take a look and triage accordingly ^?
<rockstar> matsubara, sure
<rockstar> matsubara, is this part of the meeting really necessary?
<Ursinha> allenap: I see occurrences of https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1524C2016, but not sure this is a known issue
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1524C2016
<matsubara> [action] rockstar to triage bug 531687
<MootBot> ACTION received:  rockstar to triage bug 531687
<ubottu> Launchpad bug 531687 in launchpad-code "Accessing a merge proposal during the rollout (ie R/O mode) oopsed" [Undecided,New] https://launchpad.net/bugs/531687
<allenap> Ursinha: Looking.
<rockstar> We should (and do) keep up with triaging bugs.  I'm not sure that we need to bring it up in a meeting.
<matsubara> rockstar, I think this section of the meeting is the main reason for this meeting :-)
<Ursinha> rockstar: specially after rollouts
<matsubara> may I ask why do you think it's not important?
<Ursinha> :)
<rockstar> matsubara, because you asked me to do something that someone from our team is going to do at some point today anyway.
<rockstar> matsubara, I think the ops report is the most helpful part of this meeting.
<matsubara> yeah, that part is very useful as well, I agree
<matsubara> we bring up the OOPS that we think are important so it won't fall through the cracks
<rockstar> matsubara, do we need to gather everyone together to do that?
<Ursinha> rockstar: but I recall you suggesting us to file bugs for oopses before coming to the meeting, so why exactly you think the oops section is useful?
<rockstar> Ursinha, ops wasn't a typo.  :)  Operations report
<allenap> Ursinha: That reminds me of a known issue. I don't have a bug number for it yet. If it is the same issue then it's proven very difficult to reproduce.
<matsubara> rockstar, well, we already gather everyone together for this meeting. discussing oops issues is just one side of it, along with scripts failing and critical issues
<Ursinha> allenap: that reminds me of a known issue as well, but I couldn't find the bug
<matsubara> the meeting was evolving to the point we're today. from our experience a lot of things end up falling through the cracks if the QA team don't bring them up
<matsubara> but I'm all ears for suggestion to improve the format of the meeting that would be more useful to you
<matsubara> and by you, I mean all of you
<matsubara> :-)
<matsubara> not only rockstar
<rockstar> matsubara, but I ask if we need a meeting to bring them up.  Can't you just bring them up as they happen?
<danilos> rockstar, I think OOPS section is necessary until we get to a point where every team is on top of their OOPSes *without* matsubara and Ursinha
<matsubara> +1 danilos
<Ursinha> rockstar: I think it's nice to have a main contact to express our concerns :)
<rockstar> danilos, I agree that matsubara and Ursinha are a HUGE lifesaver.  I just wonder if it needs to be part of the meeting.
<Ursinha> I agree with danilos
<rockstar> Ursinha, oh yeah, I'm happy to be the main contact for QA questions.
<danilos> rockstar, let's discuss that at the end of the meeting; Ursinha, matsubara, anyone else interested, let's move that discussion after the regular agenda
<bigjools> I quite value the input from matsubara and Ursinha for the oopses
 * rockstar sighs
<matsubara> as danilos pointed out, once the teams are taking care of OOPSes without our help, then I think this section will slowly fade away
<rockstar> bigjools, I don't disagree with you.
<sinzui> I think we have a lot of unowned or shared apps that do not have team
<bigjools> rockstar: I wasn't referring to anything you'd said actually
<rockstar> bigjools, okay.  :)
<danilos> let's go on and come back to this topic later, pleaaseee :)
<sinzui> I am tempted to fix a bug in malone, launchapd-answers, and blueprints because I am tired of reading spam attacks to find my bugs, but who would know about these attacks if we were not collectively seeing all oopses
<matsubara> all right, so Ursinha, anything else? (did I get all the action items right, specially the ones for foundations?)
<Ursinha> matsubara: nothing else in the oops section
<matsubara> [action] matsubara to discuss bug 531965 with foundations as well
<MootBot> ACTION received:  matsubara to discuss bug 531965 with foundations as well
<ubottu> Launchpad bug 531965 in launchpad-foundations "During the rollout, database changes caused old code to oops" [Undecided,New] https://launchpad.net/bugs/531965
<matsubara> scripts failing: mpcreationjobs and sendbranchmail just failed
<Ursinha> there are two critical bugs, in progress
<matsubara> rockstar, can you take care of those and reply to the list? is this something that could be caused by the rollout?
<allenap> Ursinha: I can't find out any more about that OOPS now, so I'll investigate later.
<Ursinha> thanks allenap :)
<rockstar> matsubara, sure
<matsubara> [action] rockstar to investigate failures on mpcreationjobs and sendbranchmail scripts
<MootBot> ACTION received:  rockstar to investigate failures on mpcreationjobs and sendbranchmail scripts
<Ursinha> bigjools: will you need a rc to fix bug 530566?
<ubottu> Launchpad bug 530566 in soyuz "cron.germinate still believes lpia is active" [Critical,In progress] https://launchpad.net/bugs/530566
<bigjools> Ursinha: I have one but thanks for reminding me to land that branch :)
<Ursinha> bigjools: :)
<Ursinha> matsubara: there's bug 530354 too that seems approved as well
<ubottu> Launchpad bug 530354 in launchpad-foundations "wadl generation is broken after multiversion code has landed" [Critical,In progress] https://launchpad.net/bugs/530354
<rockstar> matsubara, abentley is already figuring out what's going on with those scripts.
<matsubara> thank you rockstar
<Ursinha> matsubara: it says "Merged", so that is Fix Committed or even Fix Released? could you check, please?
<matsubara> Ursinha, if it says merged, it's fix committed. I think it's this one: # r9069 [release-critical=thumper][r=gary][ui=none] Cache a static WADL file for every version of the web service.
<matsubara> probably my script that closes it didn't get to it yet :-)
<Ursinha> matsubara: hehe
<Ursinha> okay
<matsubara> let's move on then
<Ursinha> thanks everyone
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara> Chex, the stage is yours
<mbarnett> take it and run!
<Chex> hi everyone
<Chex> Here is the LOSA report for this week:
<Chex> - LP rollout 10.02 took 70 mins longer than scheduled. Some related bugs were:
<Chex>         ; Need more visibility into progress of upgrade.py/fti.py/security.py bug 531833
<ubottu> Launchpad bug 531833 in launchpad-foundations "Need more visibility into the progress of upgrade.py/fti.py/security.py" [High,Triaged] https://launchpad.net/bugs/531833
<Chex>         ; Read-only seemed to leave lots of "idle" and "select waiting" connections to the master and
<Chex>                 slave DBs which possibly blocked the DB upgrade bug 531834
<ubottu> Launchpad bug 531834 in launchpad-foundations "When switching to read-only mode, we're left with lots of "idle/select waiting" connections to the DBs which may be blocking the schema upgrade process" [High,Triaged] https://launchpad.net/bugs/531834
<Chex> - LP incidents of note:
<Chex>         ; Crowberry Out-Of-Memory error: https://pastebin.canonical.com/28737/ 2010-03-04 12:30 UTC
<Chex>           Does anyone have any insight into this issue??
<Chex> and thats the report. anyone have questions or comments?
<matsubara> crowberry is code hosting, right? rockstar ^
<rockstar> matsubara, I'm not sure.  I never remember the names of our boxes...
<matsubara> the pastebin indicates it's a code hosting machine
<matsubara> [action] rockstar to investigate Out-Of-Memory error: https://pastebin.canonical.com/28737/ and get back to losas about it
<MootBot> ACTION received:  rockstar to investigate Out-Of-Memory error: https://pastebin.canonical.com/28737/ and get back to losas about it
<Chex> sorry, crowberry is codehosting, yes.
<matsubara> ok, I think we can move on then.
<matsubara> thanks Chex
<Chex> matsubara: sure
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> stub will send the report to the list. I'll remind him.
<matsubara> [action] matsubara to remind stub about dba report
<allenap> matsubara: I think he sent it already.
<MootBot> ACTION received:  matsubara to remind stub about dba report
<matsubara> oops
<matsubara> yes, indeed he did. thanks allenap
<matsubara> [action] cancel last action item about dba report :-)
<MootBot> ACTION received:  cancel last action item about dba report :-)
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> rockstar, so would you like to discuss a better format for the oops section?
<matsubara> seems to me we have a agreement that the oops section is generally useful and once the teams start to take care of their oopses that section will be unecessary
<danilos> matsubara, we don't have agreement that it will be unnecessary :)
<danilos> matsubara, sinzui has raised an interesting point
<danilos> matsubara, there's a whole bunch of problems which don't belong in any particular team domain
<danilos> matsubara, and then there are also those which appear only for one or two teams, but might be global
<matsubara> right, so we'll continue to bring up those during this meeting
<danilos> I am hoping we'll get to a point where OOPS section will be about those
<matsubara> yep. agreed.
<rockstar> I think we're pretty good at saying "this doesn't look like a <app> issue.  Maybe ask <other-app-dev>"
<danilos> and prerequisite for not reporting any OOPSes in a meeting is that both teams handle them themselves and that teams are good at bug triage
<rockstar> If there's a bug filed on an oops, it'll get triaged.  That should be a team's responsibility, and if the team isn't getting to it, then we need to evaluate that.
<rockstar> Code has been going out of our way to make sure we get bugs triaged.
<danilos> rockstar, well, we are still very far off zero OOPSes in normal circumstances
<Ursinha> danilos: +1
<rockstar> danilos, this is true, but that's not the issue.
<danilos> rockstar, right, I'd say we have a pretty good situation in translations (rarely more than 10 untriaged bugs), but does it hold for all teams?
<danilos> rockstar, how about launchpad-foundations which is our hold-all bag?
<rockstar> If there's an oops that Ursinha or matsubara sees, they file a bug (they are good at this).  At that point, they should assume the ball has been passed.
<rockstar> danilos, how is launchpad-foundations the "hold-all" bag?  If they have bugs that belong to code, they're hurting foundations and code by not re-assigning them.
<danilos> rockstar, sharing knowledge is useful; when I've seen some OOPSes related to authdb split in translations, I pinged bigjools because I suspected it might bite soyuz as well
<rockstar> danilos, yeah, but that doesn't need to happen in the meeting.
<danilos> rockstar, they have a gazillion bugs which are generic LP problems but not necessarily part of infrastructure, like UI features and such
<sinzui> One problem that I am thinking of was caused by our switch to storm and each application has to make their own fix. This is not a foundations issue, it is an oops that should be targeted to 3 projects
<danilos> sinzui, +1
<rockstar> sinzui, exactly.
<danilos> what I am saying is that we do have problems in some teams that need to be fixed before we can even consider dropping OOPS section from the meeting
<rockstar> Make no mistake.  matsubara and Ursinha are invaluable to Launchpad.  I just don't think they need to duplicate their efforts because I can't triage bugs.
<matsubara> danilos, +1 on the share knowledge usefulness. that's why I think this meeting (and the oops section) is still useful. we bring everyone together and talk about those issues. ideally this would all happen in the bug tracker, but reality is that sometimes some bugs end up falling through the cracks.
<Ursinha> matsubara: +1
<matsubara> and that's where Ursinha and I could help by nagging you guys endlessly :-)
<rockstar> So let's keep the oops section, but not bring up untriaged bugs.
<Ursinha> yes hehe
<danilos> rockstar, I agree, but we first need to make sure "you" are triaging your bugs; care to do the evaluation of all LP subprojects and come back with data that either confirms or rejects my feeling of what it is?
<rockstar> danilos, should QA have to babysit us to triage our bugs?  That doesn't seem fair.
<Ursinha> rockstar: I don't know if that's ideal now; sometimes we dig old triaged bugs (or partially triaged) that need to be taken care now
<danilos> rockstar, no, they shouldn't; can you guarantee all teams will have a very low number of untriaged bugs by next Thursday?
<danilos> Ursinha, rockstar is not complaining about those
<danilos> or at least not strongly :)
<rockstar> danilos, I can't guarantee that, but maybe it's something we should start pushing harder.
<Ursinha> danilos: I'm saying that mentioning bugs isn't useless, triaged or untriaged, because afaik me and matsubara only bring up that ones that need to be taken care of
<danilos> rockstar, what they do today is to raise importance of OOPS bugs in this meeting: sometimes they'll be untriaged, sometimes triaged
<Ursinha> danilos: agreeing with you
<danilos> rockstar, I agree we should start pushing harder, let's have untriaged bugs part of the OOPS section until we feel confident we've done a good push
<matsubara> danilos, so you're asking some kinda of count of untriaged bugs per team in the oops section? we could do that easily, I think.
<danilos> rockstar, we have 218 'New' bugs on launchpad-project today
<rockstar> Alright.  It's obvious that we're at an impass.  I'll bring up my personal feelings with my line manager, and see what comes of it.
<rockstar> I guess leave the meeting as it is.
<matsubara> danilos, or bring up those untriaged, but until we get those to manageable number, bringing up all of them during the meeting will be difficult and take a lot of time
<danilos> rockstar, now I have to look up 'impass' in a dictionary :)
<rockstar> danilos, deadlock.
<danilos> rockstar, ok, thanks
<sinzui> suck to be soyuz it seems
<danilos> rockstar, matsubara: having a per-team count of untriaged bugs would be a good start
<sinzui> and I see one of the new bugs claims to have a patch!
<matsubara> [action] matsubara and/or Ursinha to add a count of untriaged bugs per team to the oops section
<MootBot> ACTION received:  matsubara and/or Ursinha to add a count of untriaged bugs per team to the oops section
<sinzui> launchpad-foundations has a bug with a patch. I think they are hoping that jml will take the bug away from them
<jml> what
<jml> (gotta ask me first)
<sinzui> jml: https://bugs.edge.launchpad.net/launchpad-foundations/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&fie
 * sinzui hates bug urls
<danilos> rockstar, btw, I'd be very happy if you get this moving in any way you can, so thanks for raising it!
<danilos> sinzui, we should integrate shorturl service into LP and generate/reuse those URLs with every bugs page :)
<sinzui> danilos: what? implement saved searches for users and teams?
<danilos> sinzui, kind of :)
<danilos> anyway, matsubara, I believe the topic is settled
<sinzui> We certainly would get a lot of cheers from users and even OEM
<matsubara> danilos, thanks for the feedback on this. you too rockstar and sinzui
<matsubara> anything else before I close?
<jml> sinzui, me too
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<jml> sinzui, anyway, I'm busy and not really paying attention. If you want me to do something, please email me something asking about it :)
<Ursinha> sinzui: from me too :P
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:54.
<Ursinha> matsubara: thanks
<Ursinha> thanks all
<bigjools> gnargh
<sinzui> jml: I was only surprised to see bugs in the new state with patches, then I remembers there is one marked UI, we are planning to move thos bugs to another project
<danilos> sinzui, the count of bugs with patches is totally broken for 'rosetta' project
<danilos> sinzui, it tells me "8 bugs with patches" and when I click it, it's two bugs both in 'fix released' (with multiple bugtasks, but all of them are fix released)
<sinzui> danilos: I think the bugs team need to fix that. I wonder it they skipped the default rule of ignore fixed bugs
<Ursinha> daniloff: sinzui, hm, I just filed a bug for that
