#launchpad-meeting 2008-05-13
<barry> hi everyone, sorry i'm late
<barry> #startmeeting
<barry> mootbooootttt
<barry> who's here today?
<spiv> I am.
<barry> jml, mwhudson, thumper ping?
<thumper> pong
<jml> hi
<thumper> sorry, I had to set up my little pony on Maia's laptop
<barry> hi guys.  we can probably make this quick.  the wiki page is a bit out of date, but i'll update it after this meeting
<barry> thumper: :)
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry> next week same time?
<mwhudson> oh hi
<mwhudson> yes, next week is fine
<thumper> sure
<barry> cool.  i know the week after that i won't be here because it's a us holiday
<jml> np
<thumper> barry: that'll be a week 4 anyway
<barry>  * Action items
<thumper> and we'll probably all be panicing
<barry> thumper: yeah
<barry> and cherrypicking :)
<barry>  * (continued) thumper to report on pending-reviews killer in LP
<thumper> :)
<thumper> keep it coming
<thumper> I have cunning plans
<thumper> but no action
<jml> post 2.0
<barry> cool.  can't wait to see it :)
<barry>  * barry drive to decision about multiline sequences
<barry> still seems like we have some discussion going on about multiline imports
<barry> i think i know where jml, abentley and lifeless stand on the issue
 * thumper is +1 on no conflicts rather than "gee it is easy to resolve with lint"
<spiv> Make the test suite run in under a minute, then you won't care about conflicts so much ;)
<barry> spiv: right!
<thumper> spiv: that will never happen
<barry> spiv: you don't even want to know about the new layer i'm adding
<mwhudson> i'm not really sure of where the opposition to spreading the imports out is from
<thumper> spiv: and I'll bet a cream pie that we can't keep the same coverage and have it run in under a minute
<spiv> But in the meantime, we have a merge tool that is line-based.
<mwhudson> i wonder if we can make lifeless's next special circumstances thingy "take to the test suite with an axe"
<barry> it's mostly that people don't want 10 pages of imports at the start of the files
<thumper> mwhudson: :)
<spiv> thumper: unfortunately, it'll take me considerably more than a cream pie worth of effort to prove you wrong :)
<spiv> thumper: so I won't be taking that bet :)
<thumper> barry: if they used either Pg-Down or TAGS then it isn't a problem
<thumper> barry: how about smaller files?
<spiv> I remember database/person.py was an example of a file with many imports
<thumper> so less imports
<spiv> thumper just pre-empted me :)
<thumper> don't have 4000 lines is a browser file
<barry> +1 on smaller files
<barry> thumper: didn't we have some talk at last all-hands about reorg'ing the tree?
<thumper> yeah, we did
<thumper> but it hasn't happened
<thumper> for some reason everyone seems too busy
<barry> thumper: weird, that
<thumper> yeah, who woulda thunk it
<barry> thumper: it's one of those things that would really help internally but doesn't "add value"
<thumper> JFDI
<thumper> then ask for forgiveness
<barry> thumper: rs=thumper? :)
<thumper> barry: sure
<thumper> hey, we have a VCS that can handle moving files around
<thumper> renaming even
<mwhudson> i think i care more about the discussion not dragging on than what the resolution is
<thumper> it shouldn't be (too big) a problem
<barry> y'know we're having a foundation's sprint in july.  maybe i'll corner flacoste and the gang and we'll do it over some beers
<thumper> barry: sounds like a good plan
<barry> it's the kind of thing you want to do in a room together
<barry> ...and be drunk
<jml> while you are there
<thumper> barry: it'll look so much simpler that way :_)
<jml> gosh I'd love to have an internal xmlrpc server that I could use in the test suite
<barry> thumper: the real challenge will be if it still seems like a good idea after the hangover wears off
<barry> jml: very soon, you will
<thumper> barry: commit before the hangover hits
<jml> [rs=jaegermeister]
<thumper> \o/
<barry> :)
<thumper> jml: the alcohol made me do it!
<jml> barry: how soon is very soon?
<barry> jml: if i get r=flacoste, maybe tomorrow
<jml> so happy!
<thumper> authserver, die, die, die
<thumper> stabbie stab
<barry> yeah, you may not be when you see how long it takes for that layer to start up :/
<barry> otoh, it will be just a drop compared to the current test suite
<thumper> barry: probably not much worse than what we have right now
<jml> as long as it's a more reliable startup & shutdown than the authserver
 * barry plans to move all the mailman integration tests into that layer too
<thumper> barry: that'll slow us down more, yes
<thumper> ?
<barry> yes
<jml> barry: we are getting off topic, but I'd like to know why it's a layer.
<thumper> barry: as they are not currently run on commit
<barry> jml: good point, let's chat about it after we slog through the rest of this
<jml> barry: sounds good.
<barry>  * Queue status
<barry> not much to comment on, from me.  things didn't look to bad after my ocr.  just two branches i couldn't get to
<barry> three in pqm
<barry> and the only pink branch is... guess!
<jml> something storm-related?
<barry> stub/launchpad/testsuite2
<barry> our ol' friend
<jml> ah.
<barry> any other thoughts on the queue?
<jml> nope
<barry> k
<barry>  * Mentoring update
<barry> i'm sure nothing there, right?
<thumper> right
<mwhudson> indeed
<barry>  * Review process
<barry> i got nothin'
<jml> same.
<mwhudson> was there any resolution on the "aargh, too much reviewing to do" topic?
<barry> mwhudson: not that i know of
<mwhudson> ok
<barry> well, that's it from me
<jml> it's a self-regulating problem though
<barry> do you want to talk about the layer thing or should we all just go to bed? :)
<thumper> I'd like to go to bed :)
<barry> :)
<jml> barry: would you be available to talk in roughly 20hrs time?
<barry> jml: yes, should be able to
<jml> barry: cool. let's have a chat then.
<barry> great.  that's it then.  thanks everyone!
<jml> thanks barry
<barry> cheers
#launchpad-meeting 2008-05-14
<barry> #startmeeting
 * barry looks to the ceiling and cries "moootbooottttt"
<barry> hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
<gmb> me
<statik> me
<sinzui> him?
<EdwinGrubbs> me
<sinzui> me
<bac> me
<BjornT> me
<intellectronica> me
<allenap> me
<flacoste> me
<schwuk> me
<salgado> me
<barry> bigjools: ping
<bigjools> me
<barry> danilos: ping
<danilos> me
<danilos> barry: thanks
<bigjools> sorry, was deep in a page test
<barry> :)
<barry> i think that's everyone
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>    * Discourage use of 'hasattr' (bac)
<barry>    * Use of 'assert' in doctests (BjornT)
<barry>    * Help people learn how big branches can be split up (BjornT)
<barry>    * Final vote multiline import
<barry>  * Next meeting
<barry> same time and place + weeks(1) ?
<barry> anybody know they will be missing or sprinting?
<intellectronica> the bugies will be sprinting
<gmb> barry: BjornT, intellectronica, bigjools, cprov, allenap and I will be at UDS.
<intellectronica> but maybe we can still make it
<barry> gmb, intellectronica cool
<bigjools> we might make it, depends if a BoF gets in the way or not
 * danilos makes a note of 'bugies'
<sinzui> I'm sprinting and am here
<barry>  * Action items
<BjornT> sinzui: you don't have a bunch of external people to adjust to, though
 * gmb thought we'd established it was BjÃ¶tches...
<barry>  * barry drive to decision about multiline sequences
<barry> BjornT: you should put the irc session up on a big screen and let everyone watch
<statik> that was fun in the florida sprint
<barry> anyway, we're very close to closing this one out.  see upcoming vote later today
 * barry can't wait to put that one to bed
<barry>  * barry to solicit ideas to better handle review scheduling and workload
<barry> nothing really happening there
<barry> do people still seem overwhelmed by review workload?
<bigjools> depends on how much real work I have
<bigjools> which is always a lot :)
<barry> bigjools: what? reviewing isn't real work? :)
<bigjools> barry: hell no, don't you sit with your feet up all day until you get pinged for a review?  ;)
<intellectronica> barry: sharing with allenap seems to make it much better for me
<barry> bigjools: sure i do, but it's such a pain to have to go refilling that gin&tonic all the time while i do it
<bac> yesterday was very light -- probably b/c danilo did all of the EU reviews before i started.
<sinzui> I assume I only write code 4 days of the week. I assume I can only review 2 hours if I am mentoring. That brought me back to an equilibrium of time
<barry> intellectronica: great!  hopefully we'll have lots of good pairing as we get closer to our goal of everyone is a reviewer
<barry> sinzui: yep
<barry> anyway...
<barry>  * let's remind people in review replies to clean up their PR branches
<barry> i sent out an email today on this... (thanks gmb! :)
<danilos> that will mean we'll also need to change that suggestion of "what do we do while we wait for review requests to pop up while on call"
<gmb> :)
<barry> danilos: can you elaborate?
<danilos> barry: well, we have so far considered that it's best not to work on anything "hard" while you are on-call; if we get two reviewers on-call at the same time, review workload would be much smaller
<danilos> so, should this change when we get more reviewers or not
<barry> danilos: ah, i see.  for the past few weeks i keep thinking i might get something else done while waiting for reviews, but my dance card always seems to fill up
<barry> danilos: we'll have to see
<barry>  * bac to add a link to his PR notification script from TipsForReviewers
<bac> done
<danilos> barry: yeah, it happened to me yesterday as well, but the way day started I definitely could have gotten more work in at the start of day (empty general queue, nobody wanting anything :))
<barry> bac: thanks!
<barry> danilos: waiting for all those crazy western hemispheroids to wake up? :)
<barry>  * flacoste to add `safe_hasattr()` to `lazr.utils`
<danilos> barry: not really, I guess waiting for those EU guys to actually write some code in the morning :))
<flacoste> barry: hmm, that was changed to file a bug, no?
<flacoste> barry: which i think i did... at least i filed a bug related to a reviewer action item
<barry> flacoste: i might have missed that.  if you filed the bug, thanks!  can you double check so i can remove this action item?
<flacoste> i guess i need an action item: "flacoste to get his act together"
<barry>  * bac to write up a warning on `hasattr()` in PythonStyleGuide
<bac> done
<barry> bac: awesome
<bac> also added to reviewer checklist
<barry>  * gmb to add lpreview to sourcecode and hack rf-setup to link it in
<barry> bac: thanks!
<barry> gmb: done, right?  we can finally remove this one?
<gmb> barry: It's now in SC and the rf-setup hack needs to be landed after I've made the changes that you and bigjools suggested. But it'll land today, so feel free to remove it.
<barry> gmb: great!  we are on a roll :)
<barry>  * gmb to prod mwh again about the 800-line limit patch
<gmb> Also done.
<gmb> He has one suggestion.
<gmb> Basically, my fix was to only allow a > 800 line branch if you'd agreed it with a review (and so specified one on the command line)
<gmb> However, mwh felt that was - in his words- over the top
<gmb> So he suggested just having a --force flag.
<gmb> I'll make the changes today unless there are any objections to that.
<intellectronica> gmb: how about doing what we do for lint?
<gmb> intellectronica: ?
<bigjools> a warning
<bac> i like a force flag.  people often specify a reviewer but might not know the branch is too big.
<intellectronica> gmb: so that if it's longer you're forced to explain why in words?
<barry> intellectronica: +1
<gmb> Sure, that can be done.
<intellectronica> you know [This diff is too long, if you still want to send it remove this line and explain why it's OK]
 * barry likes these kinds of "subtle" social reminders :)
<barry> gmb: thanks for doing this.  i'm going to remove the action item
<barry>  * sinzui to update js style guide page with helpful resources
<sinzui> Done.
<barry> sinzui: thanks!
<barry>  * sinzui or flacoste to add sampledata check to lpreview or make lint
<flacoste> ah!
<flacoste> that was the bug i filed!
<barry> flacoste: cool!  i'll take this one off and leave the other on for now
<flacoste> bug 227779
<ubottu> flacoste: Bug 227779 on http://launchpad.net/bugs/227779 is private
<barry> wow, i'm impressed at how many action items we crushed this week.  thanks everyone!
<flacoste> Add a test for out-of-date sampledata
<barry> flacoste: great, thanks
<barry>  * Queue status
<barry> nothing from me here.  things look generally good to me.  any comments?
<sinzui> Do we have a plan for Carlo's many branches?
<barry> you mean his many wips?
<sinzui> Yes
<barry> i think his team is going to have to handle that.  i don't know what we as reviewers can do
<barry>  * Mentoring update
<barry> any feedback from mentors or mentorees?
 * bigjools would like the chance to do a translations review
<bigjools> and code
<danilos> bigjools: not had a chance to do that yet?
<sinzui> I think the Europeans should take advantage of schwuk when he is available.
<bigjools> nope
<intellectronica> bigjools: it's quite rare that anyone here gets to do -code reviews
<danilos> bigjools: we can make something happen in the next few days, I'll come directly to you :)
<bigjools> intellectronica: I gathered, they're a bit cliquey down there :)
<schwuk> sinzui: Very little has come through on-call the last couple of weeks.
<schwuk> Maybe everyone is waiting for week 3... :)
<sinzui> schwuk: Indeed.
<danilos> well, everybody now has a reviewer on their own team, and that cuts on the explaining, meaning people tend to use that more
<bigjools> danilos: thanks, make it a big nasty one ok? :)
<danilos> bigjools: don't worry, just the kind I've got in store for you :)
<bigjools>  /o\
<intellectronica> bigjools: you think that will redeem you for all those incomprehensible soyuz branches you always give us? ;)
 * bigjools chuckles
<barry> :)
<bigjools> soyuz is like a pubic hair on a toilet seat
<bigjools> you're gonna get pissed off sooner or later
<intellectronica> but less sexy
<gmb> That's what I like about this team, the highbrow humour...
<barry> bigjools: as my dad always says: it's better to be pissed off than pissed on
<bigjools> your dad sounds wise
<sinzui> I think that remark was worthy of mneptok
<barry> :)
<barry>  * Mentoring update
<barry> oops
<intellectronica> mneptoring update?
<barry> stoopid keyboard
<barry>  * Review process
<barry> let's do the fun one first
<barry>    * Final vote multiline import
 * bigjools hides
<barry> all in favor of switching to one-line-per-import say "aye".  all opposed, say "nay"
<flacoste> nay
<bigjools> I just had a conflict in the imports at the top of security.py - how's that for coincidence
<intellectronica> nay
<gmb> nay
<salgado> nay
<BjornT> nay
<barry> nay
<sinzui> nay
<danilos> nay
<bigjools> abstain
<EdwinGrubbs> aye
<schwuk> aye
<allenap> aye
<bac> aye
<barry> wow, interesting
<flacoste> mars has another style suggestion to minimize conflicts
<flacoste> he'll send it off to the list
<bigjools> tbh I would prefer bzr to resolve these automatically
<barry> given where i think asiapac is on this, i think we're at a standoff
<flacoste> but instead of importing from interfaces which is the hot-spot, we import from interfaces.person
<flacoste> or interfaces.bugs
<barry> flacoste: maybe that means we can finally get rid of the import-*'s in package __Inits__?
<danilos> flacoste: could we then also stop updating interfaces/__init__.py
<danilos> barry: :)
<flacoste> right
<flacoste> praise goes to mars
<barry> danilos: <wink>
<flacoste> you can send complaints to me
<danilos> flacoste: about anything, or just about this? ;)
<BjornT> flacoste: you mean creating new files, or importing from the file where the interface is defined?
<flacoste> the latter
<barry> flacoste: great.  we'll see how that's received on the list
<flacoste> i mean, these conflicts always happen when importing from interfaces
<bigjools> sounds reasonable
<barry> we have 6 minutes left and a couple of items so let's move on and follow up to mars's post
<BjornT> flacoste: right, i though so. it was just that interfaces/bugs.py doesn't exist.
<flacoste> lol
<barry>    * Discourage use of 'hasattr' (bac)
<bac> sorry i forgot to remove that from the agenda.  nothing to see here.
<barry> bac: cool
<barry>    * Use of 'assert' in doctests (BjornT)
<BjornT> this is from the review of bac's fix to the broken assert statement in a doctest
<BjornT> i commented on that we shouldn't use assert at all in doctests, since imo, all tests should be in the form of 1) do something 2) check the output
<BjornT> bac or danilo said this wasn't mentioned in the tests style guide
<barry> BjornT: +1
<sinzui> +1
<barry> BjornT: can you add an item to the test style guide covering this?
<BjornT> barry: sure
<intellectronica> as a last resort, you can always print out a boolean
<barry> BjornT: thanks
<danilos> bac wanted to have an explanation printed out in case of failure, as far as I could understand at least
<bac> i'm +1 on the new policy.  note there are almost 100 instances of assert in our pagetests
<barry> bac: fertile ground for drive byes :)
<BjornT> in doctests the explanation can go in the narrative, though. it's also possible using if statements.
<danilos> BjornT: agreed
<barry> we have one minute left, i apologize for going over
<barry>    * Help people learn how big branches can be split up (BjornT)
<BjornT> so, we have a limit on how big a branch should be
<BjornT> i it bigger, the coder has to negotiate with a reviewer to get it reviewed
<BjornT> i don't think this works that well in practise. all that happens is that the reviewer says something like: "you can't make it any smaller? ok, then"
<danilos> and then "now you'll see how it _can't_ be made any smaller" :)
<BjornT> i think we need to be better at teaching people how to break up the work into smaller pieces
<BjornT> this is something that people need to learn to think about before starting coding, rather than after the branch has gotten too big
 * gmb has started using looms for just this purpose
<BjornT> my proposal is that if you have a branch that is too big, you have to spend time with something to go through it, discussing how the branch could have been split up
<sinzui> BjornT: while I agree with you, that may best start with the pre-implementation call.
<intellectronica> sinzui: right, but if it didn't?
<bigjools> Are we ok with reviewing unlandable diffs?  That way someone can have different parts reviewed and then merge them before landing.
 * barry observes that pre-impls have been happening less and less
<BjornT> bigjools: yes. as long as the diff makes sense of its own.
<danilos> I'd be +1 on actually going with a developer through the branch and seeing what could have been split up, -1 on reviewing unlandable diffs
<bigjools> BjornT: sure, that goes without saying :)
<intellectronica> +1, i benefited a lot from going through this kind of stuff, and think it's time very well spent for any developer
<barry> -1 on unlandable diffs
<danilos> well, in my definition "unlandable" == doesn't work (i.e. make check or make run fails)
<bigjools> when I say unlandable, I mean things that make sense on their own but would fail tests
<intellectronica> danilos: sometimes there's no choice, and it's still better to split the work
<BjornT> bigjools: well, maybe not quit unlandable. i was thinking of diffs that could be landed, but shouldn't be.
<bigjools> BjornT: yeah, so we need a definition of "shouldn't be"
 * mars tends to create those when refactoring
<danilos> intellectronica, bigjools: I feel every new code should be accompanied by at least documentation that passes
<barry> BjornT: the way to think about that is a loom thread i think.  something that's part of a larger whole, but that stands on its own and is reviewable on its own, but maybe not landed until other threads are also approved
<bigjools> danilos: I agree
<intellectronica> danilos: right, so that's something to take into consideration when planning how to split the work!
<BjornT> barry: yes, that's my thinking as well.
<barry> the risk though is that those larger things will end up landing at the end of week three
<bigjools> I am extremely wary of creating loads of small branches given PQM's run time
<danilos> barry: doesn't everything land at the end of week three? (and mostly Sundays :))
<barry> danilos: :-D ;-}
<gmb> bigjools: You don't have to land them all separately though.
<danilos> one can merge branches before landing, using [r=one,two,three]
<BjornT> barry: compared to what? we're talking about breaking up large branches.
<bigjools> gmb: right, hence my "merge them" comment
<barry> gmb: exactly!  combine-thread
<barry> then land
 * gmb *actually reads* the scrollback.
<barry> BjornT: good point
<danilos> the only thing to worry about is [log] messages for those actually processing logs, but since we are talking about related branches, this should only reduce the number of [!log] landings
<barry> BjornT: so we need a plan to help devs learn how to use looms effectively
<barry> danilos: hopefully
<sinzui> bigjools: The developer can delay landing the branch until all the feature is assembled.
<BjornT> barry: right. another thing to help them learn is how to actually split up the work itself. you don't really need looms to do it, it just makes the workflow easier.
<bigjools> I quite often find my self doing that - landing separate fixes for a big bug fix
<barry> we're way over, but i'd like to keep this one on the agenda for next week.  in the meantime, can we think about this issue some more, specific ways to accomplish this?
<bigjools> I don't think looms are necessary, you just need to plan your work
<BjornT> it's the splitting up of the work that is the hardest part. not how you manage the branches.
<bigjools> anyone with the intelligence to work here should be able to split the work, they just need to remember to do it
<barry> bigjools: agreed that looms are just a tool to help you organize things, but you're right that its the organization that's key
<BjornT> that's why i suggested forcing people with big branches learn how the branch could have been split up. they are the ones the probably need the help the most :)
<barry> BjornT: thanks for bringing up an important topic.  because we're 10 minutes over, i'd like to cut this short for now.  apologies for that and for going so far over today
<intellectronica> bigjools: right, so, if they don't do it, they can be asked to go and do it now, and if they say that they don't know how to they should be able to get help
<bigjools> pre-imp calls would help....
<barry> agreed.
<bigjools> intellectronica: yup - and remind them that a pre-imp call would have helped avoid having to break it up :)
<barry> #endmeeting
<barry> thanks everyone!
<bigjools> thanks barry
<intellectronica> thanks barry
<BjornT> bigjools: unfortunately, reminders don't work that well :(
<bigjools> BjornT: threats? :)
<BjornT> bigjools: yes, that would be better :)
<bigjools> BjornT: I agree though, people should get some help, the best way to do that is to plan the work via a pre-imp
<danilos> basically, a requirement to go through how-to-split-up-discussion with a reviewer online should make everybody do their split ups beforehand :)
<BjornT> bigjools: right. although, i do think that looking at a real diff which is too big is also helpful.
<bigjools> yup
<danilos> BjornT: people usually have blueprints which document the big picture as well
<bigjools> I get the impression that massive diffs arise when starting to work on something that's not Ready To Code
<sinzui> BjornT: I had a branch that I explained I did not have time to review, but I could review part of it if it was divided into: components and vocabularies, model changes, view changes. I got the components and vocabularies branch 20 minutes latter.
<bigjools> sinzui: right - some stuff like that is so easy to split out
<sinzui> I think cprov didn't see that he could split them out because they were dead code until the mode or view changes landed
<BjornT> bigjools: still, most people don't do it. they only do it if the branch gets too big, and then it's usually quite a lot of work splitting it up.
<bigjools> BjornT: agreed - we could be more efficient here
<cprov> sinzui: sorry, split-up which code ?
<sinzui> cprov: You had a large branch once that I did not have time to review, but you kindly broke it into 3 or 4 parts so i could start the review.
 * bigjools heads off for caffeine
<cprov> sinzui: a previous branch, right, I remember something. It actually happened several time with me.
<cprov> and I'm proud of it :-/
<cprov> it's happen again, actually, `copy-ui_constraints` r=barry. The diff has grown up to 900 lines.
#launchpad-meeting 2008-05-15
 * gmb -> pre-meeting cuppa
<Rinchen> we've got MootBot!
<schwuk_> w00t!
<Rinchen> no idea where the logs will be though
<barry> Rinchen: didn't work for me at the ameu meeting :(
<Rinchen> no?
<gmb> barry: You yelled "mooooooootttttttttttboooooooooottttt"
<Rinchen> #startmeeting
<gmb> I think it needs more encouragement
<barry> gmb: i did the same thing Rinchen just did first tho!
<gmb> Ah, true.
<Rinchen> ah well. I know it's running on a private machine in the UK atm
<Rinchen> and hosting was acquired earlier
<Rinchen> bummer
<Rinchen> old fashioned way to
<Rinchen> day
 * barry tempts with tasty treats: "here mooty mooty!"
<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!
<mrevell> me
<salgado> me
<thumper> me
<al-maisan> me
<rockstar> me
<herb> me
<statik> me
<schwuk> me
<bac> me
<adeuring> me
<matsubara> me
<gmb> me
<barry> me
<BjornT> me
<Rinchen> do
 * stub yawns
<bigjools> me
<stub> me
<cprov> me
<kiko> me
<Rinchen> SteveA, ?
<abentley> me
<EdwinGrubbs> me
<Rinchen> allenap?
<salgado> leonardr?
<leonardr> me
<Rinchen> mthaddon, herb?
<Rinchen> ah found herb
<mthaddon> here
 * herb me'd above
<mthaddon> aka "me"
<Rinchen> salgado, are you in Canada? Can you poke Francis?
<salgado> Rinchen, I'm not
<Rinchen> see how you are
<kiko> canada? why would he do that!
<Rinchen> to escape from you? :-)
 * Rinchen laughs.
<Rinchen> Agenda
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (Matsubara)
<Rinchen>  * Critical Bugs (Rinchen)
<Rinchen>  * Bug tags
<Rinchen>  * Operations report (mthaddon/herb)
<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> Tom B will not be here today
<allenap_> me (apologies, computer crashed)
<Rinchen> Next meeting
<Rinchen> kiko, did we decide not to rotate the team meeting for now?
<kiko> we did.
<Rinchen> ok, then we'd be on for 22 May at 18:00 UTC on this channel
<matsubara> Rinchen: next meeting is a National holiday in BR
<Rinchen> Anyone know they will not be here?
<SteveA> me
<matsubara> Rinchen: I won't be around.
<kiko> I'll be at UDS but will make it
<SteveA> I'll be travelling back from UDS
<gmb> I'll be at UDS
<Rinchen> ah yes, Chorpus Christi
<SteveA> so I won't make it
<bigjools> uds
<sinzui> me
<cprov> I will be working, at UDS, so will participate.
<al-maisan> uds
<BjornT> i'll be at uds as well
<Rinchen> Should we perhaps skip next week to allow everyone to be on holiday or actively participate at UDS?
<gmb> (It'll be 20:00 for the UDSers, so it might be hard to fit it in around food)
<kiko> Rinchen, hmmmm. it's week 3.
<gmb> We could bring it forward for one week, couldn't we?
<BjornT> gmb: i'm sure we can find a restaurant with wifi :)
<vednis> me?
<cprov> gmb: it already is, at it doesn't seem to be considered as a valid problem.
<Rinchen> If there a problems I expect folks to escalate them and not wait...as per normal
<bigjools> BjornT: you mean a bar
<kiko> Rinchen, I think we should have it.
<gmb> cprov: True enough.
<Rinchen> kiko, ok. It might be a quick one. :-)
<Rinchen> Actions from last meeting
<Rinchen> there were none
<Rinchen> Oops report (Matsubara)
<abentley> bars with wifi.... what could go wrong?
<matsubara> Today's oops report is about bugs 230801, 230802, 230805
<ubottu> Launchpad bug 230801 in launchpad "AssertionError triggered renewing team membership" [Undecided,New] https://launchpad.net/bugs/230801
<ubottu> Launchpad bug 230802 in launchpad "InvalidURIError when request contains malformed URL" [Undecided,New] https://launchpad.net/bugs/230802
<ubottu> Launchpad bug 230805 in launchpad-bazaar "TraversalError in code-index page for a project" [Undecided,New] https://launchpad.net/bugs/230805
<matsubara> salgado, 230801 is for you. Can you take it?
<matsubara> flacoste, can you help debug 230802?
<matsubara> thumper, this one is for you: 230805. Can you assign someone from your team?
<thumper> matsubara: yes
<salgado> matsubara, do we really need to worry about it or is it something that'll happen rarely?
<matsubara> thumper: linkchecker caught that one, which make me happy :-)
<flacoste> matsubara: yeah, i'll have a look
<matsubara> salgado: it's an oops so need to be fixed. I'm not asking you to fix it right now, but please squeeze the fix in when you can.
<kiko> thanks thumper
<matsubara> apart from that, I'm done Rinchen
<matsubara> thanks flacoste, thumper, salgado
<matsubara> back to you Rinchen. thank you
<Rinchen> thanks
<Rinchen> Critical Bugs (Rinchen)
<Rinchen> two for today, 1 for jtv who's not here
<Rinchen> so I'll skip that for now
<Rinchen> flacoste, What's the new memory bug?
<Rinchen> last week you indicated we should create a new one
<flacoste> Rinchen: current working hypothesis is that it's the maximum batch size
<kiko> new memory bug!
<SteveA> flacoste: do we have this CPed into lpnet ?
<kiko> yes
<kiko> oh, no
<flacoste> SteveA, kiko: no
<kiko> for some reason
<SteveA> why not?
<flacoste> there are conflicts
<kiko> we were supposed to yesterday
<kiko> ah
<flacoste> because of fixes to the webservice
<flacoste> i need to sort it out
<flacoste> herb is waiting for me on that
<flacoste> Rinchen: bug 135681 for now
<Rinchen> flacoste, can you or a member of your team craft up a new bug report as was agreed to in last week's meeting so we can track this?
<ubottu> Launchpad bug 135681 in launchpad "All batched listing mentions "results" even when they don't represent search results " [Medium,Confirmed] https://launchpad.net/bugs/135681
<Rinchen> pulease
<Rinchen> preeeety preeety puhlease
<kiko> Rinchen, you didn't [ACTION] that!
<Rinchen> [ACTION] Francis to bug the batch sizes
<flacoste> Rinchen: i'd wait to see how batch size affects this
<Rinchen> ok. Well, I have it in my notes so you're not escaping this topic.  ;-)
<flacoste> Rinchen: like i said, i'd track it as bug 135681 for now which is Critical
<Rinchen> I'll touch base with jtv on his item...
<ubottu> Launchpad bug 135681 in launchpad "All batched listing mentions "results" even when they don't represent search results " [Medium,Confirmed] https://launchpad.net/bugs/135681
<Rinchen> k
<Rinchen> thanks
<Rinchen> movingon
<Rinchen> Bug tags
<Rinchen> we have no requests
<flacoste> Rinchen: sorry, bug 228132, which isn't Critical, i'll raise it's priority
<ubottu> flacoste: Bug 228132 on http://launchpad.net/bugs/228132 is private
<Rinchen> thanks
<Rinchen> Operations report (mthaddon/herb)
<herb> 2008-05-10 - Upgraded DB server to hardy. Approximately 45 mins. of service downtime.
<herb> 2008-05-12 - Librarian was flapping for approximately 45 mins. Recovered on its own.
<herb> 2008-05-14 - Codebrowse was restarted.  It was non-responsive.
<herb> 2008-05-14 - Cherry picked r6287 and the fix for bug #224617.
<herb> New server running hardy was added to the edge rotation on Friday of last week.
<herb> We're working on a replacement graphing tool for cricket.
<ubottu> Launchpad bug 224617 in rosetta "XPI import stumbles over malformed or email-less contributor entries." [Critical,Fix committed] https://launchpad.net/bugs/224617
<herb> The hardy chroot for storm-integration branch is now ready.
<herb> That's it for Tom and me unless there are any questions.
<flacoste> herb: when is PQM being migrated to hardy
<flacoste> ?
<SteveA> herb: flapping?
<kiko> flacoste, mthaddon's working on that.
<mthaddon> flacoste, we need to schedule time with IS to make sure there's not a long lag between that and prod server upgrades
<SteveA> what does that mean?
<herb> flacoste: I don't think we have a date set in stone yet.
<mthaddon> flacoste, and we need to make sure the test suite passes in hardy PQM chroot (which we can test any time)
<kiko> flacoste, did you see tom's landing from yesterday? a step in that direction.
<herb> SteveA: an external test showed it going online and offline periodically
<kiko> herb, no logs exist, right?
<kiko> jtv, totbb.net!!
<jtv> gah, damn these late-night meetings
<herb> kiko: none that I'm aware of, but mthaddon might have better insight on that.
<kiko> herb, I think there aren't -- flacoste was telling me about this
<kiko> jtv, we choose our burdens!
<flacoste> librarian logs
<flacoste> ?
<flacoste> they exist, but aren't very interesting usually
<mthaddon> kiko, there are librarian logs (twistd style), but we haven't investigated them yet - assumed it was swap/memory related
<Rinchen> Anything else for herb and mthaddon ?
<SteveA> do we have swap/memory logs?
<mthaddon> SteveA, we have graphs, not logs - server specific, not application specific, so could start by looking at those
<herb> not to speak of
<flacoste> herb has an interesting script that produce very interesting data
<flacoste> (RSS by app server)
<herb> flacoste: I do?
<flacoste> wouold be very interesting to hbave that in cricket
<SteveA> correlating those graphs with the flapping reports may tell us something
<mthaddon> flacoste, herb: would that work for the librarian as well as an app server?
<flacoste> it should
<mthaddon> SteveA, yeah, I'll take a look after the meeting
<flacoste> it's basically a periodical ps dump
<flacoste> or something like that
<herb> mthaddon: it's just a quick and dirty script that runs a ps periodicaly
<SteveA> ok
<mthaddon> gotcha
<Rinchen> Anything further?
<Rinchen> ok then
<Rinchen> DBA report (stub)
<stub> The production db server is now running Hardy. The backup server seems a little behind the revisions but will hopefully catch up soon.
<stub> It is apparently week 2 again so db patch reviews need to happen. Only one or two this cycle it seems.
<stub> Nothing else thrilling happening.
<Rinchen> stub, I noticed you had a few specs due this cycle
<kiko> stub, wanted to know about PersonASplit
<SteveA> "a little behind the revisions"V?
<Rinchen> read only LP and something else
<SteveA> you mean the OS?
<SteveA> or the data we sync over?
<stub> read only lp has been rescheduled - testing is blocked until we have PG 8.3 running on hardy boxes with slony-i installed.
<kiko> stub, and PAS?
<stub> authpersonsplit - the first chunk should be on the review page tomorrow
<stub> bjorn will be happy - validpersonorteamcache needs to go
<mthaddon> SteveA, nothing unusual on librarian server in terms of swap, IO, memory or load around the time of the "flapping"
<BjornT> yay :)
<SteveA> mthaddon: interesting.  so it's a mystery...
<Rinchen> stub, when you get a chance please review those specs assigned to you and adjust as you need to in order to match reality
<mthaddon> so far, yeah...
<Rinchen> Anything else for stub ?
<Rinchen> ok then
<Rinchen> thanks stub
<Rinchen> Sysadmin requests (Rinchen)
<Rinchen> Is anyone blocked on an RT or have any that are becoming urgent?
<mthaddon> SteveA, I'll take a look at the twistd logs too
 * stub falls asleep
<kiko> stub, neat! will look forward to that
<kiko> Rinchen, the private librarian RT?
 * kiko looks at bigjools 
 * bigjools is waiting on mthaddon, who knows how urgent it is ;)
<mthaddon> yeah, I need to talk with IS about that - unfortunately UDS is making that a little tricky at the moment... but working on it
<Rinchen> anything else?
<kiko> mthaddon, that RT is going to be an axe for my soft neck!
<Rinchen> there's a video game idea in there, I can just feel it....
<mthaddon> kiko, doing all we can, but it's quite a new ticket (i.e. haven't had much lead time) - was created last Friday I think
<Rinchen> New packages required (salgado)
<salgado> any new dependencies this week?
<salgado> guess not
<Rinchen> ok then
<Rinchen> A top user-affecting issue (mrevell)
<mrevell> This week's user affecting issue was obviously the effect that the SSH keys issue had on 2,333 Launchpad users' accounts.
<kiko> salgado, you added one!
<mrevell> Rather than use the launchpad-users list and the news blog to announce this, we contacted each of the affected users directly.
<kiko> salgado, have you updated lp-deps?
<mrevell> I'm pleased to say that, so far, only five people have replied. Of those, three asked "what security vuln?" and the other two asked if we'd deleted everyone's key because they were certain their key was not vulnerable.
<salgado> kiko, yep, I did
<mrevell> I'm waiting on IS for a reply to that last one and they've said they'll provide me with one.
<mrevell> Thanks Rinchen.
<Rinchen> thank mrevell
<Rinchen> Doc Team report (mrevell)
<mthaddon> mrevell, we only deleted vulnerable keys
<mrevell> mthaddon: May I talk to you about that in a bit?
<mrevell> mthaddon: to get a good answer?
<mthaddon> mrevell, sure
<kiko> mrevell, so WTF is wrong with those people -- did they not run ssh-vulnkey?
<mrevell> kiko: One guy said that ssh-vulnkey showed no problems.
<kiko> mrevell, tell them to update their openssh packages and run ssh-vulnkey, the nerve
<SteveA> mrevell: tbh, I'd just say "we searched for vulnerable keys and deleted only those that matched ssh-vulnkey.  you can make a new one and upload it to launchpad."
<kiko> mrevell, did he prove it? :)
<mrevell> SteveA: Okay, thanks for that.
<SteveA> mrevell: we don't need to get IS involved tracking anything down
<abentley> kiko: ssh-vulnkey was apparently not provided by all distros.
<kiko> SteveA, well, unless we /did/ delete keys by mistake
<mrevell> kiko: Heh, he didn't :)
<SteveA> mrevell: the important thing is that we have acted in good faith, and there's a route for the user to get their ssh account usable again.
<kiko> SteveA, which might mean that something else is wrong (i.e. compromised keys left there)
<kiko> mrevell, ask him to show command output to match the keyids
<Rinchen> or run the vuln check again
<mthaddon> mrevell, if they try reuploading the same key and it works (i.e. not caught by the vuln filter now in place) then we really did delete their key unnecessarily and should apologise
<mrevell> kiko: Thanks, I'll do that.
<stub> users might have had both an ok and a vulnerable key loaded into Launchpad and had only one removed
<Rinchen> good point stub
<mthaddon> ditto that
<Rinchen> that did happen on the day we did this
<mrevell> Thanks everyone for the input.
<Rinchen> now, about the doc team....
<mrevell> Trying to rally the troops by holding an IRC meeting next week. I've mailed the 19 members of the doc team to see if they can make it next Tuesday.
 * Rinchen has added it to the team calendar.
<mrevell> Other doc news: I've sent the coming changes and proposed release announcement features to the mailing list. Work on the tour is progressing and I'm hoping to finally have the inner page graphics from the designer back tomorrow.
<mrevell> thanks rinchen, was gonna do that once I'd had some confirmation replies.
<mrevell> Elliot, Joey and I recorded the first of our new podcast yesterday. Unfortunately, a problem I still haven't identified meant our interview with Tony at RescueTime was unusable, so we're re-recording that Monday. However, the rest went really well and I can't wait to get it out there!
<mrevell> back to you Rinchen
<Rinchen> Thanks mrevell.  Any questions for Matt?
<Rinchen> I'm going to backup for a second since jtv is here
<Rinchen> [LINK] https://bugs.edge.launchpad.net/rosetta/+bug/229630
<Rinchen> jtv, was this due to missing instructions for the cherrypick?
<ubottu> Rinchen: Error: This bug is private
<jtv> Rinchen: not on my end.  Maybe the generic ones.
<Rinchen> jtv, ok. Progressing well on the fix?
<jtv> Rinchen: Already in.  Just a matter of LOSAs doing the same thing again.
<Rinchen> k, thanks.
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting.
<Rinchen> Enjoy the rest of your week!
<Rinchen> == The End! ==
<flacoste> thanks joey!
<mrevell> thank you emmceeing Rinchen
<jtv> Rinchen: thanks for waking me up
<jtv> Rinchen: I wouldn't have come in otherwise
<mrevell> Okay friends, see you tomorrow!
<Rinchen> jtv, no problem. Now, back to sleep with you!
<statik> thanks joey
<kiko> what a fast meeting
<kiko> Rinchen, what's the idea in skipping my topic?
<jtv> kiko: he's still making up for that really long one a while ago
<Rinchen> kiko, wasn't on the agenda
<kiko> yes it was.
 * jtv gets popcorn & coke
<Rinchen> kiko, if you added it like 5 minutes before then I didn't see it
<kiko> Rinchen, I added it 10 minutes before
<kiko> and you are very cheeky!
 * jtv nibbles popcorn
<kiko> funny that I'm about to send in raise recommendations!
<bigjools> lol
 * jtv hides coke
<kiko> now where's my keyboard
<Rinchen> I just refreshed and sure enough it's there.
 * jtv finishes popcorn & coke.  The fun seems to be over.
<jtv> kiko: yhm
<Rinchen> faster my friend...go faster
<Rinchen> more lead time
<Rinchen> or poke me that you've adjusted the agenda please... If I saw it I would have pasted it in with the normal agenda
<Rinchen> sorry about that
<kiko> I'm thinking about it
<Rinchen> #startmeeting
#launchpad-meeting 2008-05-16
<beuno> it's a bit late now, aint it?   :p
<kiko> he was testing!!
<beuno> sure, sure
<Rinchen> I'm just always after a meeting
<mwhudson> beuno: i dunno, it would be a fine time for a meeting for me :-)
<beuno> mwhudson, Rinchen, well, ok, then let's have a meeting  :)
<Rinchen> :-)
<Rinchen> Apparently they didn't know mootbot wasn't listening
<mwhudson> that's not _quite_ what i mean :)
<Rinchen> so I was testing it for the scribes gent
<Rinchen> he's going to fix it in the morning
<Rinchen> I think we should pester Odd_Bloke to see how his PQM foo is doing these days :-)
<beuno> Rinchen, what time is it over where you are anyway?
<Rinchen> 18:00
<Odd_Bloke> ZOMG ping.
<beuno> Rinchen, hm, you seem to have a better time zone than me  :/
<Odd_Bloke> My PQM foo is not yet started, it still being exam season. :)
<Rinchen> lol
<Odd_Bloke> My exams don't finish until the 19th of June, but I won't realistically get any hacking done until after the 30th.
<Rinchen> ah well, I'm sure anything you can do to it will help
<Rinchen> although, a few of us might pay to see it tortured.
<Rinchen> slowly
<mwhudson> i don't think we can blame the problems we have landing branches on pqm itself, sadly
<Rinchen> test suite? we don't need no stinkin' test suite!
<mwhudson> oh boy, that approach would make our current level of pain look like a bed of lavender :)
<Rinchen> yeah, we'll just replace everything with test.py and call it good
<Rinchen> oh wait, we use zope... darn
<Rinchen> :-)
#launchpad-meeting 2009-05-13
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<gary_poster> me
<barry> hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
<gary_poster> (first post, first post!)
<gary_poster> uh, me
<danilos> me
<danilos> gary_poster: :)
<adeuring> me
<noodles775> me too
<henninge> me!!! ;)
<bigjools> me
<gmb> Mi.
<mars> me
<henninge> gmb: It's Mii
<bac> me
<henninge> as in Wii
<intellectronica> me
<gmb> henninge: I was banging on the keyboard like a monkey. Be thankful you got what you did.
<salgado> me
<gary_poster> lol
<barry> allenap: ping
<allenap> me
<barry> BjornT, cprov, EdwinGrubbs ping
<cprov> me
<BjornT> me
<flacoste> me
<barry> rockstar: sinzui ping
<barry> [TOPIC] == Agenda ==
<barry>  * Roll call
<barry>  * Action items
<barry>  * Mentoring update
<barry>  * Peanut gallery (anything not on the agenda)
<MootBot> New Topic:  == Agenda ==
<sinzui> me
<barry> [TOPIC]  * Action items
<MootBot> New Topic:   * Action items
<barry>  * gary_poster to take importfascist and rSP() discussion to ml
<gary_poster> no, sorry
<barry> gary_poster: next time? :)
<gary_poster> I hope so :-)  Looking for that info now
<barry> cool, thx
<barry>  * flacoste to work on API reviewer cheat sheet
 * flacoste whistles
<barry> :)
<barry> [TOPIC]  * Mentoring update
<MootBot> New Topic:   * Mentoring update
<bigjools> whistling while you work?
<sinzui> It's not exported until there is  a test
 * sinzui found a field that was not really exported, and there was no test to verify it was broken
<barry> any updates, problems, issues, questions, comments from mentats or mentors?
<henninge> I'm fine .
<noodles775> not really... I'm enjoy the learning process so far :)
<barry> great!
<barry> thanks mentors
<barry> [TOPIC]  * Peanut gallery (anything not on the agenda)
<MootBot> New Topic:   * Peanut gallery (anything not on the agenda)
<barry> that's all i have for today, do you all have anything?
<barry> i guess not
<barry> looks like maybe we're done in record time?
<henninge> Y nodd
<henninge> ;)
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 09:09.
<bigjools> wow
<allenap> Wow.
<barry> thanks everyone!  see you in barcelona
<bigjools> si
<gary_poster> bye
<barry> where we'll have a 5 hour reviewers meeting to make up for lost time
<bigjools> barry: don't forget your "friends" :)
<allenap> Can everyone leave the swine flu at home?
<barry> bigjools: thanks! :)
<barry> bye bye
<barry> #startmeeting
<jml> hi?
<MootBot> Meeting started at 17:32. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<jml> wasn't it in +0.5?
<barry> i think we're on the half hour
<barry> AsiaPac Wednesday 13-May-2009 2230 UTC - 2315 UTC
<barry> thumper, mwhudson are you here?
<mwhudson> yeah
<thumper> yeah
<barry> i really have almost nothing, so i'll dispense with the formalities and throw it open to you guys
<mwhudson> hey, this cycle is really short
<barry> mwhudson: indeed, but it's been my most productive one in months :)
<barry> thumper: you had an item?
<thumper> yes
<thumper> I've moved the LaunchpadObjectFactory to live in lp.testing.factory
<thumper> and login, logout et al lp.testing
<thumper> reviews should check this now
<jml> phone, sorry
<thumper> there are compability shims in canonical.launchpad.testing
<thumper> that I'd like to see go
<barry> thumper: cool, thanks for doing the rename.
<thumper> but there were like a million places in the code
<thumper> so I didn't do that
<thumper> and my awk foo isn't that good
<barry> thumper: i know a great language that you could write it in
<thumper> I did consider it
<thumper> but it isn't a simple 1 -> 1 move
<barry> thumper: actually (seriously) check with sinzui.  he may have all the basic pieces
<thumper> not enough
<thumper> I used the rename-module script for most of it
<thumper> but due to circular import crap
<barry> thumper: oh, and doctests /should/ be easy since none of them should explicitly import it
<thumper> I couldn't import the factory into lp.testing.__init__
<sinzui> lp-dev-utils/migrater/rename_module path_to_old path_to_new
<thumper> barry: they are done
<thumper> barry: I fixed the globs
<barry> thumper: cool
<barry> thumper: why does lp.testing.__init__ need it?
<thumper> barry: it doesn't
<thumper> but the old import did that
<sinzui> thumper: do you want to do a find and replace of an import path across the whole tree?
<thumper> so you could get the factory from canonical.launchpad.testing
<barry> oh i see, and call sites used the old import
<thumper> now you need to get it from lp.testing.factory
<thumper> but login et al can come from lp.testing
<thumper> sinzui: for a single class, yes
<thumper> sinzui: although you could do it if you like :)
<thumper> also, much mail stuff moved into lp.services.mail
<thumper> so
<thumper> sendmail
<thumper> signed_message
<thumper> some others
<thumper> more needs to move
<thumper> but I did some
<sinzui> lp-dev-utils/migrater/find.py [-s 'new.path'] . . 'python_re_pattern'
<sinzui> thumper: send me the module old and new path
<barry> thumper: can you add deprecation warnings to the shims?  i think that will fail the tests though
<thumper> sinzui: LaunchpadObjectFactory from canonical.launchpad.testing to lp.testing.factory
<thumper> barry: that was all
<thumper> barry: that and poking others to continue moving stuff
<thumper> :(
<thumper> plasma just died
<barry> thumper: cool.  i suggest an email to the ml to motivate devs to do drive bys
<thumper> relentless poking at all hands should suffice
<barry> cool, thanks
<barry> anything else from you guys?
<thumper> not from me
<barry> jml, mwhudson ?
<barry> 4
<barry> 3
<mwhudson> i'm moving canonical.codehosting to lp.codehosting\
<mwhudson> noone else should care though
<barry> mwhudson: +1
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 17:43.
<barry> thanks guys
<mwhudson> thanks barry :)
<thumper> ta
 * sinzui uses find.py -s lp-dev-utils/migrater/'lp.testing.factory'  . . 'canonical.launchpad.testing'
<sinzui> hmm that is not good, login_person is broken in a few places
<thumper> sinzui: we want login_person from lp.testing
<thumper> that was my problem
<sinzui> and TestCase?
<thumper> lp.testing
<sinzui> I think I do this in two passes
#launchpad-meeting 2009-05-14
<jml> sorry guys.
 * jml is back.
<Ursinha> henninge, :)
<henninge> Ursinha: Hi :)
<rockstar> Hi
<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.
<Ursinha> [TOPIC] Roll Call
<Ursinha> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<MootBot> Meeting started at 10:02. The chair is Ursinha.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<MootBot> New Topic:  Roll Call
<bigjools> me
<Ursinha> me
<henninge> ich
<sinzui> me
<rockstar> me
<flacoste> me
<herb> me
<Ursinha> herb, intellectronica, hi
<Ursinha> :)
<Ursinha> who's missing?
<Ursinha> stub is missing, but he can join later
<Ursinha> intellectronica is missing too
<Ursinha> let's move on
<Ursinha> [TOPIC] Agenda
<Ursinha> * Actions from last meeting
<Ursinha> * Oops report & Critical Bugs
<Ursinha> * Operations report (mthaddon/herb/spm)
<Ursinha> * DBA report (stub)
<MootBot> New Topic:  Agenda
<Ursinha> [TOPIC] * Actions from last meeting
<Ursinha> * Ursinha to talk to intellectronica about bug 357316
<Ursinha> * Ursinha to talk to henninge about bug 302449
<Ursinha> * rockstar to confirm that bzr fix for bug 360791 was applied to LP's bzr tree.
<MootBot> New Topic:  * Actions from last meeting
<Ursinha> * cprov to request CP of fix for bug 370513
<ubottu> Launchpad bug 357316 in malone "hwdb +submit failing with KeyError OOPS" [Undecided,Triaged] https://launchpad.net/bugs/357316
<ubottu> Launchpad bug 302449 in rosetta "Uploading a file with the same name triggers a database constraint." [Medium,Triaged] https://launchpad.net/bugs/302449
<Ursinha> I suck and failed mine
<ubottu> Launchpad bug 360791 in bzr/1.14 "bzr pull/branch shows "Error received from smart server: ('NoSuchRevision',)"" [Critical,In progress] https://launchpad.net/bugs/360791
<ubottu> Launchpad bug 370513 in soyuz "failure to accept PPA uploads" [Critical,Fix committed] https://launchpad.net/bugs/370513
<Ursinha> [action] Ursinha to talk to intellectronica about bug 357316
<MootBot> ACTION received:  Ursinha to talk to intellectronica about bug 357316
<Ursinha> henninge, hi :)
<henninge> I think danilo was onto that ...
<rockstar> I don't know if the fix has been cherry picked into production...
<Ursinha> henninge, can you just confirm that, please? it's set as medium, do we use that status?
<henninge> Ursinha: in rosetta we do ;)
<Ursinha> rockstar, hm, can you check that too?
<rockstar> Code team does, for things of medium importance.
<bigjools> as does Soyuz
<herb> rockstar: it was cherry picked on 2009-05-09
<Ursinha> I rarely see medium statuses :) that's why I'm asking
<Ursinha> thanks herb
<rockstar> herb: cool, thanks.
<Ursinha> [action] henninge to check with danilo the status of bug 302449
<MootBot> ACTION received:  henninge to check with danilo the status of bug 302449
<ubottu> Launchpad bug 302449 in rosetta "Uploading a file with the same name triggers a database constraint." [Medium,Triaged] https://launchpad.net/bugs/302449
<Ursinha> cool
<Ursinha> moving on then
<Ursinha> [TOPIC] * Oops report & Critical Bugs
<Ursinha> there's only one worth mentioning, that is the one causing the InterfaceError oopses, we're still having lots and lots of occurrences (bugs 374909 and 376207), seems to be worked on by jamesh, is that correct flacoste?
<MootBot> New Topic:  * Oops report & Critical Bugs
<ubottu> Launchpad bug 374909 in storm "InterfaceError: connection already closed should be converted into DisconnectionError" [High,Triaged] https://launchpad.net/bugs/374909
<ubottu> Launchpad bug 376207 in launchpad-foundations "LaunchpadOpenIDStore doesn't support database disconnection" [High,In progress] https://launchpad.net/bugs/376207
<flacoste> so, jamesh is working on 374909
<flacoste> and the other one also
<Ursinha> right
<flacoste> but stuart has an easy fix for the later, that I'll likely asked to be cherrypicked
<flacoste> we can deploy jamesh proper fix during next roll-out
<Ursinha> flacoste, hm, good
<Ursinha> flacoste, about the cp, when do you think it can be done?
<flacoste> i didn't look at the branch
<herb> 374909 is still cropping up from time to time, btw. though it's much gooder(tm) than it was last week.
<flacoste> but once i approved it, as soon as the LOSA can take care of it
<Ursinha> flacoste, right. okay
<flacoste> i don't think i'll ask a C-P of the INterfaceError
<flacoste> (storm fix being worked on by jamesh)
<herb> flacoste: why?
<flacoste> well, because that's not a root-cause
<flacoste> so with the other fix in place, we shouldn't see it
<herb> ok
<flacoste> that fix is more prophylactic
<Ursinha> flacoste, who's investigating the root cause?
<flacoste> if you are talking about why we are getting disconnection errors in the first place
<flacoste> nobody, really
<flacoste> but we have a fix for the places where we should be trapping those
<flacoste> and recovering
<Ursinha> yes, the disconnection errors
<flacoste> we have no ideas at why it's happening
<flacoste> there is nothing in the DB logs
<flacoste> about them
<Ursinha> this is creepy
<Ursinha> the fix you say you have
<Ursinha> is inside the fixes for one of those bugs?
<flacoste> yes
<Ursinha> great
<Ursinha> so, you'll ask a cp for the second bug
<flacoste> exactly
<Ursinha> [action] flacoste to ask a cp for fix for bug 376207 after reviewing it
<MootBot> ACTION received:  flacoste to ask a cp for fix for bug 376207 after reviewing it
<ubottu> Launchpad bug 376207 in launchpad-foundations "LaunchpadOpenIDStore doesn't support database disconnection" [High,In progress] https://launchpad.net/bugs/376207
<Ursinha> awesome
<Ursinha> we have one critical bug, being worked on
<Ursinha> so, unless anyone has anything to point, moving to the next section!
<Ursinha> good
<Ursinha> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> 2009-05-07 - Cherry pick r8906 to the scripts server and r122 of storm to lpnet* & edge*
<herb> 2009-05-09 - Cherry pick r4006 of bzr to the codehosting server and r123 of storm to lpnet* & edge*
<herb> 2009-05-09 - Cherry pick r8348, r8312 to the PPA server and r8376 to lpnet*
<herb> 2009-05-10 - mailman didn't have access the necessary access to the DB server, but it was only noticed after restarting for log rotation. mailing lists were unavailable for approximately 7 hours.
<herb> We still seem to be encountering bug #156453 and bug #118626, but the situation is much improved since the rollout.
<herb> flacoste: cprov requested a rollout of the current production tree to cesium. Apparently there was a critical fix that was included in while in RC, but we didn't re-roll to cesium. Can you (dis)approve that?
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,In progress] https://launchpad.net/bugs/156453
<ubottu> Launchpad bug 118626 in bzr-email "plugin documentation does not make interaction with checkouts clear" [Medium,Confirmed] https://launchpad.net/bugs/118626
<bigjools> herb: it's already approved by kiko
<flacoste> herb: i think kiko did? but otherwise, i can look into it
<flacoste> right
<herb> bigjools: missed it.  thanks
<Ursinha> any other questions to herb?
<Ursinha> okay
<Ursinha> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<rockstar> herb: I was under the impression that the loggerhead stuff was WAY better than "much improved"
<flacoste> stub sent it to the list
<herb> rockstar: we're still restarting a couple of times a week. which is much improved over a couple of times a day.
<herb> rockstar: order of magnitude.
<Ursinha> flacoste, to lp list? I can't seem to find it
<rockstar> herb: okay.  Is it memory restarts, or hanging restarts
<flacoste> The ex-master database (launchpad_prod on hackberry) is bloated and
<flacoste> started exceeding its free space map settings. Nothing really to worry
<flacoste> about - it might cause bloat to spiral but I suspect not in this case.
<flacoste> The losas can bounce it after shutting down the systems using it as a
<flacoste> slave, and I've suggested using it as the standalone replica for
<flacoste> read-only mode launchpad during the rollout because we then rebuild it
<rockstar> (The memory restarts shouldn't be happening anymore)
<flacoste> afterwards and it will be all nice and freshly packed.
<flacoste> Nothing major do do with database patches this cycle. rockstar's
<flacoste> bugbranch and specbranch column pruning needs to be cleared with Mark
<flacoste> still.
<Ursinha> thanks flacoste
<rockstar> flacoste: yeah, and there are other branches dependent on that one.
<herb> rockstar: The memory situation seems ok (ie. not death spiraling).  seems to be hangs at this point.
<herb> rockstar: we still see it ~1.5GB resident, but doesn't seem to grow beyond that.
<rockstar> herb: well, "death spiraling" to be is different than the memory issues.
<rockstar> herb: it's going to be *kinda* memory intensive just because of what it's serving.
<herb> rockstar: understood
<herb> rockstar: as I said, much improved. 1.2 - 1.5G is much better than 3.7G
<rockstar> herb: and we know the cause of the hangs, we just don't know how to fix it.
<herb> rockstar: good news, bad news, eh?
<rockstar> herb: yeah, something like that.
<Ursinha> okay. anyone else want to say something?
<Ursinha> 5
<Ursinha> 4
<Ursinha> 3
<Ursinha> 2
<Ursinha> 1
<Ursinha> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<Ursinha> #endmeeting
<MootBot> Meeting finished at 10:27.
<Ursinha> thanks all
<henninge> thanks Ursinha ;)
<Ursinha> henninge, :)
#launchpad-meeting 2010-05-19
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> hi, who is here today?
<gmb> me
<sinzui> me
<bac> for the launchpad reviewers meeting
<danilos> me
<gary_poster> me
<abentley> me
<gary_poster> (mars will probably be absent)
<bac> bigjools ping
<bac> EdwinGrubbs: ping
<BjornT> me
<EdwinGrubbs> me
<bigjools> \o
<leonardr> me
<adeuring> me
<noodles775> me
<bac> team leads would you ping your absent folks
<deryck> me
<gary_poster> (foundations is as here as we're going to get)
<bac> gary_poster: thanks
<henninge> me
<gary_poster> np
<bac> hi intellectronica, jelmer
<henninge> hi bac ;)
<jelmer> hi Brad
<bac> ok, let's get started and hopefully some stragglers will appear
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * Mentoring update
<bac>  * New topics
<bac>    * ec2 failures update - bac
<bac>    * Reviewer move to Friday? - bac
<bac>  * Peanut gallery
<bac> [topic] outstanding actions
<MootBot> New Topic:  outstanding actions
<bac> there are only two outstanding actions...both assigned to me.
<bac> but i'm batting .500
<bac>  * bac to write community reviewer and contributor policy and announce it on the list. -- done
<bac> i got that out, as promised, before leaving for UDS.
<bac> but remain stalled on:
<bac> * bac to define new doctest policy regarding what is "testable documentation".
<bac> i'll try to get to that next week
<bac> [topic]   * ec2 failures update - bac
<MootBot> New Topic:    * ec2 failures update - bac
<bac> actually, i was hoping to have mars give us an update but he's not here today
<gary_poster> I can summarize maybe
<bac> sinzui reported in our standup that work has been done but it is still very much a problem
<bac> yes, gary_poster?
<gary_poster> mars has been investigating the problems on ec2 test.  As a workaround, he has disabled the Windmill tests on ec2.  This is obviously very suboptimal, but considered to be less sub-optimal than ec2 break one out of four times, which I gather is the rough stat.
<gary_poster> He will continue to try to figure out and address the underlying cauase so he can reinstate the windmill tests in ec2
 * bac saw about 60% failure last time he tried
<gary_poster> note that windmill tests still run in buildbot
<gary_poster> so this is a testfix risk
<gary_poster> hopefully I didn't get anything wrong; that's what I understand.  done.
<bac> gary_poster: when tests hang, and the script kills itself after timing out, does it send a farewell email?  i think that would be a useful addition if not.
<gary_poster> bac, that is on mars' backlog, and in fact will be one of the next things he does to address, yes.
<bac> ok, great
<bac> gary_poster: when were the windmill tests disabled?
<gary_poster> bac, IIRC, Monday, with issues; issues were resolved yesterday
<bac> sinzui: did you see your tests disappear after that or before?
<sinzui> One disappeared yesterday afternoon
<gary_poster> sinzui, bac, we'll need to bring this up to mars.  Would you like me to take that action ite,?
<gary_poster> item
<bac> we should all keep an eye on our ec2 tests and report to mars instances of them disappearing.
<gary_poster> +1
<bac> gary_poster: that would be great.
<gary_poster> ok
<bac> [action] gary to follow up with mars on ec2 problems.
<MootBot> ACTION received:  gary to follow up with mars on ec2 problems.
<sinzui> gary_poster, I think my branch was within a few hours of the mailmanlayer shutoff. the issue may be fixed
<gary_poster> sinzui: ack wll pass along, thanks
<bac> [topic] * Reviewer move to Friday? - bac
<MootBot> New Topic:  * Reviewer move to Friday? - bac
<bac> our pool of reviewers has been pretty hard hit lately with personel changes
<bac> https://dev.launchpad.net/ReviewerSchedule
<bac> right now, on fridays we only have adeuring working
<bac> would gmb or henninge entertain the idea of moving to friday?
<gmb> bac, I believe adeuring is a Friday reviewer; I wonder if it's the best thing for hte bugs team to lose two devs on the same day... Not sure it matters though.
<adeuring> not that I would mind sharing reviews with gmb or henninge, but I think if we have somebody in a US timezone would be better
<bac> adeuring: yes it would be better
<bac> adeuring: but of the active reviewers in the americas we're spread pretty thin
<adeuring> right
<gmb> bac, I'm happy to do it if deryck's okay with the change.
<bac> i could move to friday but that leaves an americas hole on tuesday
<henninge> I don't mind moving to Fridays
<deryck> I don't know if I want gmb and adeuring sidelined fridays
<bac> deryck: ok.  henninge do you mind moving again?
<henninge> bac: no problem at all
<henninge> but, as was said, the problem is America
 * henninge wonders if he should move west ...
<bac> henninge: let's not bring politics into the meeting
<henninge> lol
<henninge> But I was talking about the whole continent anyway ...
<bac> henninge: why don't you try friday and if seems we have a problem i'll then switch
<henninge> It's in the way of any girl that wants to sail around the world...
<bac> [action] henninge to move to friday review EU review slot
<MootBot> ACTION received:  henninge to move to friday review EU review slot
<intellectronica> bac: on the same subject, note that there's a slot freein on monday EU. when i'm gone there will be no reviewer until abentley gets workin, and judging by the last few mondays there's a lot of activity around that time.
<bac> intellectronica: i know.  i was hoping you'd change your mind before then.  :)
<henninge> intellectronica: where are you going, what did I miss?
<bac> intellectronica: you can always help out on mondays as a community reviewer!
<intellectronica> wow, i managed to omit all those Gs. i'm not lolcat speaking, it was as accident
<intellectronica> :)
<bac> intellectronica: what is the date for you leaving?
<intellectronica> henninge: i'm leaving launchpad at the end of next week.
<henninge> intellectronica: oh, too bad :(
<henninge> ;)
<bac> in light of that, perhaps it would make more sense for henninge to move to eu-monday and i move to friday
<intellectronica> henninge: what can i do, all those monday review shifts finally got to me
<henninge> :)
<bac> henninge: let's talk about it off-line.
<henninge> bac: ok
<bac> [topic] peanut gallery
<MootBot> New Topic:  peanut gallery
<bac> any new topics?
<sinzui> orphaned commits
<sinzui> This is the what we have so far: https://wiki.canonical.com/Launchpad/QATeam/OrphanedCommits/10.05-devel
<sinzui> Ursinha, noted that this class of landing was not tracked with bug tags last release
<bac> hard to have a bug tag with no bug.
<gary_poster> FWIW, If we talk about this here, I'd be +1 on this simply leading to someone taking an action item to raise this on the mailing list
<sinzui> In the examples I saw related to the registry team they were contributor branches that were not linked to bugs
 * mars is guilty of submitting build system cleanups without bugs.
<sinzui> Do we want contributor work to always have a link to a bug/spec
<bac> i think reviewers should be on the look out for any MP that isn't linked to a bug.  not saying it isn't sometimes appropriate but it should raise a flag.
<intellectronica> sinzui: with contributor work it's even more important, because you want to help contributors plan and track the work before they start
<bac> intellectronica: agreed.  so sinzui's suggestion is a good one, IMO.
<sinzui> Or in my case, remove part of the branch a week later because the feature is causing errors
<bac> but only 2 of the 10.05 orphans are from community
<sinzui> yes, there is another issue, but in the lp engineer case, flacoste assumes these are on the kanban board
<bac> sinzui: well, that does help.  but if we're going to track qa with bug tags then it would make sense to *require* a bug or we lose all QA testing...unless we employ a separate tracking mechanism.
<BjornT> bac: if all we want is to track qa, filing a bug automatically sounds like a good idea
<bac> BjornT: at what point?
 * gary_poster idly thinks of a flag for branches that says "addresses" rather than "fixes"
<sinzui> The tags are hard to visualise at the moment since the page is missing: http://people.canonical.com/~lpqateam/test-plan-report-10.05.html
<BjornT> bac: the script that scans commits and add qa tags probably
<gary_poster> where addresses means that it is an incremental step towards a bug
<gary_poster> but does not actually resolve a bug
 * gary_poster suspects this is a can of worms
<henninge> BjornT: so it should create a bug if none is linked to the commit?
<BjornT> henninge: if all we want is to track QA, yes, why not?
<mars> gary_poster, that's why I'm not going to touch it :)
<gary_poster> :-)
<bac> sinzui: would you take an item to talk to QA and then make a proposal on the list, taking into account BjornT's suggestion?
<henninge> BjornT: sounds like a good idea. Let's see if Ursinha likes it, too.
<sinzui> yes
<bac> thanks curtis
<bac> [action] sinzui to talk to QA about our QA tracking problem and create a proposal on the mailing list
<MootBot> ACTION received:  sinzui to talk to QA about our QA tracking problem and create a proposal on the mailing list
<bac> any other topic?
<bac> 3
<bac> 2
<bac> 1
<bac> thanks for coming everyone.
<bac> #endmeeting
<MootBot> Meeting finished at 09:37.
<mars> thanks bac
<henninge> so, intellectronica, which team won you over and how? ;-)
<intellectronica> henninge: the summer won me over. in a couple of weeks i'll be out of employment and ready to rock'n'roll :D
<henninge> intellectronica: oh, because you said "leaving launchpad", I thought it was within the company.
<henninge> intellectronica: so you have nothing new lined up yet?
<intellectronica> henninge: nothing at all (other than some fun-related plans)
<henninge> intellectronica: well, have fun, then! ;-D
<intellectronica> henninge: thanks!
 * Ursinha reads the backlog
<Ursinha> <BjornT> bac: if all we want is to track qa, filing a bug automatically sounds like a good idea
<Ursinha> we dropped out that idea because some of the commits aren't really bugs
<Ursinha> henninge, ^
<henninge> BjornT: ^ ;)
<henninge> Ursinha: I think that is the  point.
<henninge> Ursinha: To track even those commits that aren't really bugs.
<Ursinha> henninge, that's how the script would initially work, but I dropped the idea after chatting with francis
<Ursinha> henninge, and why would we need that?
<henninge> Ursinha: we were talking about orphaned commits.
<Ursinha> henninge, I see now... but the point is that the orphaned commits aren't all the commits the don't mention bugs, but only those which should and don't
<Ursinha> s/the don't/that dont/
<Ursinha> henninge, I guess that not a lot of those supposedly orphaned commits are really orphaned, maybe we could fix that by adding the bug tag to the commit message?
<Ursinha> henninge, making that a pqm requirement, maybe
<henninge> Ursinha: I am not sure they have bugs. It did not sound like that.
<Ursinha> henninge, and they should?
 * henninge has little own experience, he always files bugs...
<Ursinha> henninge, that's why I love you :P
 * henninge blushes
<henninge> Ursinha: well, jtv trained me that way ...
<Ursinha> henninge, I love him too :)
<henninge> Ursinha: The question was "Should all commits have a bug so they are qa'ble".
<Ursinha> henninge, my personal opinion is no
<henninge> I was not aware of the definition for orphaned commits that you just gave.
<henninge> "should have bug bug don't"
<Ursinha> henninge, the idea of having a bug attached to a commit is to track the qa you have to do on it
<henninge> Ursinha: you are the authority on QA here, so if that is your opinion, we are fine, I guess ... ;)
<henninge> on the bug, you mean
<Ursinha> of course having a bug for real fixes is needed to track problems and future reference
<Ursinha> but now we really need to care about fixes that need qa, those need bugs
<henninge> so the rule should be "If the fix will need qa, attach a bug. If it doesn't a bug is optional?"
<henninge> Ursinha: don't all fixes need QA?
<Ursinha> henninge, I thought so, but it turns out some are just adjustments that not necessarily can be qaed
<henninge> Ursinha: I'll put that on the agenda for next week's meeting.
<Ursinha> henninge, well, speaking roughly in practical qa terms, yes, but I'd like to have bugs to all problems we have, even the ones that result in commits we can't test
<Ursinha> but that's my wish :)
<Ursinha> or the ones that don't even need commits to lp tree to be fixed :)
<bac> thumper, rockstar: up for a reviewers meeting?
<rockstar> bac, havin' our standup right now.
<thumper> I might have to skip it this week
<bac> rockstar: why do you schedule the standup during our meeting time?  :)
<bac> thumper: ok.  not much said but talk about broken ec2  and rearranging of OCR schedules due to all the people moving around.
<bac> next week...
#launchpad-meeting 2010-05-20
<matsubara> #startmeeting
<MootBot> Meeting started at 11:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<gary_poster> me
<matsubara> Chex_, gary_poster, rockstar, bigjools, danilos, sinzui, allenap, Ursinha: hi
<bigjools> \o
<Ursinha> hi me
<Ursinha> me
<sinzui> me
<Chex_> me
<danilos> me
 * rockstar  
<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> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>  * Ursinha to chase adeuring abour calculate_bug_heat failing script
<matsubara>  * DONE: Ursinha to file a bug for OOPS-1593EC1021, related to bug 523346
<matsubara>    * filed bug 580181
<matsubara>  * rockstar to look into upgrade_branches failures
<matsubara>  * danilos to take care of CPing bug 578331 fix
<matsubara>  * DONE: Ursinha to send email to stub about the dba report of the week
<ubot5> Bug 523346 on http://launchpad.net/bugs/523346 is private
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1593EC1021
<ubot5> Launchpad bug 580181 in Soyuz " DistributionSourcePackageRelease page still oopsing with NotOneError (affected: 1, heat: 6)" [High,Triaged] https://launchpad.net/bugs/580181
<ubot5> Launchpad bug 578331 in Launchpad Translations "exporting to bzr seems broken since a few days (affected: 2, heat: 20)" [High,Fix committed] https://launchpad.net/bugs/578331
<danilos> done
<matsubara> thanks danilos
<matsubara> rockstar, any news about the upgrade_branches failures?
<Ursinha> matsubara, all done
<rockstar> Done.  I don't think "failure" was the right word.  It wasn't failing, just running for a while.
<matsubara> Ursinha, any news about the calculate_bug_heat failure?
<danilos> actually, it took a while because we had to fix the branches as well
<Ursinha> matsubara, there are replies in lp list about it
<rockstar> Hey folks, the power company is about to cut power to the neighborhood for about an hour.  I can re-locate, but that relocation should take 10 minutes probably during this meeting.
<Ursinha> matsubara, people are taking care of
<matsubara> thanks danilos, Ursinha and rockstar
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> I have 5 bugs for registry,
<matsubara> I have 5 bugs for Registry, Bugs and Code
<matsubara> first, thanks sinzui for duping 553378
<sinzui> matsubara, I reported a bug in oops-tools per flacoste to ignore injection attacks by bots/spammers
<matsubara> sinzui, can you also take a look at https://bugs.edge.launchpad.net/launchpad-registry/+bug/583390 ?
<ubot5> Launchpad bug 583390 in Launchpad Registry "AssertionError deactivating an account (affected: 1, heat: 6)" [Low,Triaged]
<matsubara> sinzui, right. I saw that one. it's in my backlog, not sure when I'll be able to fix it.
<matsubara> sinzui, IIRC the oops I reported on 583378 wouldn't be filtered out from the oops summary
<sinzui> The fix for % is easy, but the unicode injection attacks are not easy
<matsubara> [action] matsubara to chase someone from Bugs about https://bugs.edge.launchpad.net/malone/+bug/583385
<MootBot> ACTION received:  matsubara to chase someone from Bugs about https://bugs.edge.launchpad.net/malone/+bug/583385
<ubot5> Launchpad bug 583385 in Launchpad Bugs "OOPS on +bugs-text page (affected: 1, heat: 6)" [Undecided,New]
<matsubara> rockstar, can you take a look and triage accordingly: https://bugs.edge.launchpad.net/launchpad-code/+bug/583392 and https://bugs.edge.launchpad.net/launchpad-code/+bug/583395, please?
<ubot5> Launchpad bug 583392 in Launchpad Bazaar Integration "IntegrityError raised setting a branch for a project. (affected: 1, heat: 6)" [Undecided,New]
<rockstar> matsubara, it's an oops, so the answer is always "High"
<matsubara> for the failing scripts of the week, we have only the productreleasefinder. sinzui?
<sinzui> That is not failing, it is running late. It ran fine for 4 weeks. I think some other script is running long this week
 * rockstar relocates
<matsubara> for the critical bugs, we have only 2, one fix committed and another one in progress.
<matsubara> sinzui, ok. thanks for the info. I take you're keeping an eye on that one in case it's something serious?
<matsubara> thanks rockstar
<sinzui> I am actually
<matsubara> thanks sinzui
<matsubara> let's move on
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Chex> hello everyone, a short report this week:
<Chex>  - LP incidents of note:
<Chex>         : Apr-17: CodeImport: bunches of 'svn updates' in a hung state on pear;
<Chex>         : Apr-16-19: Codebrowse: hanging once per day, but with lots of memory/swap issues now.
<Chex>         : Apr-13: CP 9343 to codehost/crowberry
<Chex> its the ongoing issues with codebrowse and codeimport, but the swapping on codebrowse seems to be new.
<Chex> any questions/comments on these?
<matsubara> Chex, are there people from Code looking at those issues?
<matsubara> if not, could you please coordinate with them to have those addressed please
<Chex> matsubara: yes there are open bugs on these, and several crash-traces have been looked at, I believe they are still ongoing
<matsubara> ok then. thanks Chex
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> Stuart sent the DBA report for the last weeks.
<matsubara> [TOPIC] * QA stats of the week
<MootBot> New Topic:  * QA stats of the week
<matsubara> and of course, I'm not ready for this section of the meeting
<matsubara> :-/
<matsubara> script is taking forever to complete. I'll update the stats section in the wiki page
<matsubara> sorry about that
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> no new proposed items
<matsubara> and I guess that's all for today. anything else before I close?
<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:24.
