#launchpad-meeting 2008-05-20
<barry> #startmeeting
<barry> hello everyone and welcome to this week's asiapac reviewer's meeting
<barry> who's here today?
<spiv> Oh, hi.
<spiv> I'm here :)
<sinzui> me?
<barry> spiv: hi! :)
<spiv> jml is in Prague I guess?
<barry> thumper: ?
<barry> mwhudson: ?
<spiv> (good thing I was idling in here!)
 * thumper smacks forehead
<barry> spiv: that's okay.  i haven't eaten dinner yet :)
<thumper> completely forgot, sorry
<thumper> I'm hip deep in pqm
<thumper> (the source that is)
<barry> ouch
<barry> we can make it a quick one then
<thumper> well, if we ignore for the moment that the patch will be approx 3k lines
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<thumper> it will make it better
<barry>  * Review process
<barry>    * Help people learn how big branches can be split up (BjornT)
<barry>    * Final vote multiline import
<barry> it being a us holiday next week, i will not be here.  shall we just skip it and convene back in 2 weeks?
<thumper> barry: I'm guessing that mwhudson is afk too
<barry> thumper: gotcha
<thumper> barry: sure, I don't mind skipping
<thumper> barry: expecially as it is a week 4
<barry> thumper: yep
<barry>  * Action items
<barry>  * barry drive to decision about multiline sequences
<barry> i think we're close to a decision here, but i'l say more in a few minutes
<barry>  * barry to solicit ideas to better handle review scheduling and workload
<barry> not done
<barry>  * (continued) thumper to report on pending-reviews killer in LP
<thumper> not done either
<barry> thumper: shall we keep this on the agenda or ditch it?
<thumper> barry: ditch for now I think
<thumper> we have things coming up
<barry> thumper: sounds good
<thumper> but it doesn't really help saying skip it each week
<barry> thumper: all post 2.0 right?
<thumper> yeah
<barry> works for me
<spiv> +1
<barry>  * Queue status
 * thumper hasn't looked at the queue in ages
<barry> nothing much from me here.  i got through a bunch of branches today, and assigned the 3 i couldn't get to
<barry> doesn't look too bad right now but i wouldn't want to be sinzui on friday :)
<sinzui> And Saturday
<barry> sinzui: only because you like it :)
<sinzui> No Soccer this weekend
<barry> sinzui: promise me you will not work on the holiday! :)
<sinzui> Work on what?
<barry> it's national bbq day
 * sinzui starts the heater on the pool
 * barry is going to skip the mentoring update
<barry> sinzui: very nice!
<barry>  * Review process
<barry>    * Help people learn how big branches can be split up (BjornT)
<thumper> don't talk to me about that right now
<barry> at ameu , bjorn brought up a discussion on how to get people to learn how to split their big branches
<thumper> I have a real killer
<barry> thumper: your branch?
<thumper> yeah, me for lifeless
<mwhudson> oh man, i _always_ forget this meeting
<spiv> barry: a sharp whack across the knuckles with a big ruler every time a branch goes over the limit? ;)
<thumper> spiv: it is a pqm refactoring branch
<barry> spiv: that's one idea!
<thumper> spiv: most of it is just moving stuff to modules
<barry> i had a big branch, but mostly because i added some upstream files
<thumper> would you believe I got __init__.py down to just having __version__ in it?
<barry> but in general, all the branches i saw today were < 800 lines
<barry> so i don't know how common this is
<mwhudson> i'm not really aware of it being a problem
<sinzui> I think we need a wiki page to collect ideas, then circulate a email of the top 5-10 tips after two weeks
<spiv> So there's two possible issues I guess.
<thumper> I don't think it is a big problem right now
<barry> what i'd say is that if you notice the same offenders over and over again, we should work with those people to get them to learn how to organize their work better
<thumper> +1
<mwhudson> i think 800 lines is a low enough limit that it can be slightly exceeded without causing much pain
<barry> mwhudson: agreed
<spiv> One is that maybe people are doing to much work, rather than sending things incrementally (i.e. "send-as-you-go")
<spiv> The other is that maybe when a big branch happens (which can be hard to avoid), people don't know how to split them up.
<barry> spiv: it was brought up that looms can be a useful tool for organizing a complex branch into reviewable chunks
<spiv> I'm not sure which of these two Bjorn is referring to?
<mwhudson> it requires a certain discipline to go 'oh crap to do X i need Y and then i need Z' and then put each thing in it's own branch
<spiv> (maybe both?)
<barry> spiv: i get the sense that it's a lot of the latter.  how to help people learn how to split it up
<spiv> Ok.
<barry> but otoh, most of the branches i've been reviewing have been fine
<sinzui> spiv: I believe I'm now seeing a pattern of multiple branches being submitted on the same day. bug branches are being split instead of being driven to the right solution through review.
<spiv> This is something that the broader bzr user community would benefit from education about.
<mwhudson> sinzui: i'm not sure i understand
<sinzui> s/ï»¿bug branches/but branches/
<barry> i'm going to ask BjornT to start a discussion on the ml about this
<spiv> There's a fairly straightforward process you can go through with looms + bzr shelve.
<mwhudson> sinzui: at least in an ideal world, the correct solution should be determined around the time of the pre-imp call
<mwhudson> not the review
<spiv> Which has occasionally been described on #bzr and maybe on the mailinig list.
<barry> spiv: is there anything written up about this way of working?  it's definitely something i do
<spiv> (the bazaar@ mailing list)
<spiv> But I don't think it's been written up properly.
<barry> mwhudson: yes, we want to push the organization earlier in the process
<spiv> So perhaps the thing to do is write a good, clear tutorial on it, and put it in the loom plugin docs?
<sinzui> mwhudson: I think 1800 line branches are being written, then split. The view is in a precarious position because there may be drastic changes to the model and utils below it. not to mention that mpt my have grievous things to say about the UI.
<spiv> And use the launchpad team as guinea pigs for that doc :)
<mwhudson> sinzui: ah, i see
<barry> spiv: +1.  if you want to drive it/start it, i will certainly chip in
<spiv> I don't have time for that at the moment.
<mwhudson> well, this is all about the 'ready to code' mantra i guess
<spiv> I'd be happy to proof read.
<barry> [ACTION] barry to write something up about working effectively with looms+shelve
<spiv> mwhudson: agreed
<spiv> barry: thanks!
<barry> i gotta run, so i'm going to (try to) make this last item short:
<barry>    * Final vote multiline import
<barry> did you all see mars's suggestion?
<mwhudson> remind me?
<barry> instead of: from canonical.launchpad.interfaces import ([800 lines later)
<barry> do: from canonical.launchpad.interfaces.bugs import (many fewer things)
<barry> and eradicate (over time) all import-*'s in __init__.pys
<barry> and do not do one-line-per-import
<barry> thoughts?
<spiv> I'm +0 on that, I think.
<mwhudson> i don't think this will please the people who think one-line-per-import will take too much space, will it?
<mwhudson> but yeah, import-* sucks, even when used carefully
<spiv> There's a risk that module renaming/interface moving will then cause merge-time conflicts.
<barry> yes, import-* sucks for many reasons
<barry> spiv: we won't actually move anything, we'll just do a more-specific import
<spiv> Evil though import * is, it does make the actual layout of canonical.launchpad.interfaces.* etc a blackbox to other packages.
<thumper> barry: I think spiv means if we do move something
<barry> which should reduce big parenthesed import statements, thus reducing conflicts
<spiv> barry: right, but when something moves
<barry> yeah, i see what you mean
<rockstar> import-* destroys the convenience of namespaces.
<mwhudson> this seems to be a bit
<spiv> I'm not sure it's a significant problem.
<rockstar> If we always import *, we get php at some point
<spiv> But it does make me hesitate a little.
<barry> me neither.  i don't know how often interfaces move around
<mwhudson> 'import statements attract conflicts' -> 'but one-line imports are too verbose' -> 'lets do something else that doesn't really solve either problem'
<mwhudson> ish
<barry> unless it does :)
<spiv> Yeah, my gut feeling is with mwhudson, that this is a largely orthogonal issue.
<mwhudson> but then i don't really have a problem with conflicts in import statements _or_ large amounts of imports at the top of files
<barry> i think it will reduce conflicts on import lines, which iiuc is the primary motivation for moving to one-line-per-import
<mwhudson> so maybe i should just shut up and hope people stop bothering me by talking about it :)
<barry> :-D
<barry> ok, well i didn't hear howls of objections, so i'l take that as "let's try it and see"
<barry> i just want to get this f'n item off my list ;)
<barry> that's all i have today.  anything else from y'all?
<thumper> nop3
<thumper> e
<spiv> barry: my vote on any specific proposal is +0, but my meta-vote is +1 for barry just declaring how it will be. :)
<thumper> ditto
<mwhudson> barry for president!
 * mwhudson waits for the s/!=/<>/ branch of doom
<spiv> mwhudson: well, I might be -0 on *that* specific one ;)
 * barry is just waiting until the psf f's up the trademark and then it's off to the fork he goes!
<barry> anyway. thanks everybody.  see you in 2 weeks!
<barry> #endmeeting
<mwhudson> bye barry
<mwhudson> hm, python.org seems down
<spiv> mwhudson: there's always python.com
<mwhudson> oh no
<mwhudson> probably my internet being crap again
<mrevell> Hello! Is anyone here for the Launchpad documentation meeting?
#launchpad-meeting 2008-05-21
<barry> #startmeeting
<barry> heh
<barry> hello everyone and welcome to this week's ameu reviewer's meeting
<barry> i know a lot of people are away, but who's here today?
<sinzu1> me
<sinzui> me
<allenap> me
<intellectronica> me
<schwuk> me
<bac> me
<salgado> me
<EdwinGrubbs> me
<gmb> me
<intellectronica> sorry, everyone, for allenap and mine no-show today. we've been working very hard on that hacking thing
<intellectronica> http://farm3.static.flickr.com/2395/2511062130_f148267b7f.jpg
<barry> intellectronica: why is allenap smiling?  that doesn't look like work! :)
<intellectronica> barry: something to do with JSON marshaling, iirc
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>    * Help people learn how big branches can be split up (BjornT)
<barry>    * Adopt mars suggestion for more-specific imports; don't do multiline imports; communicate decision.
<barry>  * Next meeting
<barry> everyone okay with week += 1
<barry> anybody know of sprints or holidays, or know you won't be here?
<intellectronica> i won't be here, i'll be on vacation
<salgado> I won't be here. vacation as well
<danilos> me
<barry> cool
<barry>  * Action items
<danilos> as in, me here today, though late
<barry>  * barry drive to decision about multiline sequences
<barry> so we've made a decision: we're going to adopt mars's suggestion and not multiline imports.  hopefully that will cut down on conflicts, but even if it doesn't, it'll be a win
<barry> as we're all agreed __init__.py's import-*'s suck :)
<barry> [ACTION] barry to update style guides and email ml
<barry>  * barry to solicit ideas to better handle review scheduling and workload
<barry> not done
<barry>  * flacoste to add `safe_hasattr()` to `lazr.utils`
<flacoste> i suck
<flacoste> carry on
<barry> ;)
<barry>  * bjorn to add recommendation to test style guide saying don't use asserts in doctests
<sinzui> That will wait until a week 0
<barry> i don't think BjornT is here
<barry> so we'll just carry on
<gmb> barry: He's in a UDS session, I think.
<barry>  * Queue status
<barry> gmb: np
<barry> salgado: you're switching ocr today, is that right?
<salgado> barry, that's right
<salgado> will update the wiki
<barry> salgado: thanks for helping out w/coverage!
<barry> looks like we have a few pink branches
<barry> EdwinGrubbs: what's happening w/ the cprov and julian branches?
<EdwinGrubbs> barry: I think they are done except for mentoring possibly.
<salgado> they have been mentored
<salgado> I think
<barry> cool, so just waiting to land?
<salgado> I think it's just the status that hasn't been updated
<barry> np
<barry> schwuk: any word on the adeuring #1 branch?
<schwuk> barry: in progress
<cprov> salgado: you did, I will reply it this evening. Sorry for the delay.
 * schwuk forgot to check pending reviews and missed it
<barry> schwuk: cool, thanks.  iirc, there was reluctance to start on the 2 and 3 branches until the first one got reviewed
<sinzui> I think splitting a large branch and submitting all the parts at once is unfair.
<barry> schwuk: you should check out bac's script :)
<bac> barry,sinzui : we talked to abel about it yesterday.  he said they are pretty dependent.  2 & 3 should be withdrawn
<schwuk> barry: I had it running, but I broked it :(
<barry> sinzui: if they are highly intertwined
<bac> but due to abel being at UDS i didn't get to talk with him directly
<barry> bac: ok, thanks for the feedback.  i'll remove those branches from PR
<barry> bac: and email abel so he knows to resubmit them when he gets #1 through
<barry> anything else on the queue?
<bac> barry: also make sure he knows about the depends option in review-submit
<barry> bac: good point!
<barry> moving on...
<barry>  * Mentoring update
<barry> any feedback, issues?
<barry>  * Review process
<barry>    * Help people learn how big branches can be split up (BjornT)
<barry> well, we didn't really reach any conclusions on this one, but for the folks working on abel's branch, can you think about this some and make any (general) suggestions to the ml?
<barry>    * Adopt mars suggestion for more-specific imports; don't do multiline imports; communicate decision.
<barry> already mentioned.
<barry> anyway, that's all i have on the agenda.  does anybody have any other topics?
<sinzui> I think splitting a large branch and submitting all the parts at once is unfair.
<intellectronica> sinzui: huh?
<intellectronica> you should submit as soon as the code is available
<sinzui> I think that stands as a topic. The last branch is in a precarious position.
<sinzui> A mistake in the bottom of the design may topple the top branch
<bac> and even mundane changes can bubble through all parts causing the reviewers to do extra work
<sinzui> intellectronica: I agree that once a chunk of code is ready for review, it should be.
<intellectronica> true, but i think if you already reached the point where you have all code ready at once there isn't much that can be done about this
<intellectronica> we should pay attention to 'Depends:' in the submission, and try to spot problematic cases
<intellectronica> also, it should be the responsibility of the developer to sort out effective reviews
<barry> well, the pre-impl should have helped with any design issues, no?
<sinzui> Yep
<sinzui> A pre-imp should estimate the number of lines required and plan the branches
<schwuk> sinzui: +1
<barry> intellectronica: true, but devs should be conscious of not wasting reviewers time, so they should be highly confident their branches are solid
<barry> and if not, get more up-front help in planning the branches
<schwuk> If a branch is a few lines over the limit, fair enough. If it's 100+ lines over then the work hasn't been chunked properly (see pre-imp calls)
<intellectronica> schwuk: b.t.w did you have a pre-imp with abel? you are the developer most likely to be able to have an effective one with him
<schwuk> intellectronica: no, and he's not listed a pre-imp call on the review request.
<barry> i will mention this to him, when i email him about his branches
<schwuk> barry: I've queried it in my review as well.
<barry> schwuk: thanks
<barry> anything else?
<barry> #endmeeting
<barry> thanks everyone!
<schwuk> thanks barry
#launchpad-meeting 2008-05-22
* You're now known as ubuntulog
<Rinchen> I see mootbot has abandoned us again
<Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<Rinchen> Roll Call
<thumper> me
<schwuk> me
<mrevell> me
<Rinchen> me
<mars> me
<barry> me
<flacoste> me
<adeuring> me
<herb> me
<abentley> me
<al-maisan> me
<Rinchen> apologies received from several at UDS and Brazil (holiday)
<statik> me
<mthaddon> me
<sinzui> me
<bac> me
<EdwinGrubbs> me
<Rinchen> BjornT, danilo_, jml, leonardr, ping if you're around
<Rinchen> ok, small crowd today
<thumper> gee, that isn't many
<danilo_> me
<stub> me
<Rinchen> Yeah, I suggested skipping today but kiko wanted us to run with it...so we shall
<danilos> replacing for jtv today, though not feeling too well myself
<Rinchen> Agenda
<Rinchen>  * Next meeting
<salgado> me
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (Matsubara)
<Rinchen>  * Critical Bugs (Rinchen)
<salgado> sorry
<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> thanks danilos
<Rinchen> Next meeting
<Rinchen> next week, same time, same channel
<Rinchen> any known absences?
<Rinchen> Actions from last meeting
<Rinchen> none that remain open
<Rinchen> Oops report (Matsubara) - proxied by mrevell
<mrevell> Hi
<mrevell> Today's oops report is about bugs 232494, 232528, 234072, 47864, 234078, 234083
<mrevell> #232494 is one for salgado, his recent fix in the +editsshkey form introduced the error. :-)
<ubottu> Launchpad bug 232494 in launchpad "editsshkey form breaks if the key added contain a comment with non-ascii character" [Undecided,New] https://launchpad.net/bugs/232494
<ubottu> Launchpad bug 232528 in rosetta "OOPS in +imports page entering a invalid query string" [Undecided,New] https://launchpad.net/bugs/232528
<ubottu> Launchpad bug 234072 in launchpad-bazaar "DB constraint triggered adding an external branch with a launchpad url" [Undecided,New] https://launchpad.net/bugs/234072
<ubottu> mrevell: Bug 47864 on http://launchpad.net/bugs/47864 is private
<mrevell> jtv, can you take #232528?
<thumper> I thought bug 234072 was fixed a *long* time ago
<mrevell> thumper: I'll pass that back to matsubara
<mrevell> thumper, can you take care of #234072, #234078, #234083?
<Rinchen> danilos, for jtv  on 232528
<thumper> mrevell: but apparently it isn't
<danilos> mrevell: jtv's not around
<mrevell> okay, thanks danilos. I'll email him.
<mrevell> Looking for volunteers for 47864.
<Rinchen> danilos, you're supposed to say "yeah sure he'll take it"  :-)
<mrevell> :)
<danilos> mrevell: this was probably caused by jtv himself
<mrevell> Any volunteers for 47864?
<danilos> mrevell: I can't imagine many people hacking those URLs themselves
<Rinchen> mrevell, maybe email the list on the distro series one
<mrevell> Rinchen: Okay, thanks, will do.
<mrevell> Thanks, then, everyone. That's all.
<danilos> oh, not really, it seems to include some JS instead
<Rinchen> thanks mrevell
<Rinchen> Critical Bugs (Rinchen)
<Rinchen> No critical issues remain open. Yay! :-) Thank you!
<Rinchen> We have an issue with staging updates.  A DB patch is failing to apply.  A fix is (or will be very shortly) on PQM and bumped to the top.
<Rinchen> Bug tags
<Rinchen> we have one by Diogo
<Rinchen> but he's not here and we're short on attendees so I'm going to skip that
<Rinchen> we'll come back to it next week
<Rinchen> Operations report (mthaddon/herb)
<herb> 2008-05-16: Demo was updated
<herb> 2008-05-19: lpnet4 had died - restarted
<herb> 2008-05-20: Cherry pick to lpnet* to fix bug #228132
<herb> Seems like we've been having more problems with codebrowse/loggerhead recently. It has a tendency to grow to ~1.5GB RSS. This causes swapping and the expected performance issues that go along with it. I think mwhudson is aware of the proble
<herb> m.
<herb> We'd like to update demo to either RF-tip or at least r6331 to pick up the configs that recently landed as opposed to using the cowboyed configs we have currently.
<ubottu> herb: Bug 228132 on http://launchpad.net/bugs/228132 is private
<rockstar> me
<leonardr> me
<Rinchen> herb, mthaddon +1 on demo updates
<herb> That's it for Tom and me this week unless there are any questions.
<herb> Rinchen: thanks
<Rinchen> herb, mthaddon - we should think about putting it on the lastest tip certainly after next week's roll-out....
<Rinchen> thanks herb
<Rinchen> DBA report (stub)
<stub> DB patches for this cycle have all been reviewed. One broke on production data but should be fixed shortly (fix is with PQM and next in the queue).
<stub> There are still two more patches that might land this cycle - a Rosetta patch that Mark has approved and the first stage of the Auth/Person split that needs to go through code review.
<stub> And that was all I could think of and type before being invoked by Joey
<Rinchen> Provocative! :-)
<Rinchen> Any questions for Stu?
<Rinchen> I'll withhold channeling kiko this week.
<Rinchen> Thanks stub
<Rinchen> Sysadmin requests (Rinchen)
<Rinchen> Is anyone blocked on an RT or have any that are becoming urgent?
<Rinchen> al-maisan, do you know if there is a delay yet with Julian's items?
<al-maisan>  Rinchen: I am not aware of any blocking issues.
<Rinchen> ok thanks al-maisan
<Rinchen> hey, salgado is here!
<Rinchen> New packages required (salgado)
<salgado> anything you want me to add to launchpad-dependencies this week?
<salgado> guess not
<Rinchen> jml put in a request for chec beer....
<Rinchen> but we can handle that off line
<Rinchen> thanks salgado
<Rinchen> A top user-affecting issue (mrevell)
<mrevell> hi
<mrevell> This week I'd like to re-raise an issue we've spoken about before: how we handle user support requests. I handle the feedback list with Kiko's help and amongst we have the -users list and #launchpad more or less covered. However, it can take quite a while for requests in Answers to be dealt with.
<mrevell> I've spoken to mthaddon about this and there's a problem of sheer volume of work and uncertainty over areas of responsibility.
<mrevell> mthaddon - are most of the requests in Answers something that only people with Admin access can fix?
<mthaddon> mrevell, I'm not sure - I don't think so... but couldn't give a good answer to that without looking into it further
<mrevell> mthaddon: Okay, thanks. Would it help if someone else/other people filtered out the non-OSA requests?
<Rinchen> mrevell, this is a good time to let folks know about the LP QA job post.  One of the duties of my expanded QA group will be additional support handling.
<mthaddon> mrevell, it would help if it was well known what we as LOSAs are supposed to be responsible for, and what others are responsible for
<mrevell> Rinchen, mthaddon: So, perhaps in the time between now and hiring the new QA role we could look at that.
<mrevell> Perhaps this one for the list, though.
<mrevell> thanks Rinchen
<Rinchen> Doc Team report (mrevell)
<mrevell> Held a doc team meeting on Tuesday. This was advertised with individual emails to each doc team member. Unfortunately, no one attended. I may have to reconsider the doc team, as it has been difficult to get anything going.
 * Rinchen has to rescue the neighbors dog caught in the hail
<danilos> in general, Translations team is trying to handle all 'rosetta' questions
<mrevell> Bugs user guide section sent to team list this week. Please review, if you haven't already.
<mrevell> Two episodes of the podcast published this week! Honest feedback sought! And also participants and feature ideas.
<mrevell> Anyone have any comments on the podcast they want to share?
<barry> mrevell: great theme song
<mrevell> barry: Yeah, awesome work, thanks :)
<barry> :)
<mthaddon> mrevell, please stop statik talking from waffling...
<statik> :)
<mrevell> mthaddon: Heh, I edit out the bits where we waffle, this is the good stuff :)
<statik> he left out the part where i confessed to killing a man
<mrevell> statik: hahahaha :-D I forgot that
<mthaddon> was supposed to be a ref to his waffles comment...
<mrevell> mthaddon: Oh yeah :)
<mrevell> Okay, well, if Rinchen's off on a canine rescue mission I guess that's the end of the meeting :)
<sinzui> mmm. waffles
<thumper> I was waiting for the comic ending to the second podcast
<mrevell> thumper: I lost it :(
<mrevell> Okay, I unilaterally declare this meeting over.
<mrevell> :)
<Rinchen> sorry back
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting.
<Rinchen> poor dog was trapped and couldn't get in her dog house
<Rinchen> so she's with me here inside
<mrevell> Rinchen: Good work.
<mrevell> :)
<mrevell> See you all in the morning.
#launchpad-meeting 2010-05-26
<intellectronica> no meeting?
<henninge> bac: oops, I guess I missed the meeting ... :(
<danilos> henninge, I guess everybody (including bac) did :)
<bac> danilos, henninge: sorry i had to cancel the meeting and sent out a late email.  i meant to get someone to show up here and tell people...but forgot.
<henninge> bac: no problem at all. ;)
<danilos> bac, no worries, I am not strictly missing it with all the stuff that I've got to finish up :)
#launchpad-meeting 2010-05-27
<matsubara> moo
<sinzui> cluck
<gary_poster> hee-haw
<danilos> meow
<Ursinha> hello
<Ursinha> #startmeeting
<Ursinha> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<MootBot> Meeting started at 11:01. The chair is Ursinha.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Ursinha> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<Ursinha> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<sinzui> me
<Ursinha> meeee
<gary_poster> smee
<matsubara> me
<Ursinha> rockstar, Chex, hello :)
<Ursinha> I see no soyuz people :(
<Ursinha> I know we'll have no bugs people here, so ok
<Ursinha> well adeuring is here, but not sure if it's for our meeting :)
<Ursinha> I'll move on and expect people to show up
<Ursinha> [TOPIC] Agenda
<Ursinha>  * Actions from last meeting
<Ursinha>  * Oops report & Critical Bugs & Broken scripts
<Ursinha>  * Operations report (mthaddon/Chex/spm/mbarnett)
<Ursinha>  * DBA report (stub)
<MootBot> New Topic:  Agenda
<Ursinha>  * QA stats of the week
<Ursinha>  * Proposed items
<adeuring> Ursinha: yes, that's why I'm here, but I have another (mumble) meeting right now.
<Ursinha> [TOPIC] * Actions from last meeting
<Ursinha>  * DONE: matsubara to chase someone from Bugs about https://bugs.edge.launchpad.net/malone/+bug/583385
<MootBot> New Topic:  * Actions from last meeting
<Ursinha> cool, all done
<Ursinha> adeuring, thanks :)
<ubot5> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/583385)
<Ursinha> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<Ursinha> main offenders are bug 504124 (spam processing bug?) and bug 580181
<ubot5> Launchpad bug 504124 in Launchpad Foundations "process-mail.py "need more than 1 value to unpack" (affected: 2, heat: 22)" [High,Triaged] https://launchpad.net/bugs/504124
<ubot5> Launchpad bug 580181 in Soyuz "DistributionSourcePackageRelease page still oopsing with NotOneError/LocationError (affected: 1, heat: 6)" [High,Triaged] https://launchpad.net/bugs/580181
<Ursinha> I see the latter should be worked by noodles as soon as he got rid of more urgent problems
 * rockstar is here...  had computer problems
 * Ursinha hugs rockstar 
<Chex> Ursinha: All us LOSAs are unavailable this week as we are sprinting in Montreal.
<Ursinha> Chex, oh, that's bad, LOSAs' report is so useful
 * Ursinha thinks
<sinzui> the process-mail.py bug is a spam attack. Do we want to suppress oopses when the header is malformed?
<Ursinha> this meeting is crippled :/
<Ursinha> sinzui, good question
<Ursinha> gary_poster, we're having annoying high oops counts of 504124, maybe we should do something about it now the counting seems to be raising?
<Ursinha> gary_poster, even what sinzui suggested
<matsubara> sinzui, I think we should not log an oops in that case as you suggested in the bug report
<sinzui> Ursinha, gary_poster. The problem is not the app, but the data so we should gracefully recover I think
<matsubara> with a try:except when the code is processing the To: header
<Ursinha> that's my opinion as well
<gary_poster> Ursinha: yeah, I had that one open already.  If it is really bothering us then let's do it.  Agree with sinzui's approach
<Ursinha> cool
<Ursinha> gary_poster, should I update the bug report with that?
<sinzui> well, that is now a trivial fix I think
<gary_poster> Ursinha: I'll handle it, thank you :-)
<Ursinha> thanks gary_poster :)
<Ursinha> nice
<Ursinha> thanks all :)
<Ursinha> I'd need a soyuz people here now
<Ursinha> I'll go with the code one then
<Ursinha> rockstar, so, not sure if code team knows about it: OOPS-1607EA658
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1607EA658
<sinzui> I think the soyuz bug has a deeper root cause...
<sinzui> I looked at it last month and could not see what was happening. I think it goes back to changes made in Jan/Feb
<Ursinha> sinzui, might have, this was "fixed" previously and now shows two different oopses
<rockstar> Ursinha, so, I didn't know about it, but this area still hasn't been tested much...  :/
<rockstar> Ursinha, it won't be released.
<Ursinha> rockstar, oh, right
<Ursinha> rockstar, was that QAed on edge? I'm pointing the oops as it might be a consequence of QAing the feature
<rockstar> Ursinha, well, so no, we can't QA on edge much because we're blocked on two RTs...
<Ursinha> rockstar, I see :/ do you know if the blockage is something that might last for long?
<rockstar> Ursinha, well, the RT was filed as high priority more than a week ago, so your guess is as good as mine.
<Ursinha> rockstar, maybe we should poke some people? :)
 * Ursinha cries for a losa
<gary_poster> rockstar, Ursinha, is this ...
<rockstar> gary_poster!
<gary_poster> 39402?
<rockstar> Ursinha, gary_poster is the one who's been chasing for us.
<gary_poster> RT 39402?
<Ursinha> ah, I see
<rockstar> gary_poster, yes, that's it.
<gary_poster> Ursinha, rockstar, mthaddon has said that he will look into it today
<rockstar> gary_poster, ta
<gary_poster> or to not misrepresent: "member:gary: I'll try and take a look at the latter one (the first one is marked resolved) sometime today" :-)
<Ursinha> cool!
<Ursinha> thanks gary_poster and rockstar :)
<gary_poster> np
<Ursinha> rockstar, I'll keep my eyes on that oopses and let you know if something shows up
<Ursinha> thanks
<danilos> rockstar, my suggestion is to also talk to bigjools and lamont to make sure your request is similar to what is being done for "unsupported" packages already
<danilos> rockstar, about that RT at least
<Ursinha> [action] talk to bigjools about the 300 timeouts in the DistroSeries:+index pages everyday, is that expected/known? e.g.: OOPS-1607C1282
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1607C1282
<MootBot> ACTION received:  talk to bigjools about the 300 timeouts in the DistroSeries:+index pages everyday, is that expected/known? e.g.: OOPS-1607C1282
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1607C1282
<matsubara> Ursinha, isn't that the one bigjools replied to recently?
<matsubara> the one that is making an xmlrpc request to another server but is being blocked by a firewall
<Ursinha> matsubara, not sure if that's the same, I guess that one was about builders
<sinzui> Ursinha, That is my oops
<matsubara> ok, just wondering
<Ursinha> matsubara, thanks for that :)
<Ursinha> sinzui, the DistroSeries:+index?
<danilos> Ursinha, yeah, that sounds like registry
<Ursinha> if so, even better, you're here :)
<sinzui> the distroseries-portlet-packaging  is the root cause. I have a branch that add3 3 hours caching to it
<danilos> and fwiw, storm taking too long to serialize stuff
<Ursinha> [action] forget last action
<MootBot> ACTION received:  forget last action
<sinzui> Edwin's definitve SQL fix will not land until next release
<gary_poster> Ursinha, so you know, thumper alerted me last night that this soft timeout is causing timeouts (hard, I assume) on the branch merge proposal page: https://lp-oops.canonical.com/oops.py/?oopsid=1607EA56 .  Therefore I need to make a bug and look into it.
<gary_poster> (Which sucks because pretty much none of know librarian code, but oh well :-) )
<Ursinha> gary_poster, thanks for that
<Ursinha> sinzui, do you have the bug number?
<sinzui> My oops is caused by a monster query. bug 535430 is the root cause
<ubot5> Launchpad bug 535430 in Launchpad Registry "+needs-packaging link times out regularly (affected: 1, heat: 6)" [High,In progress] https://launchpad.net/bugs/535430
<Ursinha> sinzui, right
<sinzui> ^ this is really a model problem that manifests itself on three pages
<Ursinha> sinzui, which ones?
<sinzui> distroseries +index, +needs-packaging +packaging-links  (distroseries-portlet-packaging) plus two full pages
<Ursinha> thank you
 * Ursinha takes notes
<Ursinha> thanks everyone
<sinzui> ^ +packaging, not +packaging-links
 * Ursinha fixes her notes
<sinzui> https://edge.launchpad.net/ubuntu/maverick shows that the issue centers on the Upstream packaging data
<Ursinha> sinzui, so your fix will "fix" only part of the problem
<sinzui> yes. timeouts will be reduced by 50% to 80%
<sinzui> That is still disappointing
<Ursinha> that's something
<Ursinha> I guess the model problem won't be fixed (if fixed) anytime soon..
<sinzui> The fix will be too complicated for a CP
<Ursinha> sinzui, do you think that will be fixed soon?
<sinzui> It will be fixed in week 1 on staging
<Ursinha> oh, cool
<Ursinha> better than I imagined
<Ursinha> thanks sinzui
<Ursinha> I might move on, otherwise the meeting will last forever :)
<Ursinha> we have no critical bugs! \o/
<gary_poster> \o/
<Ursinha> rockstar, upgrade_branches is still failing
<Ursinha> gary_poster, :)
<rockstar> Ursinha, yeah, I'll look into it.  I have some other P1 bugs that need to be fixed first.
<Ursinha> rockstar, sure. Thanks for that. Do you know if there are any bugs opened for that? I can do that!
<rockstar> Ursinha, can you please open one?
<Ursinha> rockstar, sure :)
<Ursinha> rockstar, I'll do that and let you know. Thanks
<rockstar> Ursinha, thanks.
<Ursinha> [action] Ursinha to open a bug for the failing upgrade_branches script
<MootBot> ACTION received:  Ursinha to open a bug for the failing upgrade_branches script
<Ursinha> cool, moving on
<Ursinha> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Ursinha> losas are sprinting, so no donut for us
<Ursinha> :/
<Ursinha> Chex, may I ask you to send any important news to the list, when you have time? please? :)
 * Ursinha values that report
<Ursinha> it's more a wish than anything else, as you're sprinting
<Ursinha> :)
<Ursinha> moving on!
<Ursinha> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<Ursinha> Email asking for the report sent!
<Ursinha> [TOPIC] * QA stats of the week
<MootBot> New Topic:  * QA stats of the week
<Ursinha> untested stuff goes this way:
<Ursinha> Code: 7
<Ursinha> Foundations: 3
<Ursinha> Registry: 4
<Ursinha> Bugs: 3
<Ursinha> Translations: 7
<Ursinha> Soyuz: 3
<Ursinha> Strategy: 0
<Ursinha> I see we're kind of stable re. the number of untested items every week, which is good :)
<Ursinha> right
<Ursinha> about the untriaged bugs
<Ursinha> I've sent one email to lp list asking your opinions about all projects we should take care of
<Ursinha> I don't think pasting the numbers here will be useful now, I'd like you to reply that thread so we know what to do about those
<Ursinha> pretty please?
<danilos> stats for untested stuff seem incorrect for translations :)
<Ursinha> danilos, it was like that 30 mins ago
<danilos> Ursinha, I doubt it, maybe something like 1h or more ago :)
<gary_poster> heh
 * gary_poster is huungry :-D
<Ursinha> danilos, how come? give me a paper bag, please
<Ursinha> ok ok
<Ursinha> danilos, you're right, I see only three now
<danilos> Ursinha, oh, the graph is probably slow to update, don't worry about it
<Ursinha> danilos, thanks :)
<Ursinha> so, please, answer the thread!
<Ursinha> :_)
<Ursinha> [TOPIC] * Proposed items
<Ursinha> None from me.
<MootBot> New Topic:  * Proposed items
<Ursinha> anyone wants to say something?
<Ursinha> okay :)
<Ursinha> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<gary_poster> I'm preparing an email to Ursinha and matsubara about orphan branches
<Ursinha> #endmeeting
<MootBot> Meeting finished at 11:34.
<gary_poster> bye
<gary_poster> thank you
<Ursinha> gary_poster, branches or commits?
<Ursinha> oh, nevermind, I can read the thread later :P
<gary-lunch> Ursinha: commits, from perspective of qa tagging :-)
<Ursinha> gary-lunch, :)
<Ursinha> thanks everyone, and bye :)
<danilos> cheers
<matsubara> thanks Ursinha
#launchpad-meeting 2011-05-25
<BabyGeek> hi
