#launchpad-meeting 2008-04-01
<barry> #startmeeting
<MootBot> Meeting started at 05:01. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everybody and welcome to this week's asiapac reviewers meeting
<barry> who's here today?
<sinzui> me
<thumper> me (kind of)
<sinzui> Well this is looking embarrassing.
<spiv> I'm here.
<barry> sinzui: i was going to say, if it was just you and me, we should do it when the sun is up :)
<jml> hi
<barry> jml: hi
<barry> spiv, thumper hi
<barry> mwhudson: are you around?
<jml> thumper is unwell and is off
<barry> thumper: :(
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<jml> mwhudson last said "afk for a little while" 4 minutes ago
<barry> jml: okay thanks, oh well
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>     * '''Pre-imp calls are falling by the wayside''' (gmb)
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<barry> so, is this a good time for y'all?
<jml> for me, yes.
<thumper> normally, but I'm somewhat uncommunicative right now
<spiv> This is fine for me too (same timezone as jml).
<barry> thumper: no worries.  anybody know if this is a good time for jamesh?
<jml> but I'd be equally with something up to four hours earlier or two hours later, if things need rescheduling.
<jml> barry: it's 11am in WA right now.
<jml> barry: it *ought* to be a good time for him :)
<barry> :)
<jml> (the WA that's on the west coast of Australia, not the one on the west coast)
<barry> jml, naw, i was thinking maybe 1 hour earlier, but this works just fine for me too.  in daylight saving's its 11pm, and i fake-tivo the daily show so it's all good
<jml> :)
<barry> cool, let's keep 0300utc then
<jml> +1
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * (continued) thumper to report on pending-reviews killer in LP
<thumper> barry: sorry, it's coming
<thumper> but nothing else to report right now
<barry> thumper: no worries, we'll just keep continuing it if you want
<thumper> yeah
<barry> thumper: just want to be sure you don't want to ditch the whole thing :)
<barry> jamesh: hi!
<jamesh> hi
<thumper> barry: not just yet
<lifeless> boo!
<barry> cool
 * barry is frightened
<barry> just for completeness, here are the ameu action items:
<barry>  * gmb to hack review-submit to enforce 800 line limit.
<barry>  * schwuk to work with mwhudson to get instructions for running loggerhead onto the wiki
<barry> any comments or should we just move on?
<jml> barry: I don't think enforcing the 800 limit is a good idea.
<jml> barry: unless that means "show a warning"
<thumper> me neither
<sinzui> jml: 800 + shame
<barry> yeah, it's mostly so you have a warning
<barry> i really think the option to override should be --isuck
<lifeless> rather than say enforce
<lifeless> say 'warn' perhaps ?
<sinzui> jml: the 800 line flag really means you need to send with the -r switch (have a review lined up)
<lifeless> if you mean warn :>
 * barry speaks as someone who sucks often
<jml> sinzui: perhaps.
<barry> yes, the point is you really need to arrange things with a reviewer if your >800 lines
<jml> I think that's fair enough. I still think you should be able to override whatever policy the tool has by default.
<barry> i'm happy to reword this action item to be clearer about it, but i think gmb knows what we mean
<barry> jml: definitely
<jml> anyway, review-submit will be an addon to send eventually.
<jml> barry: cool. now I know what gmb means, I'm happy :)
<barry> cool!
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
<barry> some bonehead's got two branch's in the general queue
<jml> :)
<barry> :-D
<jml> just to be clear
<jml> are we supposed to send emails *and* hack wiki?
<barry> jml: i don't know anymore.  i do, but that's just me
<jml> hah!
<jml> ok :)
<barry> i fully intend to ask tomorrow's on-caller to review these branches though
<lifeless> someone should patch submit-review to edit the wiki
<jml> there's also at least one email sent that's not on the wiki page and has no assigned reviewer
<jml> lifeless: yes. it's getting close to that already.
<barry> jml: it's still the responsibility of the dev to get his branches reviewed
<jml> *nod*
 * barry still likes the pending-reviews page tho
<barry> it tells me we have 5 pink branches
<barry> i know about stub's two
<barry> jml: what's up with your use-inmemory-proxies branch?
<jml> barry: shelved, for the time being.
<barry> jml: should we move that to wip?
<jml> barry: yeah, probably.
<barry> jml: i'll let you do that :)
<jml> ok
<barry> thanks
<barry> any other queue-related comments?
<jml> none from me
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> i don't think there are any asiapac mentors or mentorees
<barry> are there any of you guys who /aren't/ already reviewers?
<sinzui> That was to requirement for mwhudson to emigrate.
<jml> barry: all australasian LP hackers are reviewers
<jml> we even have a non-LP hacker who's a reviewer :)
<barry> jml: excellent!
<jml> a veritable superabundance of reviewers.
<barry> you need to hire more grunts
<barry> [TOPIC] review process
<MootBot> New Topic:  review process
<barry>     * '''Pre-imp calls are falling by the wayside''' (gmb)
<jml> What does that mean?
<barry> people 'round here slacking on pre-impl calls
<barry> have you noticed that? is it a problem? and if so what do we do about it?
<barry> here's specifically what gmb says:
<barry>  * '''Pre-imp calls are falling by the wayside''' (gmb). Since we've adopted the on-call review process I've noticed that less and less people (including myself) have been having pre-imp calls before they start work. Partly, I figure that this is because the on-call process allows the developer to talk about their implementation decisions with the reviewer and so helps to substitute for a pre-imp in a lot of ways. However, I've had one
<barry>  branch land this cycle that happily had r= from the reviewer but which, had there been a pre-imp, might not have landed in the form it did (which would have avoided me needing to ask for an RC). Should we be enforcing the requirement to have pre-imp calls, or at least be more scrutinous of those branches that don't?
<mwhudson> oopsie
<jml> I've observed that people aren't rigorous about calling someone before they begin work on a branch.
<jml> I don't think that's a problem.
<jamesh> I think I've done only two pre-impl calls with people in the last month (and only one was actually voice)
<barry> let me ask: how have the quality of branches been lately when first submitted for review?  has it been getting better, worse, or about the same?
<jml> the way we'd measure it being a problem is if reviewers were asking for branches to be re-implemented :)
<jml> barry: that's hard to discern. The code I get to review is generally very clear.
<barry> i'm curious about the rate of needs-reply branches.
<jml> the sample is limited, because we are increasing the size of the review team.
<barry> jml: many of the branches i've reviewed lately have been merge-* right off the bat (i.e. very good quality)
<mwhudson> something that's definitely happening is that i'm basically only reviewing things from the code team
<jml> needs-reply doesn't always mean lower quality
<mwhudson> and occasionally jamesh
<barry> jml: no, you're right, but it's an indicator that the branch maybe wasn't quite ready to code yet
<jml> I often flag things needs-reply because I don't understand a part of the problem domain.
<barry> mwhudson: interesting
<jml> yeah, I'd agree w/ mwhudson on that.
<barry> is that basically geography?
<jml> I also almost always get code or bzr ppl to do my pre-impl calls
<jamesh> well, it isn't that surprising that NZ reviewers mainly have overlap with NZ and AU coders
<mwhudson> indeed
<barry> jamesh: yep
<jamesh> for pre-implementation calls, it is even more of an issue
<jamesh> since that's real time when reviewing might not be
<barry> cool, so basically you don't feel that the current rate of pre-impl's is a problem?
<jml> no :)
<mwhudson> i don't know how much of a problem this is, it reduces the cross-team spread of knowledge a bit
<mwhudson> barry: no
<barry> mwhudson: good point.
<jamesh> while there might not be as many formal pre-impl calls as there once were, people do consult others on IRC about implementation issues
<jamesh> (at least in this time zone)
<barry> if it's not a problem, i'm definitely not going to try to "fix" it then :)
<barry> thanks, this has been good feedback
<barry> so... that's it from me.  we have 15 minutes if anybody has anything not on the agenda, or messages to convey to ameu
 * jml has nothing on topic
<barry> cool.  time for the colbert report then :)
<mwhudson> :)
<barry> #endmeeting
<MootBot> Meeting finished at 05:31.
<barry> thanks everyone!  g'night :)
<mwhudson> thanks barry
<jml> thanks barry
<mwhudson> (and sorry for being late)
<barry> mwhudson: no worries.  talk to you guys soon...
#launchpad-meeting 2008-04-02
<flacoste> #startmeeting
<flacoste> Welcome to this weeks' reviewers meeting
<flacoste> mootboot seems not to be available, so we'll do without
<flacoste> so who's here today?
<allenap> me
<sinzui> me
<intellectronica> me
<bac> me
<schwuk> me
<gmb> me
<flacoste> (btw, i'm chairing in lieu of barry)
<BjornT_> me
<flacoste> (who is out sick)
<schwuk> bigjools said he might not be around.
<flacoste> salgado: ping
<salgado> me
<flacoste> danilos: ping
<danilos> flacoste: sorry, on a sprint, will miss the meeting
<flacoste> danilos: ok
<flacoste> intellectronica: also sent his apologies
<flacoste> == Agenda ==
<intellectronica> i'm here but will have to leave around 14:30
<flacoste>  * Roll call
<flacoste>  * Next meeting
<flacoste>  * Action items
<flacoste>  * Queue status
<flacoste>  * Mentoring update
<flacoste>  * Review process
<flacoste>     * '''Pre-imp calls are falling by the wayside''' (gmb)
<flacoste> '''pending-reviews is missing branches listed on PendingReviews'''
<flacoste> '''Is there a policy on private name mangling?'''
<flacoste> Topic: Next meeting
<flacoste> Same time, same place?
<flacoste> anybody knows they can't make it?
<flacoste> 5
<flacoste> 4
<flacoste> 3
<flacoste> 2
<flacoste> 1
<flacoste> great, same time, same place, everybody should be there!
<flacoste> TOPIC: Action items
<flacoste>  * gmb to hack review-submit to enforce 800 line limit.
<gmb> This is done
<gmb> Hurrah
<flacoste> awesome!
<gmb> I've sent the patch to mwh to look at.
<flacoste> i guess people have to upgrade their plugin to have it?
<flacoste> ah, it's not landed yet
<flacoste> anyway, that's still cool!
<flacoste> thanks gmb
<flacoste>  * schwuk to work with mwhudson to get instructions for running loggerhead onto the wiki
<allenap> gmb: Is there an --override option, for when we're agreed in advance with a reviewer?
<sinzui> --isuk?
<schwuk> flacoste: that was finished a couple of weeks ago when gmb chaired
<gmb> allenap: Yes.
<allenap> gmb: Cool :) And thanks sinzui :)
<schwuk> flacoste: https://launchpad.canonical.com/RunningLoggerhead
 * gmb forgot to update the agenda after that last minute chairing.
<flacoste> ok
<flacoste> any other actions i'm not aware of?
<flacoste> i guess not
<flacoste> Topic: Queue status
<flacoste> according to the QueueStatus, there are two stub's branch needing a review
<flacoste> one branch that has the wrong status (that's my fault)
<flacoste> and another branch which is 7 days old but not marked over SLA?
<flacoste> salgado, that's the abel's branch, what's the status there?
<salgado> it's merge-approved, IIRC
<salgado> let me check
<salgado> yeah, I approved it
<flacoste> ok
 * salgado updates the status
<flacoste> i guess the two stub's branch are the ASIAPAC meeting responsibility
<flacoste> anything else to add on queue status?
<sinzui> It's not showing all branches
<flacoste> sinzui: i think we have another item to discuss that
<flacoste> or is this something eles?
<sinzui> flacoste: we do :)
<flacoste> ok, moving on then
<flacoste> Topic: Mentoring update
<flacoste> who's it going? schwuk, allenap?
<flacoste> bigjools and danilos are two other mentees being absent (or maybe their mentor have something to say)
<flacoste> hmm, bigjools mentor's is sick
<sinzui> schwuk: Are you going to take an on-call slot?
<schwuk> Last week fell apart for me with my father, so I got no reviews done. I'm on call this Friday so I can overlap with sinzui.
<bac> gavin and did our first on-call yesterday and it went really well
<allenap> Going well, did a couple of reviews on call yesterday, which bac mostly thought were good.
 * schwuk remembers to update the schedule
 * gmb cheers at the idea of having even more people to throw branches at on a Friday
<flacoste> who is mentoring danilos?
<bac> allenap: they were quite good!
<gmb> flacoste: danilos graduated last cycle.
<allenap> bac: Thanks :)
<sinzui> danilos: graduated
<flacoste> oops :-)
<flacoste> no offense meant
<flacoste> so we only have three mentees?
 * flacoste will take that for a yes
<flacoste> anything else to add on the topic?
<flacoste> 5
<flacoste> 4
<flacoste> 3
<flacoste> 2
<flacoste> 1
<flacoste>  * Review process
<flacoste> we have 3 items for discussion on the process
<flacoste> first one:
<flacoste>     * '''Pre-imp calls are falling by the wayside''' (gmb)
<gmb> flacoste: Was that not covered last week?
<flacoste> TOPIC: 'Pre-imp calls are falling by the wayside (gmb)
 * gmb was on vacation
<flacoste> i guess
<sinzui> I was covered here and in asiapac
<flacoste> there was an action about "barry to remind lp devs to do pre-impl calls "
<flacoste> did that occured?
 * flacoste can't remember
 * gmb didn't see anything
<flacoste> i guess not then
<flacoste> ACTION: barry to remind lp devs to do pre-impl calls (repost)
<flacoste> so let's move on
<flacoste> TOPIC: pending-reviews is missing branches listed on PendingReviews (sinzui)
 * flacoste hands the mic to sinzui
<sinzui> I noticed that the two of jtv's branches I reviewed are not on pending-reviews
<flacoste> sinzui: is it because they are not on PendingReviews, or because of a bug?
<sinzui> I also noticed that one of cprov's branches that was marked merge-approved several days ago still states it was need-reply
<sinzui> The branchs were/are on PendingReviews. All came from the general queue to my queue
<sinzui> I removed cprovs branch because I saw the commit message.
<flacoste> jtv's branch are still missing though
<sinzui> right
<flacoste> i guess there is a bug in the script
<flacoste> jamesh maintains that
<flacoste> sinzui: can you email jamesh about the problem?
<flacoste> cc list
<sinzui> I will
<flacoste> ACTION: sinzui to email jamesh about some branches not being picked up by pending-reviews
<flacoste> anything else to add here?
<flacoste> 5
<flacoste> 4
<flacoste> 3
<flacoste> 2
<flacoste> 1
<flacoste> TOPIC: Is there a policy on private name mangling? (allenap)
<flacoste> allenap has the floor
 * allenap starts copying and pasting frantically.
<allenap> A branch I reviewed yesterday had a _pseudo_private method on a mix-in class. Not that it's a big danger, but this seems like a sensible place to use __private_name_mangling. Or is mangling frowned upon, or deprecated?
<flacoste> allenap: what's your opinion
<allenap> I'm all for it, but I wanted other's opinions.
<intellectronica> i don't think we should do this unless it's really dangerous for a consumer to touch an attribute
<allenap> But, even in this case, it didn't matter too much. I wanted to see if there were good reasons for or against.
<intellectronica> you never know, for example, when you might need to monkeypatch
<gmb> I'm with intellectronica here.
<gmb> Not that I'm advocating monkeypatching ;)
<gmb> But I don't think we'd gain too much from using mangling.
<flacoste> the problem with mangling is that it makes it very hard to work with the attribute
<flacoste> in the debugger
<flacoste> or in subclass
<flacoste> so i usually prefer _pseudo_private to __mangling
<flacoste> but this all might be because I'm an ex-perl hacker and I live by the motto 'we rather you don't come in our living room because you weren't invited, not because I have a shotgun'
<gmb> flacoste: There's also the Python motto "We kind of expect you to know what you're doing; on your head be it if you don't."
<gmb> Which is less snappy but...
<BjornT_> +1 for _pseudo_private
<allenap> I don't really see name mangling as a way to prevent access, more as a way to avoid shooting self in foot.
<gmb> allenap: True, but the test suite *should* pick up on foot-shooting anyway.
<allenap> Okay, consensus seems to be for _singles, so I'll add that to the guidelines on the wiki.
<intellectronica> allenap: you see, if you didn't have a shotgun, you wouldn't have the problem of shooting yourself in the foot ;)
<allenap> Perl hackers and their shotguns, heh.
<allenap> flacoste: Back to you I think.
<intellectronica> anyway, gotta go now. my apologies again
<flacoste> ACTION: allenap to update Reviewers' guidelines with _pseudo_private policy
<flacoste> that's it for the items on the agenda
<flacoste> we have some time left
<flacoste> anybody has a topic to propose?
<flacoste> 5
<flacoste> 4
<flacoste> 3
<flacoste> 2
<flacoste> 1
<flacoste> Then we are done
<flacoste> Meeting Ends
<flacoste> thanks a lot everyone
<gmb> Thanks flacoste
#launchpad-meeting 2008-04-03
<Rinchen> hello MootBot
<bigjools> Rinchen: is there a meeting
<bigjools> ?
<gmb> Rinchen, bigjools: The calendar says it's at 18:00 UTC...
<bigjools> wtf
<bigjools> 7pm - will definitely not be making that then
<sinzui> We really need to move this meeting next week
<cprov> +1
<sinzui> I may be the only North American that supports that.
<Rinchen> On the 6th I think is when NZ does their timezone change
<sinzui> The argument would be in the European favour too if it wasn't for all us cheap Americans.
<Rinchen> sinzui, spoken like a true Canadian
 * sinzui gets out the visa
<Rinchen> and the mastercard
<Rinchen> lol
<bigjools> badumtish
<Rinchen> :-)
<bigjools> I'VE ALWAYS LOVED CANADA
<Rinchen> at the very least we can go to 17:00 next week. That should be 7am for thumper
<sinzui> I still hold Canada responsible for global warming
<sinzui> And Brian Adams
<bigjools> and maple syrup
<bigjools> wait...that's nice!
 * sinzui likes maple syrup
<bigjools> preferably doused on some pancakes
<sinzui> bigjools: There is a fashion in the US to lace sausages and bacon with it.
<bigjools> ewww gross
<bigjools> there's only one thing to have with bacon
<sinzui> bigjools: the first bite is fine, it's the second bite that you think 'ewww gross'
<bigjools> more bacon
<sinzui> bigjools: I think I agree with you
<bigjools> except if it's Jono
<bigjools> lol
<sinzui> There ca be only one
<Rinchen> mmm bacon. You're making me hungry for lunch
<barry> bacon
<Rinchen> jsk!
<sinzui> jsk?
<sinzui> jsk: translations is hiring
<Rinchen> jtv...  did you notice the similarities between SKJ and jsk ? :-)
<jtv> jsk: come back, all is forgiven!
<jtv> Rinchen: for that reason alone we must have him back.  :-)
<mwhudson> hnnnnnnnnnnngh
<jtv> Rinchen: ah, and the K in SKJ became a GTF Contributor today.
 * gmb hands mwhudson a large coffee.
<Rinchen> jtv, well, add  JJS = Joseph James Stanford (joey) and you can add me
<Rinchen> too
<danilos> Rinchen: no, that sucks :)
<jtv> Rinchen: you're already in the GCP, no?
<Rinchen> lol
<Rinchen> jtv, no idea
<jtv> Rinchen: but you're in the GTF now, right above Journal of Japanese Studies.
<Rinchen> lol
<Rinchen> domo
<thumper> mwhudson: I feel the same way
<Rinchen> morning thumper
<thumper> Rinchen: morning
<kiko> ahoy hoy
 * flacoste cheers kiko
<Rinchen> ahoy me matey
<Rinchen> 45 seconds on the atomic clock
<intellectronica> i say, free supply of meth to the down under participants if they agree to hold the meeting an hour earlier
 * Rinchen laughs. 
<thumper> Hmm.. my clock must be out
<Rinchen> intellectronica, I don't think Thumper needs meth
<gmb> T - 5
<Rinchen> and on that note.....
<Rinchen> #startmeeting
<MootBot> Meeting started at 20: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
<MootBot> New Topic:  Roll Call
<Rinchen> me!
<bac> me
<statik> me
<mars> me
<mthaddon> me
<intellectronica> me
<gmb> me
<jtv> me
<danilos> me
<abentley> me
<carlos> me
<flacoste> me
<thumper> me
<BjornT> me
<matsubara> me
<bigjools> me for 30 mins
<herb> me
<EdwinGrubbs> me
<salgado> me
<sinzui> me
<adeuring> me
<cprov> me
<Rinchen> mrevell, mpt ?
<kiko> me
<mrevell> me
<stub> me
<flacoste> barry is still sick<
<Rinchen> apologies from allenap
<mwhudson> me
<schwuk> me
<kiko> I'm sick too
<mrevell> Rinchen: mpt said somethng about going to the other side of the world earlier, so maybe he's on a flight.
<leonardr> me
<Rinchen> anyone missing from your teams flacoste, statik ?
<statik> nope
<Rinchen> SteveA?
<statik> all present and me'd
<flacoste> Rinchen: apart barry, no one
<Rinchen> cool thanks
<Rinchen> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<flacoste> Rinchen: besides i'd love to have statik on my team, but he got one of his own :-)
<Rinchen> * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (Matsubara)
<Rinchen>  * Critical Bugs (Rinchen)
<Rinchen>  * Bug tags
<Rinchen>  * Operations report (mthaddon/herb)
<Rinchen>  * DBA report (stub)
<Rinchen>  * Sysadmin requests (Rinchen)
<Rinchen>  * New packages required (salgado)
<Rinchen>  * A top user-affecting issue (mrevell)
<Rinchen>  * Doc Team report (mrevell)
<Rinchen>  * Blockers
<Rinchen> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<Rinchen> There was some rather vocal pre-meeting discussion about how the 18:00 UTC meeting time no longer works for the European team members now that the Northern Hemisphere is on DST.
<Rinchen> DST ends in NZ on the 6th which would mean that next week could start the meeting at 17:00 UTC and this would restore the meeting time to the usual hour. I understand this is still not convenient for the eastern Europeans but it would be 7am in NZ allowing those folks to participate.
<thumper> ah, 17:00 UTC is 5am
<jtv> Or midnight for me
<gmb> Even *I* think that would be harsh...
<Rinchen> hmm I must have misread timeanddate.com then
<thumper> for NZ take UTC and add 12 hours
<thumper> I could do 6am
<thumper> but 5am is a little harsh
<Rinchen> yeah, indeed
<Rinchen> we could move the meeting up
<Rinchen> but even at 14:00 it'll be 2am
<barry> me
<danilos> vote?
<thumper> votes suck
<thumper> :-)
<flacoste> yeah, the antipodeans are underpresented
<Rinchen> because they are mostly asleep still
<danilos> thumper: we can vote on that too :)
<carlos> let's open a Launchpad poll!!
<gmb> flacoste: I think you mean under*rep*resented.
 * carlos hides
<Rinchen> kiko, opinions
<gmb> Unless they're sartorially shoddy...
<flacoste> gmb: that also ;-)
<bigjools> it's going to suck for *someone* whatever we do
<kiko> I think we shouldn't change the date, as much as it pains northerners
<kiko> or the time
<SteveA> me
<Rinchen> yeah, even the meeting spreadsheet doesn't help us due to our diversity
<intellectronica> how about rotation, so it only sucks some of the time?
<kiko> this meeting time is totally geared towards tim -- if we change it to be one hour closer to death from him, we've failed
<thumper> my only suggestion would be to have rotation
<thumper> intellectronica: exactly
<kiko> a lot of people would miss meetings, I suspect
<kiko> rotations are really confusing
<kiko> well, here's my proposal
<schwuk> they are
<bigjools> thumper: just move back to London :)
<Rinchen> I agree because they wouldn't know when the meeting would be
<sinzui> The sparsest population is San Francisco and Denver. Should we move the meeting to 13:00
<adeuring> an email reminder can help
<kiko> thumper decides whether it's 18:00 or 17:00 UTC
<kiko> and we try a rotation for the team leads meeting for 2 weeks
<kiko> if it works for that smaller group we can try it for the larger group
<Rinchen> (which starts on Monday)
<thumper> 18:00
<kiko> is that workable for the next 2 weeks?
<Rinchen> ok by me but I'm not affected
<Rinchen> anyone deeply opposed?
<danilos> any chance to get a more relaxed excuses for missing meetings then?
<Rinchen> I'd say take that discussion up with your manager.
<jtv> ...who is sitting right next to him
<Rinchen> I have no problem with it so long as it's not a regular occurrence and someone covers for you
<Rinchen> covers and provides feedback about the meeting of course
<kiko> danilos, it's only one meeting a week -- it's not like you don't get a lot of flexibility otherwise.
<stub> Is this meeting still considered essential for everyone now the teams have grown and been reorganized? (assuming yes, but I don't know if this has been discussed)
<kiko> I can see that if it's after 10pm or before 7am it's nasty
<kiko> I think the meeting is one thing that helps ensure people are on the same page in a number of things
<danilos> kiko: that's true, but see stub
<kiko> danilos, I'm really sympathetic to stub, jtv and thumper for that reason
<intellectronica> let's discuss this again after you've experimented with rotation for  for the team leads meeting. no point going on about this for hours here and how
<kiko> okay
<kiko> fair enough. thanks
<barry> kiko: i don't care what you do, just be sure to send a very clear email to the list stating when the next meeting is ;)
<kiko> barry, in what timezone? :)
<kiko> heh
<Rinchen> [AGREED] try rotating the team leads meeting to see how well that works for everyone. If it works well we'll consider rotating the larger LP meetings.
<MootBot> AGREED received:  try rotating the team leads meeting to see how well that works for everyone. If it works well we'll consider rotating the larger LP meetings.
<kiko> [AGREED] keep meeting at 18:00 for the next 2 weeks
<barry> kiko: us eastern of course <wink>
 * kiko kicks fucking MootBot 
<Rinchen> [AGREED] keep meeting at 18:00 for the next 2 weeks
<MootBot> AGREED received:  keep meeting at 18:00 for the next 2 weeks
<Rinchen> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<Rinchen> both have been worked on
<Rinchen> flacoste, any commentary on the librarian?
<Rinchen> none is ok
<flacoste> Rinchen: kiko and I had a call, and it seems that the issue is similar to the app server
<flacoste> Rinchen: so i'm investigating that first
<Rinchen> k, thanks. We'll come to that topic shortly
<Rinchen> [TOPIC] Oops report (Matsubara)
<MootBot> New Topic:  Oops report (Matsubara)
<matsubara> Today's oops report is about bugs 209892, 211394, 211423
<ubotu> Launchpad bug 209892 in launchpad-bazaar "LaunchpadValidationError raised while registering a branch using the xmlrpc interface" [Undecided,New] https://launchpad.net/bugs/209892
<ubotu> Launchpad bug 211394 in launchpad-bazaar "OOPS deleting a branch" [Undecided,New] https://launchpad.net/bugs/211394
<ubotu> Launchpad bug 211423 in malone "OOPS in the email interface when inactive account tried to file a new bug" [Undecided,New] https://launchpad.net/bugs/211423
<matsubara> mwhudson, since you commented on #209892, and wrote that code, can you take it?
<matsubara> thumper, who from your team should take 211394?
<matsubara> intellectronica, can you take 211423?
<mwhudson> matsubara: oh right yes
<thumper> matsubara: I'll work with abentley on 211394
<intellectronica> matsubara: i can take a look at 211423, since i'm doing emaily stuff anyways
<matsubara> that was smooth! thanks guys
<matsubara> I'm done Rinchen. back to you
<Rinchen> [AGREED] mwh to work on bug 209892
<MootBot> AGREED received:  mwh to work on bug 209892
<Rinchen> [AGREED] intellectronica to look at bug 211423
<MootBot> AGREED received:  intellectronica to look at bug 211423
<ubotu> Launchpad bug 211423 in malone "OOPS in the email interface when inactive account tried to file a new bug" [Undecided,New] https://launchpad.net/bugs/211423
<Rinchen> I'm trying to do more of these per feedback from the Ozzies
<Rinchen> [AGREED] Thumper and abentley to look at bug 211394
<MootBot> AGREED received:  Thumper and abentley to look at bug 211394
<Rinchen> [TOPIC] Critical Bugs (Rinchen)
<MootBot> New Topic:  Critical Bugs (Rinchen)
<ubotu> Launchpad bug 211394 in launchpad-bazaar "OOPS deleting a branch" [Undecided,New] https://launchpad.net/bugs/211394
<Rinchen> two for today
<mwhudson> Rinchen: +1
<Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/206654
<Rinchen> This is the memory issue. flacoste, SteveA - is there anything anyone else can do to help?
<MootBot> LINK received:  https://bugs.edge.launchpad.net/launchpad/+bug/206654
<kiko> Rinchen, SteveA and flacoste have a good plan
<kiko> Rinchen, flacoste's working hard on some diagnostic code -- let's wait to see that deployed.
<Rinchen> good deal. I didn't think there was much we could add
<Rinchen> [LINK] https://bugs.edge.launchpad.net/rosetta/+bug/209859
<Rinchen> jtv, what's your plan for your popularity issue?
<MootBot> LINK received:  https://bugs.edge.launchpad.net/rosetta/+bug/209859
<jtv> Rinchen: ?
<jtv> Rinchen: ah, that.
<jtv> Rinchen: memory errors are fixed now, so it's not quite as urgent anymore.
<jtv> Rinchen: so will look into that in more detail later.
<Rinchen> jtv, should it be high rather than critical?
<kiko> yes
<jtv> Rinchen: now, yes.
<mthaddon> jtv, have we confirmed the memory error fix works as expected?
<Rinchen> jtv, would you do the honours?
<jtv> mthaddon: yes, thanks for the quick rollout
 * jtv does honours
<Rinchen> [AGREED] downgraded bug 209859 to high as it's not as much of an issue now
<MootBot> AGREED received:  downgraded bug 209859 to high as it's not as much of an issue now
<ubotu> Bug 209859 on http://launchpad.net/bugs/209859 is private
<ubotu> Bug 209859 on http://launchpad.net/bugs/209859 is private
<Rinchen> heh
<Rinchen> thanks
<Rinchen> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<Rinchen> we have 1
<Rinchen> intellectronica, javascript
 * kiko snickers as he fixed his!
<Rinchen> https://help.launchpad.net/TaggingLaunchpadBugs
<kiko> I approve javascript
<thumper> +1
<matsubara> +1
<sinzui> +2
<Rinchen> Any objections?
<intellectronica> sounds like a consensus to me
<kiko> no
<cprov> no
<Rinchen> [AGREED] javascript bug tag approved, intellectronica to update the wiki
<MootBot> AGREED received:  javascript bug tag approved, intellectronica to update the wiki
<Rinchen> [TOPIC] Operations report (mthaddon/herb)
<MootBot> New Topic:  Operations report (mthaddon/herb)
<herb> 2008-03-31 - edge2 died. nothing in nohup.out. restarted.
<herb> 2008-03-31 - Cherry pick 5977
<herb> 2008-04-02 - edge3 died, no coredump. restarted.
<herb> 2008-04-02 - Cherry pick 5992
<herb> 2008-04-02 - edge1 died during logrotate.  restarted.
<herb> We're going to be testing a new staging update script which might cause staging update errors over the next couple of days. Tom and I will be watching closely.
<herb> Cherry pick 5992 had issues due to the new config format.
<herb> Multiple restarts of both edge and production app servers daily due to memory leaks.
<mthaddon> I'd also like to bring up the issue of rocketfuel-built inconsistencies that I'd mailed to the list
<kiko> herb, what's the issue with the staging update script?
<mthaddon> kiko, we're adding an option to allow non DB-import version
<herb> kiko, no issue, just a change in the way we deploy the code.
<mthaddon> kiko, at the moment, non-DB import on staging is manual - we're adding it as an option to the script so it can be consistent and quicker in the future
<kiko> gotcha
<kiko> nice job!
<Rinchen> Anything else for herb or mthaddon ?
<mthaddon> thx, rocketfuel-built inconsistencies, anyone?
<kiko> the deaths of edge due to links?
<Rinchen> ah yes
<kiko> mthaddon, you got a reply on list about that?
<kiko> it's something to take up with lifeless afaik
<kiko> err
<mthaddon> kiko, yeah, but wasn't very revealing - okay, will take up with lifeless
<kiko> the deaths of edge due to leaks?
<herb> kiko, most likely.
<LarstiQ> leaks make a lot more sense than links :)
<kiko> mthaddon, the inconsistencies were pretty minor, right -- just perms?
<kiko> LarstiQ, talking on the phone at the same time ruins me :-/
<mthaddon> kiko, yeah, just perms, but creates noise on a new production code checking script we're putting in place
<Rinchen> further discussion?
<mthaddon> but anyway, that's it from me
<kiko> gotcha
<kiko> thanks
<Rinchen> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<stub> Currently our full text indexes are only indexing the first 2.5k of text for a row. This is screwing up package searchi (Bug 207969). I'll be landing a patch that turns off this limit so we can test on staging to see if anything blows up. I think the limit is left over from limitations on earlier PG versions.
<stub> I want to have the auth/person split finalized next week and implementation started. I need to go over the options and recommendations with Mark first.
<stub> I've been seeing more idle open transactions being killed by our transaction reaper - fiera and poexport I think. These should be obvious in the OOPS report (server closed connection). If this is a problem and can't be fixed in the short term let me know and we can discuss increasing the timeouts.
<ubotu> Launchpad bug 207969 in soyuz "ppa search fail to return expected results on some cases" [High,Fix committed] https://launchpad.net/bugs/207969
<stub> We have two options for migrating to PG 8.3. Do it whenever while the data centre machines are running dapper and take around a 3.5 hour downtime hit, or wait until the DC machines are running hardy and we can run Slony-I. This will allow us to do the migration with a few minutes of downtime. I'm thinking waiting for Hardy unless elmo wants to delay DC upgrades for some reason.
<stub> All for now.
<danilos> stub: fyi, those 'poexport' leftovers could be from manual killings of poexport script to solve some problems
<kiko> stub, I'm hoping for hardy soon, too
<kiko> let's see what the release looks like
<stub> Ok. I can't tell from my end.
 * stub nods
<Rinchen> Thanks stub
<Rinchen> anything further for stub?
<Rinchen> [TOPIC]  Sysadmin requests (Rinchen)
<MootBot> New Topic:   Sysadmin requests (Rinchen)
<Rinchen> Hi! Is anyone blocked on an RT or have any that are becoming urgent?
<Rinchen> I know about the usual suspects from last week
<kiko> Rinchen, BjornT will be wanting to talk to elmo about setting up a debbugs instance
<jtv> Rinchen: #30384 is pretty important to us.
<jtv> But it's brand-new.
<BjornT> kiko: we'll be having a call about it tomorrow
<kiko> BjornT, owwsom
<Rinchen> BjornT, let me know how it goes.
<Rinchen> jtv, got it
<Rinchen> any others?
<bigjools> Rinchen: any eta for mine?
<Rinchen> bigjools, none, or kiko's either.  IS is working on several things, many to prep for hardy as I understand
<kiko> yeah
<Rinchen> but I'll keep after them
<Rinchen> [TOPIC] New packages required (salgado)
<MootBot> New Topic:  New packages required (salgado)
<mthaddon> jtv, isn't that just setting up launchpad_langpack?
<salgado> if any of the branches you're working on right  now depends on any library which is not part of the launchpad-dependencies      package, come talk to me ASAP.
<kiko> salgado, there is a big hardy shakeout happening eh?
<jtv> mthaddon: basically, though no longer as standby for production
<kiko> will that affect lp-devel-deps
<mthaddon> I thought we'd agreed to use launchpad_staging for that?
<salgado> kiko, hardy shakeout?
<Rinchen> yeah, what should we do about python-xml?
<kiko> well, the upgrade causing issues left and right with our dependencies
<jtv> mthaddon: we feel like messing with the schema.
<carlos> mthaddon: it's just for a big branch we are working on
<carlos> mthaddon: in general stating is enough
<mthaddon> jtv: well that didn't last long... :(
<jtv> s/stating/staging/
<carlos> s/stating/staging/
<salgado> I think in the long term we should replace python-xml with something else
<kiko> mthaddon, hey, this is software engineering! :)
<Rinchen> I'm currently running and older copy per salgado's email
<jtv> engineering is blowing stuff up.
<flacoste>  salgado: i suggest the ElementTree API
<stub> (which means we make it up as we go along)
<kiko> what flacoste said
<salgado> jtv, carlos, danilos, is that feasible?
 * intellectronica blows his nose
<kiko> stub, (you and me think alike)
<flacoste> salgado: several libraries provide that interface (lxml, cElementTree, ElementTree, there is even a BeautifulSOupwrapper for it)
<kiko> flacoste, ah, there's a wrapper you tell me now!!
<danilos> salgado: would need investigation, we are parsing DTD, not XML
<Rinchen> we also use py xml for new branch creation when running make schema
<flacoste> kiko: not the way we need for our pagetests though
<kiko> flacoste, </3
<flacoste> kiko: it to use the ELementTree API with BeautifulSoup
<mwhudson> Rinchen: eh, really?  is that not something that just gets imported by the by?
<kiko> mwhudson?
<Rinchen> make-dummy-hosted-branches
<Rinchen> mwhudson, I haven't checked it in detail though
<kiko> I am concerned that the hardy upgrade will cause big shakeouts in lp-deps and we are skewed further from production
<kiko> but I guess we'll just need to keep a special eye out for version upgrades
<kiko> and file bugs against ubuntu
<kiko> btw
<kiko> please escalate ubuntu packaging bugs to joey
<kiko> and I'll work with him to make sure they are fixed
<Rinchen> deal
<kiko> before hardy releases
<salgado> kiko, I don't see what is your concern. the only problem we've seen so far is with python-xml and python-pkg-resources
<kiko> this is really important, because otherwise we're at a distro blind spot just filing bugs
<carlos> Rinchen: https://bugs.edge.launchpad.net/bzr/+bug/208418
<ubotu> Launchpad bug 208418 in bzr "ValueError when trying to pull/merge from a remote repository" [Critical,Confirmed]
<kiko> salgado, that's two packages already
<salgado> the latter not being in lp-deps so not really a problem
<kiko> and counting
<kiko> well.. so yes, this problem goes beyond deps, salgado
<kiko> what's your point? should we not worry? :)
<salgado> we should
<kiko> okay! :)
<salgado> I just don't expect it to be a big deal
<salgado> maybe I'm just too optimist
<kiko> well, it's a big deal if we need to pin or downgrade packages past the hardy release
<kiko> let's make sure we get these fixed before that.
<kiko> over and out! send bugs to Rinchen
<Rinchen> [AGREED] there is concern that hardy will affect our dependencies. e.g. python-xml no longer contains a module we need.  Devs to provide bugs of this sort to Rinchen for follow up
<MootBot> AGREED received:  there is concern that hardy will affect our dependencies. e.g. python-xml no longer contains a module we need.  Devs to provide bugs of this sort to Rinchen for follow up
<Rinchen> [TOPIC]  A top user-affecting issue (mrevell)
<MootBot> New Topic:   A top user-affecting issue (mrevell)
<mrevell> Yo.
<kiko> Yo!
<mrevell> other than the POT export failure, which the Translations guys are dealing with, I haven't seen any major issues this week. However, in the launchpad-users thread on bug noise, Bruce Cowan links to a fascinating blog post and comment discussion on karma hunting (http://www.sourcecode.de/content/dealing-with-bugs-no-karma-hunting). The suggestion is that some people edit bugs in an unhelpful manner simply to boost their karma. It
<mrevell> makes interesting reading, even if just to see views on how karma influences people's actions in LP.
<kiko> I should read that, I have lots of karma
<Rinchen> We've had amazing OpenID feedback since we launched too..... amazing as in a lot of it
<mrevell> I would be interested to hear from anyone else who has seen a user-affecting issue that they'd like to discuss, though.
<stub> The fact I still get Bug #1 spam (and other bugs too) bugs me
<kiko> stub, is that bug invalidated for Launchpad?
<mwhudson> yes
<kiko> I was looking at https://bugs.edge.launchpad.net/malone/+bug/83488
<ubotu> Launchpad bug 83488 in malone "Implicitly unsubscribe bug contact when bug is Invalid" [Undecided,Confirmed]
<kiko> today
<stub> So invalid targets shouldn't get mail any more? Cool.
<kiko> I wish it weren't so controversial
<mwhudson> (there's a bug about this problem too, i think)
<kiko> yes
<kiko> there is
<statik> I was really pleased to note yesterday that zed shaw started using bazaar and launchpad http://www.zedshaw.com/projects/vellum/
<kiko> that's very cool
<kiko> I've been seeing lots of people request project groups
<mrevell> statik: nice hat
<kiko> so
<statik> ah, that reminds me!
<statik> user affecting issue
<statik> when people start using launchpad
<statik> they almost ALWAYS forget to link their bazaar branch to the trunk series
<abentley> kiko: I think that unsubscribing from the bug is wrong.  There should be a way to delete the BugTask.
<statik> which means that bzr get lp:project doesn't work
<abentley> There are *lots* of annoying things about the continued existence of invalid bugtasks.
<thumper> statik: I tried to make that a bit more obvious on the project code page
<thumper> st
<thumper> statik: perhaps we need to work out a better way
<thumper> statik: mdz suggested making "bzr push lp:project" autolink
<statik> thumper: yeah, I've just realized over the last week that almost every new project i saw in launchpad I had to email them and tell them to hook up their branch to trunk
<thumper> statik: which requires api's to work as a privledged user
<thumper> but would be cool
<barry> statik: happens to me all the time, and i /know/ i have to do that
<mwhudson> thumper: something for the branch/+new page too?
<kiko> abentley, well.. deleting bugtasks is a possibility, too. it's just nastier and gives off a different impression than invalidation.
<mwhudson> if user is owner and there is no trunk.user_branch then ...
<thumper> mwhudson: perhaps...
<kiko> good call mwhudson
<thumper> mwhudson: best to talk with poolie, but he might agree
<mwhudson> doesn't help if the user doesn't use the +new page
<mwhudson> thumper: right
 * Rinchen glances at the clock.
<Rinchen> I'm going to move on then....
<Rinchen> thanks for the discussion
<Rinchen> [TOPIC] Doc Team report (mrevell)
<MootBot> New Topic:  Doc Team report (mrevell)
<mrevell> Howdy. I've published the new Help wiki home page, along with the YourAccount, Teams and Projects sections of the new user guide. In the mean time, while waiting for the new user guide sections, I've linked to existing material in the "user guide" section of the new front page.
<mrevell> Following on from last week's meeting, we've had a positive response to the idea of a frequent update detailing changes on edge. We seem to have a split, right now, between those who'd prefer a feed and those who are happy with email. I'd say using the beta testers team's mailing list for these updates would be the least-effort option right now.
<mrevell> However it's presented, beta team members seem keen to get this information, as it'll enable them to actively test things we haven't announce in some other way, rather than stumble across them.
<mrevell> The only real time-drag I can see, in actually producing the report, is finding if the feature/fix has made it to edge.
<mrevell> thanks Rinchenator
<gmb> mrevell: Can we not create a script for you that would do the hard work?
<kiko> mrevell, we should probably just stick this on edge itself..
<mrevell> kiko: In the way poolie suggested?
<gmb> That sounded more subservient than I'd intended...
<kiko> i.e. in a hideable element present overlayed
<Rinchen> I rather liked poolies NEWS idea
<kiko> yeah
<mwhudson> mrevell: doesn't the "build 6002" thing in the footer help with that?
<Rinchen> but it's an extra step to do news
 * mwhudson has unpleasant thoughts about conflicts
<mrevell> mwhudson: Yeah, it would, although commit 6001 might not be on edge because a db change
<abentley> Let everyone create a description of their feature.  One per file, so you don't get conflicts.  Require it in reviews.
<mwhudson> mrevell: uh
<thumper> abentley: ah, a news.d directory
<mwhudson> mrevell: either you or i are confused here :)
<mrevell> mwhudson: Or am I confused?
<mrevell> mwhudson: Most likely me :)
<abentley> thumper: Pretty much.
<mwhudson> mrevell: lets take this elsewhere
<mrevell> mwhudson: k
<Rinchen> The advantage of a news.d directory or similar is that we can feed that automagically
<Rinchen> rather than mrevell having to sift through commits to produce something
<thumper> and no conflicts
<thumper> (with suitable naming scheme)
<kiko> I'm not opposed to it
<kiko> would engineers be discliplined enough about it, though?
<Rinchen> yeah. I'm happy to try to automate something else but the key for me is that it be automated...and not time consuming.
<kiko> Rinchen, hold a vote?
<thumper> how about a directory called "edge-news"?
<kiko> well, it's not really just edge news
<mrevell> I'd always be available to help write or review these news snippets.
<kiko> if we do it that way
<statik> that's interesting, as the news entry would then be part of the code review
<thumper> kiko: they only need to write something if they want explicit testing
<kiko> it's news.d really
<kiko> thumper, explicit announcement, I hope you mean?
<mrevell> thumper: Yeah, simple bug fixes or whatever wouldn't need it.
<thumper> well, yea
<danilos> warning: we are over time already ;)
<kiko> this isn't just for testing
<mrevell> I'll open a thread on the ML
<kiko> it's for communicating to people what we're doing
<stub> News on edge is different to News on production ('Please beta test this new feature' vs. 'here is this cool new feature')
<kiko> agreed
<kiko> though one is a batched and subsetted form of another if you provide a full changelog
<kiko> I'm not sure -- just musing
 * sinzui rescues children from state institution. 
<kiko> anyway, good plan with mrevell opening a thread, let's just not drop it
<abentley> So tragic to be institutionalized so young.
<kiko> moveing on
<Rinchen> mrevell, let's chat about this when you have time
<kiko> movieing on
<mrevell> Rinchen: sho thang
<Rinchen> it's that time again...
<Rinchen> [TOPIC] Blockers
<MootBot> New Topic:  Blockers
<jtv> Translations: more Kiko please!
<flacoste> Foundations: not blocked
<cprov> Soyuz Team: not blocked
<BjornT> Bugs: not blocked
<Rinchen> Releases Team: Not blocked too badly. :-)
<thumper> Code: not blocked
<kiko> jtv, now with added 99% more kiko
<adeuring> hwdb: not blocked
<jtv> kiko: yummy
<cprov> Soyuz team: P3A RT from bigjools (correction)
<Rinchen> [AGREED] soyuz team blocked on the RT
<MootBot> AGREED received:  soyuz team blocked on the RT
<Rinchen> statik?
<Rinchen> SteveA?
<statik> lopcomm: not blocked
<statik> lpcomm even
<kiko> SteveA's out
<Rinchen> very well then
<Rinchen> Shazam!
<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 20:55.
<kiko> thanks joeyey
<thumper> thanks Rinchen
<kiko> it's great when the meeting overruns!
<intellectronica> thanks Rinchen, great meeting
<mrevell> Thanks rinchen, thanks everybody.
<Rinchen> Thanks gents
<statik> thanks everyone for a very informative meeting (especially those at odd timezomens)
<abentley> Thanks everybunny
<mwhudson> thanks all
 * mwhudson goes for more caffeine
<schwuk> Thanks Rinchen
<carlos> thanks *
<mrevell> Right, I'm off to drink a flat pint of brown beer, eat jellied eels and wallow in some other stereotypes.
#launchpad-meeting 2008-04-04
<jsk> Rinchen, jtv: yo
<jsk> Rinchen, jtv: :)
#launchpad-meeting 2009-04-02
<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
<rockstar> me
<herb> me
<cprov> me
<sinzui> me
<matsubara> Ursinha:
<Ursinha> me
<stub> me (on the right server this time)
<danilos> me (if no call)
<flacoste> me
<matsubara> intellectronica: hi
<intellectronica> me
<matsubara> all right, everyone 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 (stub)
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>   * intellectronica to make efforts to take a look at bug 329908
<matsubara>   * sinzui to talk to kiko about pending cp requests
<ubottu> Launchpad bug 329908 in malone "DownloadFailed OOPS when reporting a bug with apport (dup-of: 349646)" [Undecided,New] https://launchpad.net/bugs/329908
<ubottu> Launchpad bug 349646 in malone "apport uploads not being found in +filebug" [Undecided,Fix released] https://launchpad.net/bugs/349646
<intellectronica> matsubara: that's fixed
<matsubara> well, sinzui's one is not needed anymore since that's been released
<matsubara> thanks intellectronica
<sinzui> matsubara: I removed the requests because it was close to the rollout and the items were not critical
<matsubara> sinzui: sure. thanks for checking
<matsubara> moving on
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
 * sinzui has a question about what is critical for unmaintaines app
<matsubara> Ursinha: ?
<Ursinha> me
<Ursinha> 4 bugs to talk about
<Ursinha> matsubara wants to talk about bug 353530
<Ursinha> â¢ bigjools, bug 347194, fixed as RC but still appears on lpnet
<Ursinha> â¢ sinzui: bug 353863
<Ursinha> â¢ bigjools, bug 353568, timeout at +source/package page
<ubottu> Launchpad bug 353530 in malone "OOPS filing a bug using the email interface " [Undecided,New] https://launchpad.net/bugs/353530
<matsubara> sinzui: good question. You mean blueprint stuff?
<ubottu> Launchpad bug 347194 in soyuz "IntegrityError: duplicate key value violates unique constraint "binarypackagerelease_binarypackagename_key"" [High,Fix committed] https://launchpad.net/bugs/347194
<ubottu> Launchpad bug 353863 in launchpad-registry "TypeError when finishing creating user account in lpnet" [Undecided,New] https://launchpad.net/bugs/353863
<ubottu> Launchpad bug 353568 in soyuz "ubuntu/source/package/+index timing out" [High,Triaged] https://launchpad.net/bugs/353568
<Ursinha> should we raise bug 353568 to critical?
<matsubara> sinzui: I think we need to raise that question in the list
<matsubara> cprov: what's up wit hteh ones bigjools fixed?
<flacoste> me again
<matsubara> hi francis
<flacoste> another X lock-up
<flacoste> what did i miss?
<matsubara> we're doing the oops section
<Ursinha> flacoste, the bugs we'll discuss
<sinzui> Ursinha: That looks like a critical bug to me
<cprov> matsubara: I don't know, AFAICT it's not fixed.
<matsubara> so far nothing for foundations
<sinzui> Ursinha: I will give it to salgado who is already looking into login/account issues
<Ursinha> sinzui, I couldn't reproduce that, don't know if matsubara tried that
<matsubara> those oopses are likely to be candidates for RC and next re-roll
<Ursinha> for sure
<matsubara> Ursinha: I did not
<Ursinha> thanks sinzui
<flacoste> what login/account issues are we having?
<sinzui> Ursinha: salgado saw many oopses he could not reproduce, but I think he can at least explain why
<cprov> matsubara: I will look at it this afternoon, maybe I can do something quick to stop the timeout in production
<Ursinha> flacoste, bug 353863
<ubottu> Launchpad bug 353863 in launchpad-registry "TypeError when finishing creating user account in lpnet" [Undecided,New] https://launchpad.net/bugs/353863
<salgado> I'll need help with this one
<matsubara> re: bug 353530, intellectronica could you take a look? it's about the OOPS in filing bug using the email interface but I'm not sure that scpecific oops is under Bugs responsability
<ubottu> Launchpad bug 353530 in malone "OOPS filing a bug using the email interface " [Undecided,New] https://launchpad.net/bugs/353530
<matsubara> cprov: cool. thanks
<intellectronica> matsubara: according to steve's comment that's another case of missing permissions
<intellectronica> but i'm not clear whether it was dealt with. i'll check
<matsubara> I'm going to add those to the CurrentRolloutBlockers page and use that page to coordinate things that will go in for the re-roll
<Ursinha> matsubara, afaik that was just fixed by adding the user to the conf file in the server
<matsubara> intellectronica: seems to be dealt with, but my question is more in the sense on how we can avoid that in the future
<Ursinha> as per spm explanations
<Ursinha> to me
<matsubara> so, apparently it was a unusual rollout requirement but nobody added it there
<matsubara> Ursinha: don't say server, we have at least 10 "servers" out there :-)
<Ursinha> matsubara, sorry :) s/server/server in which the conf was missing/
<matsubara> anyway, glancing at it, could be that the slaves were missing the right config?
<intellectronica> so it seems
<rockstar> matsubara, might that be a question for the db report section?
<flacoste> Ursinha, matsubara: we should add test for missing permission
<flacoste> matsubara: did you file a bug about the one you wanted me to discuss with stub?
<matsubara> flacoste: nope, but I have the pastebin here. I'll file a bug about it right after the meeting
<matsubara> [action] matsubara to file a bug about the missing select permissions that delayed the rollout
<MootBot> ACTION received:  matsubara to file a bug about the missing select permissions that delayed the rollout
<flacoste> thanks
<matsubara> [action] cprov to look up soyuz bugs 347194, 353568
<ubottu> Launchpad bug 347194 in soyuz "IntegrityError: duplicate key value violates unique constraint "binarypackagerelease_binarypackagename_key"" [High,Fix committed] https://launchpad.net/bugs/347194
<MootBot> ACTION received:  cprov to look up soyuz bugs 347194, 353568
<ubottu> Launchpad bug 353568 in soyuz "ubuntu/source/package/+index timing out" [High,Triaged] https://launchpad.net/bugs/353568
<cprov> matsubara: the first one is fixed
<matsubara> err, sorry about that, I'll edit that entry
<matsubara> [action] matsubara to edit #347194 out of the last action :-)
<MootBot> ACTION received:  matsubara to edit #347194 out of the last action :-)
<cprov> matsubara: some errors happened yesterday because I had to reprocess a bunch binary uploads that failed after the rollout (due the absence of the launchpad_auth DB user)
<Ursinha> cprov, now it makes sense
<matsubara> ah, so that also affected other things other than the email interface.
<Ursinha> thanks :)
<cprov> Ursinha: yes, it was a nightmare, because the buildfarm was full and binaries could not be processed due to the lack of DB access
<matsubara> [action] matsubara to include francis suggestion to bug 353530 and ursinha to summarize what spm told her
<ubottu> Launchpad bug 353530 in malone "OOPS filing a bug using the email interface " [Undecided,New] https://launchpad.net/bugs/353530
<MootBot> ACTION received:  matsubara to include francis suggestion to bug 353530 and ursinha to summarize what spm told her
<Ursinha> indeed
<matsubara> salgado: how can we help you with that one?
<salgado> matsubara, I'll let you know once I know. :)
<matsubara> [action] salgado to debug and fix bug 353863
<ubottu> Launchpad bug 353863 in launchpad-registry "TypeError when finishing creating user account in lpnet" [Undecided,New] https://launchpad.net/bugs/353863
<MootBot> ACTION received:  salgado to debug and fix bug 353863
<matsubara> I think I addressed everything
<danilos> Ursinha: has there been any outcome of the timeout discussion?
<matsubara> so, as usual after the release we are going to monitor the oops reports constantly and coordinate with the teams about any new oopses
<Ursinha> danilos, I'm going to talk about it with stub in his section
<danilos> Ursinha: ok, thanks
<danilos> sorry for not following the script, I forgot my lines :)
<Ursinha> danilos, :)
<matsubara> [action] sinzui to email the list how we should address critical bugs on unmaintained apps (e.g. blueprint)
<MootBot> ACTION received:  sinzui to email the list how we should address critical bugs on unmaintained apps (e.g. blueprint)
<matsubara> sinzui: ^ is that correct?
<sinzui> matsubara: yes
<matsubara> ok, I think that's all for this section. All the critical ones are being handled
<matsubara> thanks everyone
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> 2009-03-30 - Experienced some DB problems that affected the service. Launchpad was unavailable for approximately 9 minutes. stub sent out an email summarizing the issues.
<herb> 2009-03-30 - Cherry picked r8054 and part of r7999.
<herb> 2009-04-01 - Rollout of 2.2.3. Total downtime was approximately 100 minutes. I think there were a few hiccups on some DB permissions, but I haven't had an opportunity to catch up with mthaddon and spm on the details.
<herb> Bug 156453 and bug 118625 continue to be a source of discomfort. I think rockstar has an update on these though.
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,In progress] https://launchpad.net/bugs/156453
<herb> Bug 80895 and bug 119420 are a pain point for the LOSAs. I think something may have been scheduled for this cycle on this front. If so that's a total win from our point of view.
<ubottu> Launchpad bug 118625 in launchpad-bazaar "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/118625
<herb> When do we think we'll be doing a re-roll?
<ubottu> Launchpad bug 80895 in malone "Give people five minutes to edit/delete their comment" [Undecided,Confirmed] https://launchpad.net/bugs/80895
<ubottu> Launchpad bug 119420 in launchpad-answers "Cannot edit a comment" [Medium,Triaged] https://launchpad.net/bugs/119420
<rockstar> herb, I can has update!
<rockstar> :)
<herb> woo!
<rockstar> So we have a memory middleware currently that's allowing us to track down memory issues.
<rockstar> herb, also, mwhudson and jam have been writing a C-based memory profiler as well, so we can track refs even better in bzrlib itself.
<herb> excellent
<matsubara> herb: I'll let you know about the re-roll once we know. :-)
<herb> matsubara: appreciated.
<rockstar> herb, unfortunately, I can't really tell if the "sometimes hangs" bug is related to the "leaks memory" bug.
<matsubara> herb: re: the DB permission, I'm going to file a bug about it and flacoste and stub will discuss it :-)
<herb> rockstar: I suspect so, but fixing the memory issue would be a huge win.
<stub> its not a bug, it was an operational issue
<Ursinha> indeed
<rockstar> herb, yes.  If they are unrelated, it's probably a bug in one of our dependencies.
<stub> erm... if you are talking about the same one i'm thinking off.
<matsubara> stub: I'm talking about the permission for the SSO user
<stub> ok. different ;)
<matsubara> :-)
<matsubara> ok, anything else for herb?
<matsubara> thanks herb.
<herb> thanks matsubara
<matsubara> and thank mthaddon and spm for the handling the rollout so well too!
<matsubara> moving on.
<herb> matsubara: will do
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> Todays Database update ran in about 100 mins with all replicas enabled. Earlier calculations indicated the downtime would be a bit under three hours. The discrepancy is staging isn't as powerful and normal staging operations are underway during the restore.
<stub> This was good from a downtime perspective, but does mean we can no longer get reliable rollout timings from staging. When rollout times are a concern, we might have to test the database upgrade process on a production server and calculate the time from there.
<stub> I want to switch our master database to the new 16 core box from the current 8 core box in the next two weeks. This will require a few minutes downtime - I think a scheduled 10 minute outage will suffice. We might want to double up if there is other downtime required in the near future.
<stub> A few days ago, generating a table bloat report managed to mess up PostgreSQL, causing all queries to the master to generate nothing but errors. A forced restart was required, causing a few minutes of downtime total The cause has been tracked down and is being worked on upstream, and we can avoid it now we know what it is (don't feed temporary tables to pgstattuple).
<stub> I've opened a couple of bugs about batch jobs that are taking too long. I generally don't care how long things take as long as their impact is light, but staging updates and post rollout processes are approaching 24 hours...
<stub> A number of problems where caused by missing PostgreSQL authorization to the new launchpad_auth user on production. This authorization was added to staging, but missed getting into the production rollout tasks. spm sorted it a few hours after the rollout as I understand it. This is a purely operational issue outside the scope of our test suite (staging is the test bed for database connection authorizations). Ignore OOPSes and bugs like 3535
<stub> All from me.
<stub> Bug 353530
<ubottu> Launchpad bug 353530 in malone "OOPS filing a bug using the email interface " [Undecided,New] https://launchpad.net/bugs/353530
<Ursinha> stub, I have one oops, I don't know if it was just a hiccup
<Ursinha> stub, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1188D1214
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1188D1214
<matsubara> [action] matsubara to talk to mrevell to announce a maintenance in the DB for about 10 min outage in the next 2 weeks. ask mrevell to talk to stub about it
<MootBot> ACTION received:  matsubara to talk to mrevell to announce a maintenance in the DB for about 10 min outage in the next 2 weeks. ask mrevell to talk to stub about it
<stub> Ursinha: Thats a bug needing fixing.
<Ursinha> stub, I'll file a bug about it now
<Ursinha> about the timeouts we mentioned during the week
<Ursinha> it seems they indeed dropped
<Ursinha> the major responsible now is the source package index page
<Ursinha> danilos, ^
<stub> Ok. So we need to be even less aggressive doing mass data migration.
<Ursinha> if the timeouts continue the next days, we'll have to chase another cause.
<danilos> stub, Ursinha: we'll have something similar coming up, how can we make sure the impact is not felt on our production machines?
<stub> danilos: Either set the acceptable lag setting lower, or a cooldown time after each batch.
<herb> stub: or both?
<danilos> stub: ok, I guess we'll have to experiment with these
<stub> or both
<matsubara> ok. I guess that's all for stub?
<matsubara> thanks stub
<Ursinha> thanks stub
<matsubara> I have a minor annoucement that I forgot to add to the agenda
<matsubara> Next week is our second performance week
<matsubara> so, please add the bugs you're going to work on in https://dev.launchpad.net/PerformanceWeeks/April2009
<matsubara> and I think that's all
<matsubara> anything else before I close?
<matsubara> 3
<matsubara> 2
<matsubara> 1
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<Ursinha> stub, bug 353897
<ubottu> Launchpad bug 353897 in launchpad-foundations "DisallowedStore OOPS in lpnet/+login" [Undecided,New] https://launchpad.net/bugs/353897
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:39.
<flacoste> stub: do you know why that bug is happening?
<flacoste> Ursinha: i guess we should fix this before the re-roll?
<stub> flacoste: a login.launchpad.net page is trying to access the MAIN_STORE, MASTER_FLAVOR which is disallowed (because it needs to keep running when lp is down for maintenance)
<Ursinha> flacoste, 5 occurrences we have registered
<flacoste> on loging!
<flacoste> ok, this needs to be fixed
<Ursinha> on loging
<flacoste> create_unique_token_for_table
<stub> He is spelling login with a Canadian accent
<Ursinha> lol
<flacoste> lol
<flacoste> French Canadian accent!
<stub> flacoste: Or more precisely, a login.launchpad.net page is attempting to create a LoginToken (which it can't) instead of an AuthToken (which it can)
<flacoste> ok
<flacoste> stub: i'll try to give it a shot this afternoon
<stub> flacoste: It is a twisty maze
<flacoste> stub: but i might punt it to you if i cannot complete it :-)
<stub> flacoste: Salgado loves the authentication system.
<flacoste> i think he has his share of problems already
#launchpad-meeting 2010-04-07
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> good morning
<bac> me?
<bac> anyone else?
<salgado> me
<bac> sinzui, danilos, gary_poster, flacoste, deryck, noodles775: ping
<flacoste> me
<gary_poster> yup me sorry
<noodles775> me (sorry)
<gary_poster> was here seconds before your good morning
<gary_poster> will cal trops
<gary_poster> call troops
<sinzui> me
<bac> EdwinGrubbs: ping
<EdwinGrubbs> me
<mars> me
<leonardr> me
<bac> gmb: ping...can you find your TL?
<bac> hmm, no bug types around at all
<gmb> me
<adeuring> me
<abentley> me
 * noodles775 calls jelmer in (as he's started as a mentat).
<bac> thanks noodles775
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * Mentoring update
<bac>  * New topics
<bac>  * Peanut gallery
<danilos> bac, hi, I have a call now (when have we changed the time of the meeting?)
<bac> danilos: we changed a few weeks ago after discussion here
<danilos> bac, I guess that was the week when I was sprinting then
<bac> danilos: sorry if you didn't get updated
<bac> danilos: can you make it next week?
<bac> [topic]  Outstanding actions
<MootBot> New Topic:   Outstanding actions
<danilos> bac, no worries, we'll work something out (I might change the phone call time for next week)
<bac> [topic] thumper/mwh to bring up issues with launchpadlib testing on ML.
<MootBot> New Topic:  thumper/mwh to bring up issues with launchpadlib testing on ML.
<bac> we we discussed the work leonardr did for automating launchpadlib tests, thumper and mwhudson had some concerns
<bac> michael did bring it up on the list but as far as i could tell it was unresolved.
<leonardr> well, i know there were concerns about automatically creating launchpadlib objects
<bac> leonardr or gary_poster do you have any update on possible changes?
<leonardr> i landed a branch that takes that out. you now have to create your own launchpadlib object
<gary_poster> bac, leonardr addressed all concerns to my knowledge.  It is cooler and more flexible now
<bac> leonardr: great
<leonardr> there were also concerns about using the sampledata users, which i also addressed
<leonardr> there's a helper function that will create an oauth access token for any user
<leonardr> so you can create a dummy user and then give them an access token if you want
<leonardr> i think that was it
<bac> leonardr: is it easy to create an object for anonymous access?
<leonardr> bac: i haven't tried it, but Launchpad.login_anonymously() should work in the pagetests just as it does in real life
<bac> ok, good.
<leonardr> one thing we could add to make things nicer is a url alias for 'the launchpad instance accessible to the testrunner'
<leonardr> which is http://api.launchpad.dev/ (not https)
<bac> what do we want to do going forward?  start requiring lplib tests for new API changes?  what about coverage for existing methods?
<bac> i approved some API changes yesterday but didn't require a lplib test.  i think we should.
<leonardr> bac, did you require a test at all?
<bac> leonardr: the webservice test was updated to show the new field
<bac> that was all
<gary_poster> From Foundations' perspective, my main interest is in tests verifying that our critical clients work with the specified webservice version
<leonardr> certainly if it's something that requires a test (and doesn't need to be tested by hacking HTTP requests) an lplib test is better than a webservice() test
<leonardr> we thought of two ways to do what gary says, and i don't think we've decided on one (not that we have to go all one way or the other)
<gary_poster> And from a general perspective, I'm a string +1 on using launchpadib directly now that we have it.  Leonard wrote one (yesterday) that caught a problem that would not have been otherwise caught.
<gary_poster> argh
<gary_poster> strong
<leonardr> the first way is to write a launchpadlib test every time we make a change in (eg.) 2.0 that doesn't bleed through to earlier versions
<leonardr> make sure that 1.0 still has the old behavior, and 2.0 has the new
<leonardr> the other way is to get our critical clients to expose their launchpadlib test suites, and run them as part of the launchpadlib test suite
<leonardr> the apport developers are working on this now. if we run apport's launchpadlib tests as part of launchpad's tests (just as we run launchpadlib's launchpadlib tests) we'll know when we make a change that breaks apport
<abentley> I think the second way more directly supports gary_poster's interest.
<bac> leonardr: that effort is great and something i assume foundations will pursue.  but as reviewers we need to decide how to handle testing of changes to API functionality.  it sounds like you're in favor of using lplib tests over the older web service tests.
<leonardr> bac: yes, unless you're writing a test that needs to send a specific http request
<leonardr> in which case webservice() is better
<bac> that sounds good to me.  the web services tests will require updating when new fields are exposed but the actual tests should be lplib.
<gary_poster> abentley: (agree, and Francis and I have talked about different ways we can attack that.  I suspect that the first way will be appropriate sometimes, particularly for API calls that are heavily used, but this hasn't been hardened yet.)
<bac> anything else on this topic?
<bac> [topic]  * bac to restart discussion on community reviewer/committers after feedback from elmo
<gary_poster> not from me
<MootBot> New Topic:   * bac to restart discussion on community reviewer/committers after feedback from elmo
<abentley> gary_poster, it can be very difficult to predict what kind of changes will break clients.  Some will accidentally depend on bugs, for example.
<gary_poster> abentley: agreed.
<bac> i've been unable to get an opinion from legal about community reviewers/committers but got a strong one from elmo.  i'll share that with the list and start the discussion again.
<bac> apologies for dragging this out.
<bac> [topic] peanut gallery
<MootBot> New Topic:  peanut gallery
<bac> any new topic to discuss?
<bac> oh, wait, backup.
<noodles775> Just an update that Jelmer has started reviewing on Thurs...
<bac> [topic] mentoring update
<MootBot> New Topic:  mentoring update
<noodles775> :)
<noodles775> as a mentat.
<bac> welcome jelmer to the meeting and as a reviewer mentat.
<bac> noodles775:  thanks for doing the mentoring
<jelmer> thanks Brad
<noodles775> bac: np!
 * wgrant wonders in which direction elmo's opinion was.
<bac> so everyone bring lots of good reviews to jelmer on thursdays
<noodles775> Yeah, particularly some non-soyuz ones!
<bac> so, back to the peanut gallery.  are there any other topics?
<bac> 3
<abentley> I am having trouble remembering to attend this meeting
<abentley> And part of it is because it's no longer a weekly meeting.
<flacoste> it's not weekly anymore?
<abentley> Instead of notifying people when it's *not* happening, maybe we could notify people when it *is*?
<bac> abentley: would you prefer a regularly scheduled meeting even if there isn't much going on or the disruption of occassionally canceled ones?
 * noodles775 just assumes it is on, unless there's notice.
<abentley> flacoste, it's been cancelled due to lack of agenda frequently.
<abentley> noodles775, bac: I find the routine helps me remember.
<bac> abentley: but if you're around at this time, and keep your calendar free for the hour, is it a burden if we just ping you to join?
<abentley> bac, no, that's fine on my end.
<bac> abentley: i understand routine is nice.  but i figured saving the team from showing up when there isn't much to discuss outweighs it.  and others have commented they like the idea.
<bac> abentley: and you're at a disadvantage b/c you have no other team members to check to see if you're around...
<abentley> abentley, true.
<abentley> bac, true
<bac> if there's nothing else let's call it a meeting.
<bac> thanks for coming
<bac> #endmeeting
<MootBot> Meeting finished at 09:28.
<noodles775> Cheers bac
<bac> hi thumper, mwhudson, rockstar -- up for a reviewers meeting?
<mwhudson> alright
<thumper> bac: if it's quick, I have something on soonish
<bac> thumper: let's do quick, then
<bac> in the ameu meeting we had a very brief conversation
<bac> we talked about the issue michael raised on the list wrt launchpadlib
<bac> it sounds like leonard has addressed all of your concerns.
<bac> he provides helpers for creating credentials for a user and getting an object and logging in anonymously is easy
<bac> we agreed that new API functionality should be tested with new lplib tests, which are preferred over the webservice tests
<bac> of course the old tests will need to be kept up-to-date when new things are exported, unless a test is completely replaced
<bac> other than that, i am supposed to reopen the discussion about community reviewers/committers based on info i've gotten from IS
<bac> that, in a nutshell, was the meeting.
<bac> of course it took us closer to 30 minutes to get all that out
<bac> y'all have anything else?
<thumper>  what is the result of the email from is?
<bac> for many of the reasons we brought up in our internal discussion, elmo does not want to allow commit rights to a branch that automatically goes into production/edge
<thumper> but happy for reviews?
<bac> he thought it'd be ok if we create an intermediate branch that accepts contributions from some community members but must be reviewed by a canonical employee before deployment
<bac> thumper: i'll need to review his email to refresh my memory on the reviewer issue
<thumper> ok
<mwhudson> bac: yeah, i'm happy with the launchpadlib test scaffolding now
<bac> iirc he was not in favor of a single external reviewer.
<bac> mwhudson: great
<bac> i think there is great value in having community reviewers, even if they do need a second pair of eyes
<bac> anyway, let me formulate a proposal and get it out on the list
<bac> that's all i've got
<thumper> I've nothing to add
<bac> ok.  well let's call it a meeting then so you can get to your next one.
<bac> later.
<mwhudson> thanks bac
#launchpad-meeting 2010-04-08
<matsubara> #startmeeting
<MootBot> Meeting started at 11:02. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> sorry I'm late
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<sinzui> me
<matsubara> Chex, rockstar, gary_poster, danilos, allenap: hi
<Ursinha> moi
<allenap> me
<chex> me
<gary_poster> me
<matsubara> no one from soyuz?
 * rockstar  
<Ursinha> matsubara, julian is on leave
<matsubara> ok. let's move one then
<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>  * QA stats of the week
<matsubara>  * Proposed items
<matsubara>  * Ursinha to send email to TLs about QA summaries
<matsubara>  * matsubara to triage open oops-tools bugs
<matsubara>  * Ursinha to file a bug about setting the increase threshold for the product release finder monitoring script
<matsubara>  * allenap to talk to chex after the meeting about the calculate_bug_heat failing script
<matsubara>    * Suspect it was due to the roll-out; the script did actually run
<matsubara>      but took a long time to get through the backlog. Will see if it
<matsubara>      happens again. -- allenap
<matsubara>  * Ursinha to investigate about oops-prune and expire-ppa-files failing scripts
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=prune
<matsubara>  * rockstar to find someone to look at bug 536486 and update it
<ubottu> Launchpad bug 536486 in launchpad-code "Svn import of ruby taking 2.7G RSS" [High,Triaged] https://launchpad.net/bugs/536486
<matsubara>  * Ursinha to send one email to lp list about the untriaged bugs in lp-project and others
<matsubara> oops
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> * Ursinha to send email to TLs about QA summaries
<matsubara>  * matsubara to triage open oops-tools bugs
<Ursinha> matsubara, I've commented on two of my items there
<matsubara>  * Ursinha to file a bug about setting the increase threshold for the product release finder monitoring script
<matsubara>  * allenap to talk to chex after the meeting about the calculate_bug_heat failing script
<matsubara>    * Suspect it was due to the roll-out; the script did actually run
<matsubara>      but took a long time to get through the backlog. Will see if it
<matsubara>      happens again. -- allenap
<matsubara>  * Ursinha to investigate about oops-prune and expire-ppa-files failing scripts
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=prune
<matsubara>  * rockstar to find someone to look at bug 536486 and update it
<matsubara>  * Ursinha to send one email to lp list about the untriaged bugs in lp-project and others
<matsubara> sorry, forgot to reload the page
<matsubara> I did triage all open oops-tools bugs
<Ursinha> I've filed a bug, bug 558448
<ubottu> Launchpad bug 558448 in launchpad-registry "Threshold for the product release finder monitoring script needs to be increased" [Low,Triaged] https://launchpad.net/bugs/558448
<Ursinha> oops-prune haven't failed again. expire-ppa-files is failing because it was removed. Is that on purpose? spm sent one email to lp list asking that
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=prune
<matsubara> [action]  * Ursinha to send email to TLs about QA summaries
<MootBot> ACTION received:   * Ursinha to send email to TLs about QA summaries
<matsubara> [action] * Ursinha to send one email to lp list about the untriaged bugs in lp-project and others
<MootBot> ACTION received:  * Ursinha to send one email to lp list about the untriaged bugs in lp-project and others
<matsubara> Ursinha, are those two correct to be re-added to the action items?
<sinzui> Ursinha, I have looked into it. There is no clear fix yet. The two leading ways is to make the processes in nightly.sh run faster, or run them in parallel
<Ursinha> matsubara, I'm writing the untriaged bugs email right now; you can keep them if you want, I'll manage to do it
<matsubara> rockstar, how about yours? did you find someone to look at bug 536486
<ubottu> Launchpad bug 536486 in launchpad-code "Svn import of ruby taking 2.7G RSS" [High,Triaged] https://launchpad.net/bugs/536486
<matsubara> ?
<rockstar> matsubara, yeash.  The bug reflects the actions being taken (very little currently)
<rockstar> We're not focusing on ruby for bzr-git, we're focusing on the kernel import.
<matsubara> rockstar, all right. thanks for chasing that
<matsubara> ok, let's move on then
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> allenap, thank deryck for looking at https://bugs.edge.launchpad.net/malone/+bug/556515. please let him know this is one of the top oopses for this week
<ubottu> Launchpad bug 556515 in malone "Changing the status of a task causes an error 500" [Undecided,Confirmed]
<matsubara> gary_poster, I see that https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1557EA572 is still happening as of 2010-04-06
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1557EA572
<allenap> matsubara: Will do.
<matsubara> rockstar, have you seen https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1553EC1332 ? oops retrieving the feed for person branches. not sure if this is a bug for code or registry
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1553EC1332
<gary_poster> matsubara: ack.  I think I asked about that before but don't remember answer.  will investigate and reopen or open anew as appropriate
<matsubara> thanks gary_poster
<sinzui> matsubara, branches is the code team
<rockstar> matsubara, it's a code issue
<sinzui> matsubara, the registry only manages project announcements
<matsubara> [action] gary_poster to investigate OOPS-1557EA572 and re-open or file a new bug for it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1557EA572
<MootBot> ACTION received:  gary_poster to investigate OOPS-1557EA572 and re-open or file a new bug for it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1557EA572
<matsubara> [action] matsubara to file a bug for OOPS-1553EC1332
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1553EC1332
<MootBot> ACTION received:  matsubara to file a bug for OOPS-1553EC1332
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1553EC1332
<matsubara> we have 3 critical bugs, 2 fix committed and one confirmed
<matsubara> the one confirmed is for soyuz :-(
<Ursinha> :/
 * rockstar is glad it wasn't for code
<matsubara> [action] matsubara to chase critical bug 556839 with noodles or someone from soyuz
<MootBot> ACTION received:  matsubara to chase critical bug 556839 with noodles or someone from soyuz
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/556839)
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/556839)
<Ursinha> oops
<matsubara> we have a few scripts failing since last week
<matsubara> retry-depwait is failing frequently
<matsubara> Ursinha, do you know what's up with that one? ISTR you asked in the list or something about it
<Ursinha> matsubara, there's an open bug for that, let me find it
<matsubara> there's also expire-ppa-files script which seems to have been moved or removed
<Ursinha> I asked about expire-ppa-files
<matsubara> [action] matsubara chase someone from soyuz about expire-ppa-files failing script
<MootBot> ACTION received:  matsubara chase someone from soyuz about expire-ppa-files failing script
<matsubara> update-cache also failed due to a missing user
<matsubara> fixed by spm already
<matsubara> that's it. thanks everyone. let's move on
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Ursinha> matsubara, bug 553068
<ubottu> Launchpad bug 553068 in soyuz "buildd-retry-depwait.py crashing" [High,In progress] https://launchpad.net/bugs/553068
<Chex> hello everyone
<Chex> here is the LOSA report for this week:
<matsubara> thanks Ursinha
<Chex>         : 08-Apr: Librarian1 rapidly gobbling memory, restarted to free up.  Bug 556245.
<Chex>         Any more info on this issue?
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/556245)
<Chex>         : Issue with LP staging_restore: replication DB issue.
<Chex>         fixed the problem yesterday, Staging restore are working now.
<Chex>         : Buildbot issues: having problems pulling sourcecode earlier - issue still not
<Chex>         resolved.  Does anyone have more information on this issue?
<matsubara> gary_poster, ^
<Ursinha> Chex, I see that edge updates aren't working yet
<gary_poster> Chex, no more info on Librarian issue, but aware of it.
<gary_poster> pulling sourcecode: that's a code issue IMO, but I don't think we've raised it because we don't know what to do about it.  The buildbot issue I was talking to you about was that jml wanted buildbot to no longer allow a failed update to proceed.  I'm fine with this, but his change didn't work, and I don't know why.
<Chex> gary_poster: ok, thanks for librarian.  about buildbot issues, thats fine, anything we can do you help you debug why the change didnt work?
<gary_poster> matsubara, rockstar: salgado reports about OOPS-1557EA572:
<gary_poster> "gary_poster, the OOPS above is different from the one I'd seen when fixing the bug.  that's in the view that generates merge-proposal diffs.  that view should either use StreamOrRedirectLibraryFileAliasView (which knows what to do when the librarian is down) or do something similar to that"
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1557EA572
<Chex> Ursinha: edge updates.. I will have to take a look at that.
<matsubara> gary_poster, thanks!
<gary_poster> sure
<Ursinha> Chex, I see lp stable branch is currently on r10650, but edge is running other branch
<matsubara> [action] matsubara to file a bug on launchpad-code about OOPS-1557EA572 including details from salgado ("the OOPS above is different from the one I'd seen when fixing the bug.  that's in the view that generates merge-proposal diffs.  that view should either use StreamOrRedirectLibraryFileAliasView (which knows what to do when the librarian is down) or do something similar to that")
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1557EA572
<MootBot> ACTION received:  matsubara to file a bug on launchpad-code about OOPS-1557EA572 including details from salgado ("the OOPS above is different from the one I'd seen when fixing the bug.  that's in the view that generates merge-proposal diffs.  that view should either use StreamOrRedirectLibraryFileAliasView (which knows what to do when the librarian is down) or do something similar to that")
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1557EA572
<matsubara> ok, let's move on. thanks Chex and everyone
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> I'll ask stub to send the dba report if he hasn't yet
<Ursinha> he has
<matsubara> [TOPIC] * QA stats of the week
<MootBot> New Topic:  * QA stats of the week
<matsubara> great
<matsubara> Soyuz (soyuz): 28
<matsubara> launchpadlib  (launchpadlib): 25
<matsubara> Launchpad Developer Utilities (lp-dev-utils): 9
<matsubara> Launchpad Bazaar Integration (launchpad-code): 8
<matsubara> Launchpad Auto Build System (launchpad-buildd): 8
<matsubara> Launchpad Development Wiki Moin theme (launchpad-dev-moin-theme): 5
<matsubara> Launchpad Foundations (launchpad-foundations): 3
<matsubara> Launchpad Buildbot Configuration (lpbuildbot): 2
<matsubara> trac-launchpad-migrator (trac-launchpad-migrator): 2
<matsubara> launchpad-loggerhead (launchpad-loggerhead): 2
<matsubara> Launchpad News WordPress Theme (launchpad-news-wordpress-theme): 2
<matsubara> Launchpad QA Utilities (lp-qa-tools): 2
<matsubara> Launchpad Help Wiki Moin theme (launchpad-help-moin-theme): 2
<matsubara> Launchpad Bugs (malone): 2
<matsubara> Launchpad CSCVS (launchpad-cscvs): 2
<matsubara> Launchpad Registry (launchpad-registry): 1
<matsubara> Launchpad Documentation (launchpad-documentation): 1
<matsubara> Tickcount (tickcount): 1
<matsubara> I guess I should've formatted this better
<matsubara> anyway, soyuz and launchpadlib still high on the number of untriaged bugs
<Ursinha> matsubara, I guess launchpadlib is somehow related to foundations people
<matsubara> yes, it is. I'll talk to the team about it
<Ursinha> I'm about to send one email to the list to discuss that
<matsubara> [action] matsubara to talk to foundations about launchpadlib
<MootBot> ACTION received:  matsubara to talk to foundations about launchpadlib
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> there's no new proposed items
<matsubara> anything else before I close?
<Ursinha> just a reminder
<Ursinha> don't forget to check outstanding 10.03 bugs, so we can close the cycle
<Ursinha> that's all :)
<matsubara> ok. thanks Ursinha
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda  for the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 11:35.
