#launchpad-meeting 2008-06-16
<SynthroidMan> http://synthroid.co.uk/
#launchpad-meeting 2008-06-17
 * mwhudson is here on time today, so of course noone else is
<sinzu3> I am
<sinzui> and so am I
<jml> I am
<jml> ish
<jml> but barry is not, which is kind of critical :)
<mwhudson> jml: are you at the sprint today?
<jml> mwhudson: no. I mentioned it on the call
<jml> mwhudson: but maybe you dropped out for that point
<mwhudson> it's certainly possible
<jml> I'm getting a filing cabinet delivered today, and as such need to be at home.
<mwhudson> oh well, no meeting today it seems
 * mwhudson wanders off to do the chores he didn't do last night because he was busy hacking loggerhead
#launchpad-meeting 2008-06-18
<thumper> barry: were we going to have that meeting?
<barry> thumper: i think we should
 * thumper nods
<barry> thumper: 2 minutes
<thumper> ok
<mwhudson> hello
<barry> #startmeeting
<MootBot> Meeting started at 21:03. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everybody and welcome to this week's asiapac reviewers meeting
<jml> hello
<barry> i see my clock is off by 3 minutes?
<barry> who's here today
<mwhudson> i am here
<jml> I am
<barry> thumper is too i know
<thumper> me
<barry> i can't update the meeting page because i guess the machine updates are still running
<barry> apologies for last night btw
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>   * Module alternatives - do we really want them?
<barry> shall we go ahead and do our regular time next week?
<thumper> yep
<jamesh> okay
<barry> cool
<barry>  * Action items
<mwhudson> yes please
<barry> [TOPIC]  * Action items
<MootBot> New Topic:   * Action items
<barry> nothing outstanding
<barry>  * Queue status
<barry> [TOPIC]  * Queue status
<MootBot> New Topic:   * Queue status
<barry> does it seem like we have a bajillion branches that need reviewed this cycle?
<jml> yes.
 * jml hasn't checked his queue today.
<thumper> gee, I wonder why?
<mwhudson> i don't know that it's going to be any more intense than usual for week 3 though
<spiv> It seems like the bzr team have a bajillion reviews to atm too :)
<mwhudson> i thought that was just one humungous review :)
<barry> i'm a little worried that ocrs are getting overloaded or burned out.  do any of y'all feel that way?
<thumper> rocs?
<thumper> orcs?
<mwhudson> it's much easier for us 'round here
<jml> barry: I don't.
<barry> on call reviewers :)
<thumper> ah
<jml> barry: there's a minor problem where I get requests for reviews on Friday afternoons
<jml> barry: that's resulted in a couple of Europeans having to wait 24hrs between review cycles.
<barry> jml: you get them while on call or in your queue?
<thumper> jml: is there someone to pass the reviews onto?
<jml> barry: while on call.
<jml> thumper: there wasn't this time.
<thumper> who is the european on on Friday?
<jml> at other times in the cycle I probably would have just said no :)
<barry> david murphy
<barry> then in the us it's superman, er, sinzui
<jml> barry: where does the schedule live?
<barry> https://launchpad.canonical.com/OnCallReviewers
<barry> i still would love to fill wednesday more
<barry> but we lost statik as a reviewer, which is too bad, because he was good
<barry> otoh, bigjools is going to graduate
<jml> cool.
<mwhudson> how many non-reviewers do we have currently?
<barry> mwhudson: i was just looking that up
<thumper> I'd like to get abentley onto the team shortly
<barry> except i can't get into the directory :(
<barry> thumper: good idea
<mwhudson> aaron, mars, leonard ?
<thumper> I'll follow it up with him first
<barry> thumper: sounds good
<thumper> to make sure he is up for taking it on now
<thumper> (or after 2.0)
 * mars stirs
<barry> mwhudson: those are the next logical choices i think
<mwhudson> oh, al-maisan isn't a review either i guess
<mwhudson> reviewer
<thumper> and rockstar
<thumper> rockstar is still very new though
<barry> so is al-maisan?  i haven't seen many of either's branches.  have you guys seen any of them?
<jml> al-maisan is still pretty new
<jml> I just reviewed one of his branches.
<mwhudson> i doubt al-maisan or rockstar are ready yet
 * jml agrees.
<rockstar> Yes, I am not ready...
<mwhudson> but yeah, i guess we should bully the three i first mentioned i guess
<barry> [TOPIC] mentoring update :)
<MootBot> New Topic:  mentoring update :)
<barry> mwhudson: all we need to do is find mentors for them
<barry> with bigjools graduating, i can take someone else on
<barry> al-maisan is euro?  rockstar, you're us right?
<jml> barry: al-maisan is in .de
<rockstar> Yup, US
<barry> i know mars is ca, eastern
<barry> jml: cool
<barry> leonard is us eastern too
<jml> barry: abentley is .ca -- my geography doesn't extend that far north though
<barry> :)
<mwhudson> i _guess_ one of us could do one of the new guys, but the difference is a bit much
<jml> yeah.
<mwhudson> (until the dst thing happens again)
<jml> better to get someone from atlantis
<barry> yeah it's tough when there's so little overlap
<jml> I mean AMEU
<barry> jml: unless you can convince someone to move!
<jml> barry: I would like Australia to move :)
<barry> :-D
<spiv> I'm not sure what the real estate market in Atlantis is like...
<barry> spiv: you can get great stuff cheap these days
 * thumper seemed to miss 5 mintutes
<mwhudson> jml: http://www.satirewire.com/news/jan02/australia.shtml
<spiv> barry: I'd worry about home owners going under.
<barry> spiv: you haven't heard about our real-estate crash?  it's only going to bring down the entire world economy
<jml> mwhudson: seen it :)
<mwhudson> jml: good :)
<jamesh> maybe we need some reviewers in hawaii
<barry> mwhudson: :)
<barry> it's a great time to /buy/ a house, a horrible time to sell one
<barry> anyway, all good suggestions, thanks
<thumper> I checked out the cost of a house in hawaii
<thumper> it isn't cheap
 * spiv would want to bouy a house if he lived in Atlantis
<thumper> we seem to be somewhat off topic
<mwhudson> :)
<jamesh> spiv: there are people who will sell one to you
<barry> [TOPIC]  * Review process
<MootBot> New Topic:   * Review process
<barry>   * Module alternatives - do we really want them?
<jml> barry: what's a module alternative?
<barry> lets see if i can swap this one in
<thumper> what is this exactly?
<barry> intellectronica brought this up
<barry> whether we want to wrap imports of say, from cFoo import Foo in try/excepts
<barry> or just do the import
<barry> and expect them to work
<jamesh> just import
<mwhudson> oh just import
 * jml seconds jamesh
<thumper> just import
<jamesh> have you found a Python installation without cStringIO or cPickle?
<mwhudson> we control our environment
<spiv> We know what dependencies we have, don't we?  So just import.
<jamesh> and what mwhudson said
<spiv> s/have/have installed/
<barry> that's basically what we decided.  i think there was some question about forward-proofing etree, elementree and the like
<mwhudson> mmm
<jamesh> the one place I think a try/except might be useful is for module name changes going 2.4 -> 2.5
<thumper> mwhudson: wasn't there something that you wanted to bring up at the review meeting?
<jamesh> e.g. ElementTree
<mwhudson> thumper: it's on the agenda :)
 * jamesh is too slow
<barry> jamesh: some talk about having a canonical.alternatives package for hiding the 2.4/2.5 differences
<thumper> mwhudson: I didn't see it on the agenda
<mwhudson> well i added it
<barry> anyway, we're all agreed, just import it
<barry> and upgrade to 2.5 when we do :)
<barry>  * (mwhudson) What are page tests for?
<barry> mwhudson: the floor is yours
<mwhudson> oh, it's just a proposed item
<mwhudson> this came from some conversations i had with jml and thumper
<mwhudson> basically, writing and maintaining pagetests is a pain
<mwhudson> and i think we are a bit muddled as a team as to what the purpose of a page test is
<mwhudson> some of them are 'customer stories'
<mwhudson> and some of it is just testing that the templates work
<mwhudson> (and most are some mixture of both)
<mwhudson> so i'd like to encourage a wider conversation on the topic
<spiv> My first reaction is that both are useful, but keeping them separate would be a good idea.
<thumper> some try to do exhaustive testing of alternatives
<mwhudson> i guess i should mail the list about this, but let's have a short argument here first :)
<thumper> I'd prefer to see template testing move to unitests
<barry> spiv: that's my first reaction too
<thumper> customer stories are fine
<jml> thumper: +1
<jml> spiv: +1
<mwhudson> if they are customer tests, we should consider not running them on every landing
<barry> one question i've often had is how much should we be sneaking around the web u/i in a pagetest?
<spiv> Basically: for tests the key question iswhat is the intent of the test, and for docs the key question is what is the audience of the document.
<thumper> mwhudson: not sure about that
<spiv> (And for doctests, there's also the question of "is this a doc or a test?")
<barry> thumper: i agree, i'd hate to stop running some of our important tests
<spiv> I think being clear about the answers to those will help us figure out how to organise our pagetests.
<jamesh> mwhudson: for a while, it wasn't possible to do testbrowser stuff outside of the pagetests
<barry> spiv: very good point.  i love doctests for everything, but some are documentation and some are not
<mwhudson> thumper: this pre-supposes that all the important things are tested in non customer tests
<thumper> I think that trying to do exhaustive tests of alternatives should never be in a doctest or pagetest
<jamesh> due to some required setup/teardown being done in the FunctionalDocFileSUite
<mwhudson> jamesh: oh, interesting
<jamesh> that is fixed now though, so there isn't any technical reason not to do testbrowser in unittest code now
<spiv> barry: I *will* persuade you that doctests for everything is bad at some point, I promise :)
<mwhudson> jamesh: i have written unittests that use testbrowser :)
<barry> spiv: :)
<thumper> spiv: I'm sure doctests are good somewhere
<jamesh> mwhudson: and that worked because I moved the test setup to the layers
<mwhudson> (it's still a pain because you have to log in and out all over)
<mwhudson> jamesh: i shall buy you a beer for that at some point
<thumper> mwhudson: what about setting the unitest in the pagetestlayer?
<barry> thumper: i have this theory that we can use the doctest format for everything (and that it's better than python tests)
<thumper> barry: ew, NO!
<mwhudson> this is a separate punch-up
<mwhudson> :)
<barry> yeah, let's not get distracted :)
<jamesh> these days, there isn't any special setup done for doc tests, other than default globals, iirc
<barry> jamesh: right, and we're trying to discourage magical globals in doctests anyway
<mars> barry, +1 :)
<jamesh> yep
<thumper> are we?
<thumper> I just added one
 * mwhudson shall have to buy xUnit Test Patterns for everyone on the launchpad team, it seems
<barry> i've had exactly one case where i think it's justified, but other than that, the imports are good to put in the doctest!
<thumper> at least it makes it clear where things are coming from
<mwhudson> so, should i mail the launchpad list about the page test thing?
<spiv> mwhudson: ideally with a short proposal about what to do about it
<jml> mwhudson: I think that's a good idea.
<barry> thumper: yeah, i hate having to go hunting for the harness that sets up a doctest just to figure out what some global actually is
<spiv> mwhudson: just to try to limit the inevitable bike-shedding a little
<mwhudson> and say that launchpad/pagetests should be stories
<barry> mwhudson: +1, spiv +1
<mwhudson> and that doc/ should be documentation
<spiv> mwhudson: +1
<mwhudson> and tests (whether .py or .txt) should be in a tests directory?
<barry> mwhudson: +1
<spiv> mwhudson: +1 +1 +1
<mwhudson> ok
<barry> and can we for gawd's sake please do something about tests, testing, and ftests?
<spiv> Rename ftests to f'ing tests?
<mwhudson> well, testing is for scaffolding
<jml> barry: tests & testing is a sensible split
<jamesh> stuff in ftests can go to tests
<mwhudson> ddaa tried to land a branch that moved everything in ftests into tests
<barry> jml: yes, maybe just get rid of ftests.  i would be so much happier
<thumper> testing is infrastructure
<jamesh> the tests / testing split is good
<jml> jamesh: sometimes it needs to go to testing :)
<spiv> jamesh: +1
<jamesh> jml: right
<barry> jamesh: +1
<mwhudson> but it's a conflict nightmare
<mwhudson> ok, i can add this to my mail too :)
<thumper> each team should move its own tests
<thumper> from ftests to tests in the appropriate place
 * barry has a secret plan for montreal :)
<thumper> we file a bug
<thumper> create tasks for each team
<thumper> and JFDI!
<barry> thumper: right!  i want a special pqm tag for that
<thumper> :)
<thumper> barry: why a pqm tag?
<jml> thumper: I think you'll find that one team has already done it :P
<thumper> jml: not quite
<barry> thumper: well, when i want to jf land a branch :)
<thumper> jml: there are some older tests still in c.l.ftests
<spiv> Some people claim "Jedi" as their religion.  thumper's religion is "JFDI".
<jml> thumper: let us continue this team-specific discussion outside of the meeting.
<barry> 2007's motto was "canonical fuck yeah!".  2008's should be JFDI
<thumper> barry: can you add a mootbot task for that?
<barry> [ACTION] mwhudson to start discussion on page test purpose
<MootBot> ACTION received:  mwhudson to start discussion on page test purpose
<thumper> barry: I was meaning a bug for ftests -> tests
<barry> [ACTION] thumper to submit a bug for moving ftests contents to tests
<MootBot> ACTION received:  thumper to submit a bug for moving ftests contents to tests
<barry> anything else on this topic mwhudson?
<mwhudson> not for today i think
<mwhudson> i can hear jml's stomach rumbling from here :)
<barry> :)
<jml> :D
<barry> okay, one quick last one
<jml> The "D" represents my gaping maw.
<barry>  * (bigjools) On-call reviewers to remind devs to be available during the review.
<jml> that's a good idea.
<mwhudson> +1
<jml> I'll do that in future.
<barry> bigjools brought up to me that some people are using on-call requests to jump ahead of the review queue
<jamesh> we've got way too much obsolete test infrastructure still in tree
<barry> i.e. they request an on-call review then disappear
<mwhudson> jamesh: yes
<jml> barry: yeah, this has happened to me.
<barry> i told bigjools that if that happens, you are allowed to reject the ocr request and move on to someone who is present
<barry> the whole point of ocr is to have a dialog with the dev
<mwhudson> i think i've done this
<spiv> This makes good sense to me.
<mwhudson> at least, if i have two reviews to do and the developer is there for one of them, he gets done first
<barry> anybody disagree?
<thumper> nope
<mwhudson> nope
<barry> great.  that's it for me.  shall we end 2 minutes early and let jml get some food?
<jml> I think we should discuss it first :)
<barry> jml: but only for 1 more minute :)
<barry> #endmeeting
<MootBot> Meeting finished at 21:47.
<barry> thanks everyone!
<jml> barry: thanks!
<mwhudson> thanks barry
<spiv> barry: thanks
<barry> #startmeeting
<MootBot> Meeting started at 09:03. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everybody.  welcome to this week's ameu reviewers meeting
<barry> who's here today?
<sinzui> me
<EdwinGrubbs> me
<gmb> me
<bigjools> me
<intellectronica> me
<bac> me
<barry> danilos, BjornT ping
<barry> flacoste: ping
<danilos> me
<flacoste> me
<BjornT> me
<danilos> barry: thanks
<allenap> me
<barry> salgado: ping
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<salgado> me
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>    * bye to statik
<barry>    * bigjools graduates
<barry>    * new recruits?  (leonardr, abentley, mars)
<barry>  * Review process
<barry>    * (bigjools) On-call reviewers to remind devs to be available during the review.
<barry>    * (gmb) Wrapping long argument lists: What's the agreed style?
<barry>    * (mwhudson) What are page tests for?
<barry>    * thumper moving ftests contents to tests
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
 * barry kicks mootbot
<jtv> me
<statik> me
<barry> jtv: hi!  statik hi!
<jtv> barry, hi!
<barry> next week, same time and place?  anybody know they will be sprinting or away?
<barry> cool
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * intellectronica to file bug on lint issue regarding elementtree import
<intellectronica> sorry, i didn't. let's carry this on
<barry> intellectronica: np
<barry>  * mwhudson to start discussion on page test purpose
<barry> i will proxy mwhudson :)
<barry> he's going to start a ml thread on the purpose of page tests.  more in a moment
<barry>  * thumper to submit a bug for moving ftests contents to tests
<barry> more on this in a bit
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
<barry> any comments?  i was freaking out on monday, but i've calmed down by now.  thanks everyone for cranking away on reviews!
<sinzui> Stub has reviewed my two branches now; he has not updated the statuses
<barry> sinzui: are they merge-approved?
<sinzui> yes
<barry> sinzui: cool. i'll ignore those and you can just remove them when they land
<barry> my branch that kiko reviewed is still trying to land
 * barry won't even mention testsuite2 :)
<barry> anything else on the queue?
<sinzui> We seem to have extra missing branches this week
<barry> sinzui: missing where?
<salgado> yeah, I'm nagging stub about my oauth-context branch, which has a DB patch
<sinzui> barry: The red branches are missing. It implies they were removed from the repo, or renamed
<barry> sinzui: yeah, people are not updating PR
<sinzui> gmb and intellectronica have missing branches
<sinzui> and schwuk
<barry> everyone, remind your reviewees to clean up PR when their branch lands!
<bigjools> amen to that
 * bigjools cleaned 4 of other people's out this morning
<intellectronica> sinzui: oh right, i cleaned my repo but not PR, i guess. i'll sort it out
<barry> bigjools: yes, feel free to clean out any that you see
 * barry is a culprit too
<bigjools> I don't like doing it though, it makes devs lazy!
<barry> bigjools: hmm, maybe refuse to review any new branches until they clean out their old ones :)
<bigjools> lol
<barry> anyway...
<barry> [TOPIC]  * Mentoring update
<MootBot> New Topic:   * Mentoring update
<gmb> Or have PQM check for red branches and rejecting anything until they're gone...
<barry> so first, we say goodbye to statik who is moving off the lp team and won't be accepting any more reviews.  i was tempted to go down to florida to camp on his doorstep until he changed his mind but it's a long train trip
<barry> statik: thanks and good luck!  you're welcome to come do reviews any time you're bored :)
<statik> thanks!
<barry> next up: bigjools graduates.  congratulations bigjools!
<jtv> congrats bigjools!
 * flacoste cheers bigjools
<intellectronica> congrats bigjools!
<bac> hurrah
 * bigjools takes a bow
<gmb> Hurrah!
<bigjools> thanks guys
<barry> i will send an official email after this meeting
<bigjools> Barry is a great mentor - thanks to him also
<barry> remember, give all your hard branches to bigjools now :)
<bigjools> oof
<barry> :)
<barry> bigjools: thanks
<flacoste> but has it easy, being a soyuz developer
 * bigjools considers retracting the last statement :)
<jtv> too late
<flacoste> the worst branch are his :-p
<barry> flacoste: no kidding!
<bigjools> flacoste: lol
<barry> i think we can accept a few more recruits now.  i'm certainly happy to mentor again.  i think the next three potential candiates are leonardr, abentley, and mars
<barry> i talked to thumper and i'm thinking about mentoring abentley
<barry> we need mentors if we're going to accept anybody else, though i propose we do not accept until after 2.0
<barry> so if you would like to volunteer to mentor leonardr or mars, please send me an email
<intellectronica> i'm happy to mentor again, after 2.0
<barry> intellectronica: awesome
<gmb> I'll be happy to do the same
<barry> gmb: great, thanks!
<barry> btw, we mentioned rockstar and al-maisan but we want to give those guys a bit more time dev'ing for now
<barry> [TOPIC]  * Review process
<MootBot> New Topic:   * Review process
<barry>    * (bigjools) On-call reviewers to remind devs to be available during the review.
<barry> we talked about this last week...
<bigjools> ok
<bigjools> I've noticed a few instances where developers are not available during on call reviews
<barry> but i just wanted to mention that asiapac was all for the idea that it's okay to reject an ocr if the dev disappears
<bigjools> the primary reason for OCR is to speed up reviews
<intellectronica> well, if they're not available then they're not available, what can you do? just postpone the review for later
<bigjools> not as a means to jump the general queue
<bigjools> intellectronica: put them in the GQ
<barry> bigjools: exactly
<intellectronica> bigjools: yeah, exactly
<jtv> It's a bit annoying when you're in Asia though
<bigjools> jtv: we could prioritse people who find it hard to be around at the same time as OCRs
<barry> jtv: who is affected by that?
<bigjools> anyway - we should remind devs, when they ask for a review, to be around, otherwise refuse the review
<jtv> Agreedâif you ask for it, you ask for it.
<barry> the one hitch is when someone asks for  review and you can't get to it for several hours because your dance card is full.  they might disappear by the time you're free
<bac> this tends to happen to me when europeans ask for reviews in my early afternoon.  often by the time i get to the review it's pretty late where they are.  happened last night.
<barry> this has happened to me when euros get bumped to the end of my list
<barry> bac: yep
<bigjools> if you're not sure you can get to it, I don't think it should be accepted
<barry> i think it's okay to reshuffle your queue
<bigjools> maybe we need to consider doubling up reviewers on some shifts?
<barry> i.e. give some priority to those east of you if it helps speed the review
<bigjools> like some already do
<bac> and, if you're approaching the end of your work day, don't ask someone just b/c they have a few hours left
<barry> bac: good pont
<bac> 'you" being a dev, not a reviewer
<barry> er, point
<barry> bigjools: i'm not sure we have enough coverage as it is atm
<bigjools> when I've been on call on Monday mornings it's quite thin most of the time, I could move to a different day
<barry> i.e. wednesday we only have intellectronica and allenap in euro time
<intellectronica> only?
<sinzui> We need to send rockstar to NZ once he is a reviewer to take the Wednesday slot
<barry> intellectronica: not to disparage you guys!  you all do great, but we have no america coverage on wednesdays
<intellectronica> ah, of course. well, i think we'll have to relocate someone
<barry> btw, the asiapacsters don't feel to bad about the current situation, i.e. they are neither overloaded nor seeing their branches languish
<bigjools> does this mean we need more Americas reviewers?
<barry> bigjools: leonardr, abentley and mars are all here so getting them on board will improve coverage eventually
<intellectronica> if we get leonardr on board it will help, though, so let's try to convince him to start after 2.0
<bigjools> rockin'
<barry> intellectronica: +1
<barry> bigjools: we have good euro coverage, so if you want to stay on monday that's cool.  it's nice to have a little overlap in our days.  otherwise, definitely feel free to pick a slot later in the week and double up with someone
<salgado> we also have EdwinGrubbs, who's being mentored by myself
<barry> bigjools: maybe friday so sinzui's load gets lightened.  i always feel bad that sinzui reviews into his weekend :)
<bigjools> I don't mind either way.  I'll stay where I am for now and we can check which periods are most busy
<salgado> once he graduates we'll have one more reviewer in america
<barry> salgado: good point!
<bigjools> barry: yeah, there's nobody on Friday mornings
<barry> bigjools: sounds good
<bigjools> Europe time that is
<sinzui> barry: You do not. I'm taking the load off of you
<flacoste> barry: well, if doesn't review into the week-end, he'll code, which increase the review load so...
<barry> :)
 * sinzui looks forward to this Friday with PQM in top form to screw developers whose nicks are not gmb
<barry> anyway, moving on...
<gmb> *mumblemumble*
<barry>    * (gmb) Wrapping long argument lists: What's the agreed style?
<gmb> Right.
<gmb> So, my question is pretty simple.
<gmb> When we come across a method definition with a really long list of arguments, how do we want it wrapped.
<sinzui> We agree to wrap two ways as we see fit
<gmb> I've seen three styles:
<gmb> def spam(eggs, ham, jam, lamb, spam
<gmb>     foo, bar):
<gmb> def foo(
<gmb>     here, is, a, nother, long, list):
<gmb> or
<gmb> def bar(
<gmb>     this,
<gmb>     looks,
<gmb>     really,
<gmb>     ugly):
<salgado> I think the basic rule should be to have all the arguments aligned so that they stand out from the rest
<sinzui> I choose neither
<salgado> there's also
<intellectronica> iiuc the first one is not kosher, but you can choose wither of the last two
<bigjools> there's a 4th!
<salgado> def bar(foo, bar, baz,
<salgado>        nah):
<sinzui> I choose salgado's
<flacoste> i thought that was the agreed style actually
<barry> salgado: with the 'nah' lined up under 'foo'?
<salgado> barry, yep
<flacoste> barry: yes
<jtv> That's PEP-8
<barry> salgado: +1
<gmb> jtv: Good enough for me.
<BjornT> i think the 4th one is the most common one in our code
 * bigjools is using non-prop fonts here so it all looks ugly
<jtv> Personally I like the double-indent for continued parameter lists.
<bac> salgado: +1
<salgado> I personally prefer the second example of gmb
<salgado> but I'm strongly opposed to the first one
<gmb> salgado: That's the one I usually use, but I'm happy to follow prevailling wisdom
<gmb> s/usually/
<salgado> hence my saying that the basic rule should be to have all the arguments aligned so that they stand out from the rest
<jtv> Should we put this on a wiki page (where we know it's in nonproportional fonts) and vote?
<salgado> if that was the rule all three options would be allowed, which I think is fine
<salgado> maybe not the third one as it looks quite ugly
<bac> i'm against any style that lines up the arguments with the body of the method
<gmb> I think the third one takes up unnecessary space.
<intellectronica> bac: i very much agree
<barry> bac: i agree too
<jtv> +1 for bac
<danilos> I'd be for the current prevailing style "de salgado" (at least in this meeting)
<barry> danilos: +1
<jtv> But verily it sucketh with long method names.
<barry> [VOTE] adopt salgado's suggestion for parameter indents: aye +1 or nay -1
<MootBot> Please vote on:  adopt salgado's suggestion for parameter indents: aye +1 or nay -1.
<MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
<MootBot> E.g. /msg MootBot +1 #launchpad-meeting
<barry> +1
<MootBot> +1 received from barry. 1 for, 0 against. 0 have abstained. Count is now 1
<bigjools> +1
<MootBot> +1 received from bigjools. 2 for, 0 against. 0 have abstained. Count is now 2
<salgado> +1
<gmb> +1
<allenap> +1
<MootBot> +1 received from salgado. 3 for, 0 against. 0 have abstained. Count is now 3
<MootBot> +1 received from gmb. 4 for, 0 against. 0 have abstained. Count is now 4
<MootBot> +1 received from allenap. 5 for, 0 against. 0 have abstained. Count is now 5
<bac> +1
<sinzui> +1
<MootBot> +1 received from bac. 6 for, 0 against. 0 have abstained. Count is now 6
<MootBot> +1 received from sinzui. 7 for, 0 against. 0 have abstained. Count is now 7
<danilos> +1
<MootBot> +1 received from danilos. 8 for, 0 against. 0 have abstained. Count is now 8
<flacoste> +1
<MootBot> +1 received from flacoste. 9 for, 0 against. 0 have abstained. Count is now 9
<danilos> ho-hum, what was that discussion about in the first place? :)
<statik> +1
<MootBot> +1 received from statik. 10 for, 0 against. 0 have abstained. Count is now 10
<jtv> danilos: car repairs.
<barry> #endvote
<flacoste> jtv: don't use long method names :-)
<barry> er, whatever mootbot
<barry> flacoste: right
 * bigjools aims a kick to mootbot's nads
<barry> gmb: can you update PythonStyleGuide and send a quick email to the ml?
<gmb> barry: Will do.
<flacoste> jtv: seriously, i think we should allow starting the argument lists on the next line with a double-indent for long method names
<barry> [ACTION] gmb to update PSG for parameter indents and email launchpad@
<MootBot> ACTION received:  gmb to update PSG for parameter indents and email launchpad@
<bigjools> barry: I will do the same about the OCR topic
<danilos> #startsomethingtoendvote
<jtv> flacoste: +1 for that
<barry> [ACTION] bigjools to email launchpad@ about devs sticking around for their ocr
<MootBot> ACTION received:  bigjools to email launchpad@ about devs sticking around for their ocr
<barry> flacoste, jtv yes, it's okay if there are exceptions for superCrazyMegaUltraLongMethodNamesThatTakeUpTonsOfSpace
<barry>    * (mwhudson) What are page tests for?
<sinzui> use cases
<barry> mwhudson: brought up some questions about the purpose of page tests. are they customer stories or do they test our templates
<sinzui> customer acceptance tests
<barry> right now, the stuff in pagetests is some of both
 * sinzui tests templates in doc/*-pages.txt
<salgado> I test views in there
<salgado> I mean doc/*-pages.txt
<sinzui> salgado: So do it, but I recently added template tests since I did not think it was relevant to the use case
<barry> sinzui: i think we mostly agree, so mwhudson is going to start a ml thread about it and begin to get people to separate these
<bigjools> I think customer stories should involve all aspects of the template, otherwise what is that part the template doing there?
<flacoste> sinzui: testing template in doc/*-pages is not our standard, although it might make a good idea
<BjornT> sinzui: do you have an example?
 * sinzui thinks
<flacoste> bigjools, sinzui: sometimes you have to test all the possibilities in a template
<flacoste> but that's not relevant to the user stories
<flacoste> as a dev, you know that these three cases involved three different code paths
<intellectronica> i think that it's ok to mix the two purposes, as long as you get sufficient coverage
<flacoste> but from the point of view of the user, it's one sue-case
<intellectronica> that's in line with our not doing unit tests for everything
<flacoste> intellectronica: which i think is wrong
<jtv> intellectronica: but is that a good thing?
<flacoste> but that's just me
<sinzui> BjornT: I checked the calls to the search form in launchpad-search-pages. the form is a technical matter, not a use case.
<intellectronica> jtv, flacoste: i'm not sure myself, i just note that this is how we do it. mostly, it means that we have to pay attention closely to make sure that we get full coverage from the mix of tests we do have
<sinzui> the pagetests need reorganisation, and normalisation
<jtv> sinzui: +1
<bigjools> if your template is *that* complicated it has multiple code paths, should it not be simplified and stuff put in the view?
<danilos> as do all our other tests
<bigjools> my eyes bleed over some templates
<barry> sinzui: right.  thumper is going to start a thread about test reorg, and especially moving ftests stuff to tests
<sinzui> bigjools: right. We don't have as many doc/*-pages.txt as we should have, I think a lot of pagetests are checking the view's behaviour
<barry> bigjools: reviewing pts are incredibly painful
<bigjools> exactly
<danilos> if we are to reorganize tests, we should make as clear separation and categorization as possible, covering all testing
<bigjools> and if more stuff is in the view, it can be tested separately
<bigjools> and more efficiently
<bigjools> thus speeding the test suite
<flacoste> bigjools: different code paths simply means different conditions
<flacoste> so the logic is in the view
<BjornT> intellectronica: it's not really how we do it. basically, we treat our tests for DB classes as 'unit tests'. they should have have as much coverage as possible.
<flacoste> but you still need coverage that the template is using the view correclty
<bigjools> flacoste: agreed
<flacoste> barry: ftests/tests is an historical separation
<barry> flacoste: s/historical/hysterical/ :)
<barry> but yeah
<sinzui> barry: +1
<barry> anyway, we've gone over.  my apologies for that.  we'll continue this discussion on the list when mwhudson starts it
<barry> #endmeeting
<MootBot> Vote is in progress. Finishing now.
<MootBot> Final result is 10 for, 0 against. 0 abstained. Total: 10
<MootBot> Meeting finished at 09:52.
<barry> thanks everyone!
<jtv> barry: thank you, nice seeing you again :)
<intellectronica> thanks barry
<bac> thanks barry & mootbot
<barry> jtv: you too!  you're welcome to stop by any time :)
#launchpad-meeting 2008-06-19
<salgado> me
<abentley> me
<thumper> me
<bigjools> moo
<flacoste> chair is late
<mwhudson> me
<stub> me
<flacoste> roll call hasn't started yet
<gmb> Rincheeeeeeeeeeeeeeeeeen....
<mpt> Rinchen's on holiday
<sinzu1> All is moot without mootbot
<mpt> all this week
<mars> Rinchen's off in the wilderness somewhere...
<gmb> Ah, so it's kiko's show is it?
<bac> kiiiiiiiiiiko
<gmb> And he's not even in the room
<flacoste> stub: did you get my email about the api-acl-db DB patch?
<matsubara> kiko's on the phone
<flacoste> stub: i'd like you to land it unless there is good reason not to do it
 * stub has a look
<mpt> #startmeeting
<MootBot> Meeting started at 13:06. The chair is mpt.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<mpt> nono, the chair is kiko
<kiko> mpt, can you help be chair? I'm still on the phone
<gmb> pwned.
<mpt> ok, MEETING TIME
<mthaddon> me
<mpt> Who is here today?
<matsubara> me
<allenap> me
<schwuk> me
<sinzui> me
<mrevell> me
<flacoste> me
<stub> me
<gmb> me
<kiko> em
<intellectronica> me
<bac> me
<EdwinGrubbs> me
<mars> me
<bigjools> me
<statik> me
<adeuring> me
<salgado> me
<leonardr> me
<mpt> me
<thumper> me
<mwhudson> me
<abentley> me
<thumper> rockstar: ?
<mpt> Team leads, please ensure all your team members who should be here are
<mpt> That, by the way, was
<mpt> [TOPIC] Roll call
<MootBot> New Topic:  Roll call
<mpt> And now it's time for
<mpt> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<bigjools> cprov ping
<mpt>  * Next meeting
<mpt>  * Actions from last meeting
<mpt>  * Oops report (Matsubara)
<mpt>  * Critical Bugs (Rinchen)
<mpt>  * Bug tags
<mpt>  * Operations report (mthaddon/herb)
<mpt>  * DBA report (stub)
<mpt>  * Sysadmin requests (Rinchen)
<mpt>  * New packages required (salgado)
<mpt>  * A top user-affecting issue (mrevell)
<mpt>  * Doc Team report (mrevell)
<herb> me
<al-maisan> me
<cprov> me
<mpt> If anyone has other items, please /msg me
<barry> me
<mpt> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<mpt> If anyone knows of any reason why the next meeting should not be same time, same channel, let them speak now, or forever hold their peace
<mpt> Is there anyone who won't be here?
<kiko> I will be :)
<mpt> A resounding silence, that's good
<mpt> ok
<mpt> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<mpt>  *  Joey to ping Salgado about documenting package dependency policy
<salgado> not done
<mpt> [TOPIC] Oops report
<MootBot> New Topic:  Oops report
<matsubara> Today's oops report is about bugs 241355
<ubottu> Launchpad bug 241355 in launchpad-bazaar "OOPS requesting cvs code import using the new code import interface" [Undecided,New] https://launchpad.net/bugs/241355
<matsubara> thumper, can you assign and schedule 241355?
<thumper> ok
<matsubara> thumper: thanks
<matsubara> mpt: that's it for the oops report.
<mpt> thanks matsubara
<mpt> [TOPIC] Critical Bugs
<MootBot> New Topic:  Critical Bugs
<matsubara> No critical bugs open.
<mpt> excellent
<matsubara> that's it for critical bugs :-)
<mpt> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<mpt> There is one proposed tag
<matsubara> we have package-diff as a proposed tag
<bigjools> that was last week
<kiko> and we approved it :)
<matsubara> yes, was that accepted or moved to this one?
<mpt> ok
<cprov> :)
<bigjools> cprov, did you want to raise another one for p3a?
<matsubara> ok
<mpt> It was approved
<cprov> bigjools: yes, probably, but I will propose it next week
<mpt> matsubara, can you take care of moving it to the Approved section?
<matsubara> mpt: yep
<mpt> thanks
<mpt> [TOPIC] Operations report
<MootBot> New Topic:  Operations report
<mpt> mthaddon or herb?
<herb> Friday (2008-06-13) - Librarian seemed to have problems which caused a knock-on effect on app servers. Caused about 10 minutes of downtime. Tom might have more in the way of details.
<herb> Wednesday (2008-06-18) - Upgraded a bunch of servers to hardy. Took about 4 hours of planned downtime to do so.
<herb> There are 2 cherry picks (r6410 and r6451) awaiting approval that, I'm assuming, won't be approved prior to the rollout.
<herb> The only remaining hosts to be updated to hardy are the Soyuz machines. They are scheduled for tonight.
<herb> The Debian import machine is up and configured. Celso and I have been working through remaining issues and are making good progress.
<herb> Bug #224623 is still hanging around. We haven't seen the problem crop up again and I know Stuart has been very busy with the 8.3 upgrades. If there is anything we can do to help, Tom and I are happy to do so.
<ubottu> herb: Bug 224623 on http://launchpad.net/bugs/224623 is private
<herb> That's it from Tom and me unless there are any questions.
<mpt> thanks herb
<stub> When is bug expiry going to be implemented?
<stub> Then annoying unreproducible issues will silently die...
<mpt> sinzui, is that something you can answer?
<intellectronica> wasn't it already implemented, then cancelled?
<sinzui> mpt: No
<flacoste> mpt: sinzui is off the hook fo rthat nor
<flacoste> it's a bugs team decision
<mpt> BjornT?
<stub> I'm not that serious...
<intellectronica> mpt: he's not here today
<mars> BjornT is off today
<mpt> ok, we'll move on
<mpt> He looks here
<mpt> [TOPIC] DBA report
<MootBot> New Topic:  DBA report
<stub> Everything is running PG 8.3 now. It seems faster. Todays OOPS reports will give us not-a-metric.
<stub> The first stage of the Auth/Person split has landed. yay. This opens launchpad/devel up for db changes so land 'em if I haven't done it for you.
<stub> All the db patches I'm aware of have been reviewed for this cycle.
<stub> We need to work out where staging and demo are going to live. Demo needs to go first as I will use staging for testing replication and there just isn't enough disk atm for everything.
<stub> After we have worked out and tested how this replication stuff is going to be glued together I'd like the launchpaddb master and authdb replica running on hackberry and the authdbmaster and launchpaddb replica running on chokecherry.
<mthaddon> stub, if we drop launchpad_demo from 8.2 on chokecherry, would that give us enough space?
<stub> I didn't drop it already? Better do that now or the staging restore will likely blow up again...
<stub> If it fits, it will be very tight.
<mthaddon> stub, it did blow up - I dropped launchpad_langpack and it now is okay with restore
<mthaddon> stub, but I suspect if we drop launchpad_demo as well we'll get some more space again
<mthaddon> stub, should I just do that now?
<rockstar> me
<stub> So we might be fine for testing.
<stub> dropping it now
<mthaddon> cool (and session_demo too I presume)
<stub> If we run staging and production and demo on chokecherry that will be 4 full copies of the production db (because staging will need to be replicated too).
<mthaddon> stub, our current staging restore also means creating another db (launchpad_staging_new) and then dropping and renaming if the restore works
<stub> And it will be a production server, highly visible if it goes down, so I still vote for demo and staging on different hardware.
<stub> Ok. 5 full copies.
<mthaddon> stub, would definitely be better, just don't know if we have other hardware anywhere near the same class
<mpt> Ok, anything more from the DB department?
<stub> I don't think we need it in the same class personally - I'd prefer staging to be underpowered compared to production.
<stub> (If we need production level hardware to cope with one or two users, how can we expect production to cope?)
<mthaddon> stub, tough one that, as ideally we want to be able to see how performance compares on similar hardware, but load is different, so....
<stub> mpt: next...
<mpt> thanks stub
<mpt> [TOPIC] Sysadmin requests
<MootBot> New Topic:  Sysadmin requests
<mpt> matsubara is filling in for Rinchen
<matsubara> Any outstanding RT requests? I'll send those out to Joey and he'll follow up
<matsubara> on Monday. If there's anything that can't wait until Monday, I'll follow up
<matsubara> with elmo.
<bigjools> The Soyuz team has RT 31016
<cprov> kees and ubuntu-security team need access to http://private-ppa.buildd
<mpt> I'd like to express my appreciation for RT 27357 being closed after 15 months :-)
<matsubara> cprov, bigjools I'll ask elmo to take a look. how important is it?
<bigjools> matsubara: very
<bigjools> thank you
<matsubara> np
<mpt> thanks again matsubara
<mpt> [TOPIC] New packages required
<MootBot> New Topic:  New packages required
<salgado> anything for launchpad-dependencies this week?
<kiko> well
<kiko> yes
<kiko> flacoste has a profiling package we want
<kiko> oh, no, that goes to sourcecode/.
<kiko> sorry.
<flacoste> kiko: no, it's in sourcecode
<abentley> I encountered some issues because TG isn't a dependency.
<kiko> abentley, TG?
<abentley> TurboGears
<stub> bzr-loom might need to be packaged - there are looms in the review queue (salgado)
<mwhudson> tg won't be a dependency for much longer
<flacoste> salgado will use export-loom
<flacoste> as everybody using loom should
<flacoste> it makes better thread on the mailing list
<salgado> yeah, I'll use that
<flacoste> otherwise all branches look the same
<stub> yay. sftp really sucks here. need the smart server.
<barry> though it would be nice not to have to export, as it's a bit of extra work
<flacoste> abentley, salgado: i thought there were issues packaing turbo-gears
<salgado> flacoste, no, it's already packaged.  there are issues running it, IIRC
<flacoste> barry: i don't agree, i hate record :-)
<salgado> it doesn't run against our sqlobject
<barry> flacoste: i hate record too!  still if you have 5 thread, you have an issue :)
<abentley> salgado: I haven't seen any reports of issues running it.  AFAICT, the sqlobject one is a non-issue.
<abentley> It runs against its own sqlobject just fine.
<flacoste> barry: i don't understand what is the issue
<mwhudson> abentley: is this an issue if i land the loggerhead branch that removes the dependency on turbogears?
<salgado> abentley, the issue is whether or not we want our developer dependencies to include sqlobject
<emgent> hello
<abentley> salgado: I think make run_all should not require anything above our developer dependencies.
<barry> flacoste: i'll explain after the meeting
<abentley> mwhudson: No, if you land that, it goes away.
<mwhudson> let's do that then
<mwhudson> (it's very nearly ready)
<salgado> mpt, guess we're finished here
<mpt> thanks salgado
<mpt> [TOPIC] Storm update
<MootBot> New Topic:  Storm update
<mpt> kiko?
<jtv> He's on the phone I believe.
<mpt> ok, we can leave that for a few minutes
<mpt> [TOPIC] A top user-affecting issue
<MootBot> New Topic:  A top user-affecting issue
<mpt> mrevell!
<mrevell> hey hey
<mrevell> Recently, we've had a number of users who have written to the feedback address complaining that they are receiving large numbers of bug related emails. They've subscribed to a project or distro and don't know how to turn it off.
<kiko> back back. sorry mpt, jtv.
<mrevell> Alongside the "kill bug mail" button that we're planning, I think we should make it clearer that a structural subscription could result in a great deal of email. I also think we should show structural subs on people bug pages. I've filed bug 241387 to reflect this.
<ubottu> Launchpad bug 241387 in malone "Can't view the projects whose bugs I've subscribed to" [Undecided,New] https://launchpad.net/bugs/241387
<mrevell> As an aside, we've had no emails to the feedback address or -users complaining about the Hardy upgrade related service interruptions. One person complained about an Internal Server Error but the time he reported doesn't seem to tie up with our recent interruptions.
<mrevell> thanks mpt
<mpt> thanks mrevell (and I think 241387 might be a duplicate;-)
<mrevell> mpt: gosh darn it, I did look
<mpt> [TOPIC] Storm update
<MootBot> New Topic:  Storm update
<kiko> mrevell, yeah, it appears they went through very smoothly -- thankfully, too. :)
<kiko> very good.
<kiko> storm's been running on staging for the past days, but it's been upgraded today to r6527, which includes perf work which gustavo and niemeyer have been doing
<stub> Do we want to record metrics of how many bugs a particular structural subscription would generate per day? The average so far? Then we could warn users how much traffic they are going to get.
<thumper> some, many, lots
<intellectronica> stub: i think that's a really cool idea!
<kiko> stub, I actually think these people are subscribing for the wrong reason -- they don't actually know
<kiko> they are just clicking on buttons and hoping their bugs get fixed
<kiko> anyway
<kiko> so staging's running a recent version of storm
<kiko> I need to ask you to please spend 10 minutes today trying to navigate, modify and check out staging
<mpt> matsubara, can you report a bug on implementing stub's suggestion?
<mpt> it's a neat idea
<kiko> from the oops logs I am still seeing significant non-sql time in many pages
<kiko> for instance:
<kiko> https://devpad.canonical.com/~matsubara/oops.cgi/2008-06-19/S833
<kiko> https://devpad.canonical.com/~matsubara/oops.cgi/2008-06-19/S599
<kiko> https://devpad.canonical.com/~matsubara/oops.cgi/2008-06-19/S886
<kiko> https://devpad.canonical.com/~matsubara/oops.cgi/2008-06-19/S888
<kiko> it's not happening on every page, thankfully
<kiko> but those pages will need further investigation. just how much is a question for flacoste, SteveA, niemeyer and me after this very meeting. :)
<kiko> we will decide together whether to rollout edge or not.
<kiko> if we do roll out, you'll be notified through email
<kiko> note also that 1.2.6 remains targeted for Wednesday next week
<kiko> ask me questions now :)
<mpt> kiko, if we do, when will it happen? intellectronica and mars will be wanting to watch to see if the help frame appears like it did at the last edge rollout
<intellectronica> indeed
<kiko> mpt, later today.
<mars> ok
<kiko> I know -- I have the same thing on my mind.
<mpt> ok
<stub> That peoplelist one is a high start - I hope Storm isn't sucking the first 1.9 million people to render the next 50...
<kiko> the one which concerns me the most is MailingListAPIView
<kiko> so we'll see
<barry> kiko: we have an open bug on that one
<kiko> barry, it's about to be made critical :)
<kiko> more seriously, let me talk to francis
<barry> kiko: yay!
<kiko> okay.
<kiko> let me steal the spotlight for another announcement.
<mpt> [TOPIC] Another announcement
<MootBot> New Topic:  Another announcement
<flacoste> kiko: that one only happens on Staging iirc
<kiko> I'm running an experimental test service for branches in PQM
<flacoste> kiko: it's not clear why it's only a problem on staging though
<kiko> flacoste, I still want it fixed :-/
<kiko> this experimental service does the following:
<kiko> - merges all branches in the PQM queue
<kiko> - reports conflicts
<kiko> - runs tests
<jtv> Yay!
<kiko> look at the topic in #launchpad-code for the URL
<salgado> does it revert the merges which caused conflicts?
<thumper> kiko: so if it is good, you could clear the pqm queue :)
<kiko> yes
<kiko> thumper, indeed :)
<mpt> nifty
<kiko> thumper, however, I haven't managed to get the tests to pass :)
<salgado> just like pqm
<kiko> salgado, yeah, it does -- it has to :)
<stub> The trick will be inserting a branch containing the merged branches into the front of the pqm queue
<kiko> stub, when tests pass, yes
<kiko> anyway
<kiko> if you have a branch in PQM
<kiko> watch that URL
<flacoste> kiko: that kind of lose al commits messages
<flacoste> but saves us processing time
<mpt> and could make it harder to back out changes
<kiko> flacoste, I commit the individual logs with the commit messages.
<flacoste> and that too
<stub> You might want something dumber in reality - pick three random branches from the queue, merge, run tests, if pass stick an integration branch to the front of the queue.
<intellectronica> flacoste: they can comitted separately
<thumper> kiko: you should get it to not stop on the first failure
<stub> Rather than the entire queue, which will be more likely to fail when we need it most.
<kiko> mpt, flacoste: well, we DO use a revision control system.. :)
<matsubara> stub, mpt: https://bugs.edge.launchpad.net/malone/+bug/241398 did I get it right?
<ubottu> Launchpad bug 241398 in malone "Record metrics on how many notifications a structural subscription will generate." [Undecided,New]
<kiko> right now, it looks like al-maisan's branch is still failing in PQM :)
<al-maisan> Whoops
<kiko>     testDelayedBinaryUpload (canonical.archiveuploader.ftests.test_buildduploads.TestBuilddUploads)
<mpt> matsubara, pretty much
<kiko> etc.
<mpt> ok
<mpt> Anything more kiko?
<kiko> no, that's it from me.
<mpt> thanks
<mpt> [TOPIC] Doc Team report
<MootBot> New Topic:  Doc Team report
<mrevell> hi
<intellectronica> matsubara: that should probably be on launchpad itself, rather than malone, because structural subscriptions are nt (in the long run) a malone-only feature
<mrevell> Just a quick one: I've sent a new translations section of the user guide to the team list for review. I'd really appreciate your review of it. Thanks mpt.
<mpt> thanks mrevell
<mpt> And now, as the Storm of indecision rolls in over the streetscape of #launchpad-meeting
<mpt> And the Janitor of time sweeps away the dust of our agenda
<mpt> It's time to bring this week's meeting to a close.
<mrevell> mpt: heh :)
<mpt> #endmeeting
<MootBot> Meeting finished at 13:49.
<intellectronica> thanks mpt
<mpt> Thanks everyone
<mrevell> nicely done mpt and I love the tribute to Humphry Littleton at the end there :)
<jtv> MootBot: what timezone are _you_ in?
<kiko> heh
<kiko> mpt, thanks so much for saving my bacon :)
<intellectronica> tz -42
<mpt> matsubara, so the actual problem is "People don't realize how much mail a structural subscription will send them"
<mpt> that wouldn't be solved just by recording the average messages/month
<mpt> it would be solved by recording it *and* presenting it on the page for subscribing
<mpt> an alternative (though highly unlikely) way of fixing the problem would be to get rid of structural subscriptions
<mpt> there might be other ways of fixing the problem that we haven't thought of
<matsubara> right, I'll update the description.
<mpt> Reporting it as a problem (and suggesting possible ways to solve it) makes it less likely to end up marked Invalid :-)
#launchpad-meeting 2009-06-17
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everyone and welcome to this week's ameu reveiwers meeting.  who's here today?
<bigjools> me
<bac`> me
<allenap> me
<gmb> me
<adeuring> me
<salgado> me
<henninge> me
<jtv> me
<beuno> me
<intellectronica> me
<mars> me
<flacoste> me
<barry> BjornT: ping
<barry> cprov: ping
<barry> danilos: ping
<barry> EdwinGrubbs: ping
<cprov> me
<danilos> me
<EdwinGrubbs> me
<barry> rockstar: ping
<barry> sinzui: ping
<sinzui> me
<barry> i think that's everyone
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Action items
<barry>  * Mentoring update
<barry>  * Peanut gallery (anything not on the agenda)
<barry>    * naming of unittest methods (Camel``Case or under_scores) (henninge)
<barry>    * order of assert parameters (expected, observed) (hennige)
<barry>  * Driving maintainable Javascript code (intellectronica)
<barry>   * Modularization and unit testing are strongly encouraged
<barry>   * Refactoring code after a UI review is often a good idea
<barry>   * The upper limit for JS diffs is 1600 lines (because javascript is so verbose)
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry> i think the only one outstanding is gary's and he's away today
<barry> so...
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> i think we have just one mentored reviewer left, and noodles isn't here today
<barry> so...
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<barry>    * naming of unittest methods (Camel``Case or under_scores) (henninge)
<barry>    * order of assert parameters (expected, observed) (hennige)
<barry> henninge: the floor is yours
<henninge> Hi
<henninge> Yesterday cprov and I ran into this discussion about how to name unittest methods.
<henninge> I have always done test_the_frobnob, while his branch had testTheFrobnob
<henninge> The argument is: Coding style for methods is CamelCase
<cprov> yes, and I've used CamelCase for most of the soyuz unittest, and it's not looking good.
<salgado> isn't the policy to use test_methodName()?
<intellectronica> i have a feeling of deja vu
 * barry would greatly prefer anything make makes us more pep 8-y
<intellectronica> salgado: exactly
<mars> I thought unit_tests_were_the_exception?
<henninge> but these methods are never called directly and only appear in test runner
<henninge> output
<bigjools> salgado: +1
<jtv> this was changed a few months back, but I don't remember what it was changed to exactly.
<gmb> barry: +1
<flacoste> we already discussed that
<flacoste> the convention for unit test is:
<flacoste> test_methodName_with_particular_condition
<bac`> flacoste: that's what i remember too.
<henninge> ah, that was my faint memory, too.
<flacoste> we had this discussion like 6-8 months ago
<barry> flacoste: yes
<salgado> When testing a specific Launchpad method, a mix of PEP 8 and camel case is
<salgado> used, e.g. test_fooBarBaz()
<bigjools> is it not in the style guide?
<flacoste> barry: somebody should have updated the wiki ;-)
<salgado> https://dev.launchpad.net/TestsStyleGuide#Functional and Unit Tests
<salgado> flacoste, it's there!
<salgado> In general, you should follow Launchpad coding conventions (see PythonStyleGuide), however when naming test methods:
<salgado> ...
<flacoste> perfect!
<barry> flacoste: time machine activated!
 * bigjools sees a rapid end to the discussion coming
<flacoste> anybody wants to rehash this?
<cprov> cool, problem solved.
<henninge> second item
<henninge> I have seen that LaunchpadTestCase uses assert(expected, observed)
<henninge> and have used the asserts that way.
<henninge> But I see a lot of (obseved, expected).
<barry> henninge: +1 for (expected, observed)
<henninge> barry: me, too
<bigjools> do you mean assertEqual?
<henninge> is there a guide line for that already?
<intellectronica> i don't understand
<henninge> bigjools: yeah
<henninge> oh sorry, I meant assert*(e,o)
<henninge> btw, I found out that not everybody knows about LaunchpadTestCase
<salgado> intellectronica, self.assertEquals(sut_output, 'what I expect') instead of self.assertEquals('what I expect', sut_output)
<barry> henninge: could you please update https://dev.launchpad.net/TestsStyleGuide
<intellectronica> i don't think it's worth having a policy on that. it doesn't matter
<bigjools> I don't either
<salgado> agreed
<barry> actually, i think it's better to be consistent because it's easier to debug
<bigjools> how does it make it easier?
<barry> bigjools: you have to think less when you see failing output
<henninge> yes, it's for clarity.
<intellectronica> if you want to make it really easy you can do `expected = expr \n observed = expr \n assertEqual(expected, observed)`
<henninge> intellectronica: true
<bigjools> yeah, I quite like that style
<henninge> that is fine by me, too.
<barry> intellectronica: it would be better to have that in the framework
<intellectronica> but again, i don't think we should force this. just remember that it's a possibility
<bigjools> I think encouraged but not enforced
<barry> just sayin', all things being equal, we prefer (expected, observed)
<bac`> bigjools: +1
<barry> bigjools: +1
<henninge> bigjools: +1
 * bigjools is not used to this many people agreeing with him
<barry> henninge: can you capture this in the wiki?
<henninge> barry: will do
<barry> [ACTION] henninge to capture decision on assert*(expected, observed) preference in wiki
<MootBot> ACTION received:  henninge to capture decision on assert*(expected, observed) preference in wiki
<barry> henninge: thanks!
<henninge> np
<barry> [TOPIC]  * Driving maintainable Javascript code (intellectronica)
<MootBot> New Topic:   * Driving maintainable Javascript code (intellectronica)
<barry>   * Modularization and unit testing are strongly encouraged
<barry>   * Refactoring code after a UI review is often a good idea
<barry>   * The upper limit for JS diffs is 1600 lines (because javascript is so verbose)
<intellectronica> what a stupid title. i should be shot
<barry> intellectronica: why? because of the oxymoron? :)
 * bigjools chuckles
<barry> intellectronica: the floor is yours
<intellectronica> in the last ajax swat team meeting, we rockstar and deryck led a discussion about how to produce better (more maintainable, easier to test) javascript code
<intellectronica> we made several observations:
<intellectronica> 1. code that is OO and modularized is much easier to work with than code that is very imperative and/or relies on closure too heavily
<intellectronica> 2. unit tests (aka YUI tests) are a great way to test our code. in many cases much better than integration tests
<intellectronica> 3. working on UI features it is often easier to first concentrate on completing a working UI than on code quality
<intellectronica> that's fine, but it means that we should refactor the code immediately after it passes UI review
<intellectronica> that can happen either before code review, or if not, the reviewer should encourage doing that (either as part of this branch or in a followup branch)
<intellectronica> finally, since javascript code is so much more verbose, we propose a much higher limit, in order to encourage developers to not skip these important steps
<flacoste> one of those being writing unit tests
<intellectronica> we think 1600 lines (double the limit we have for python) is reasonable
<barry> intellectronica: how can we get more assistance in making our js work correctly, and be more consistent?  although everyone i've asked for help has been very helpful, i still often feel like i'm just hacking in the dark until it works
<flacoste> just unit tests can talk 2/3 of your branch size
<barry> intellectronica: when you say "javascript unit test" you're not talking about windmill, right?
<barry> or are you?
<intellectronica> barry: to some extent, we are all a bit in the dark, discovering how to best go about this. discussions in #rhinos and on the canonical-javascript mailing list are a good way to exchange ideas
<mars> barry, yuitest, not windmill
<intellectronica> barry: no. we're talking about in-page unit tests using the yuitest framework
<barry> intellectronica: fair enough :)
<intellectronica> you'll be glad to learn that they are much easier to write and execute
<barry> mars: i don't know anything about yuitest.  where can i learn and/or where are good examples in our code?
<flacoste> lazr-js/src/*/tests
<barry> intellectronica: that would make me very very happy :)
<sinzui> where are these unit tests in our tree?
<intellectronica> barry: see lib/canonical/launchpad/javascript/soyuz/tests for example
<mars> barry, right now the best examples are in lazr-js itself, but others will be landing examples in launchpad soon
<flacoste> <...>/javascript/*/tests
<intellectronica> also all widgets in lazr-js have tests
<flacoste> currently,only the soyuz module has some
<flacoste> yep lazr-js/src/*/tests
<barry> cool, thanks, i will be looking at those for the branch i'm currently working on
<flacoste> unit tests are really "unit" tests
<flacoste> no Launchpad
<flacoste> only DOM and you code
<flacoste> and it's an self-created DOM
<mars> barry, btw, the test infrastructure is open for hacking and improvement.  Please feel free to stop the pain :)
<sinzui> So I believe lp_dynamic_dom_updater.js is the only Launchpad test in our tree
<flacoste> in lauchpad, yes
<flacoste> lazr-js has tons of them
<intellectronica> so you still need to do some integration testing, but the advantage is that they encourage you to do a good job on modularizing your code
<barry> mars: i will as soon as i can localize it.  right now, it's mostly a full-body numbing throb.  :)
<barry> i think the other problem is that anything touching js just takes WAY more time to develop.  i don't think it's entirely the fault of not being as familiar with js.  it's a function of the ui 90/10 rule and the fact that yui documentation is lousy
 * barry knows he's just ranting
<intellectronica> barry: that, and the fact that we're all still learning. i bet in a couple of years we'll all be js/yui wizards. it takes time to build competency
<mars> barry, thankfully we have started to work on that. intellectronica's process improvements are an important step towards speeding things up
<barry> intellectronica: true.  though, we need to keep that in mind when estimating story points and such
<sinzui> intellectronica: so your saying in a couple of year javascript will require less keystrokes to code?
<barry> mars: yes, and they are greatly appreciated.  our velocity will certainly improve over time
<mars> sinzui, yes, actually
 * beuno yells from the back "FASTER!  FASTER!"
<intellectronica> sinzui: i'm sure in a couple of years you will have written enough gedit plugins to automate most of the crud :)
<sinzui> I guess the soyuz team won't notice since their class names exceed the line limit
 * barry mumbles "dabbrev"
 * sinzui pines for Javascript 1.7/ECMA ??
<bigjools> at least we have tests!
<mars> sinzui, you want ECMA 3.1 :)
<intellectronica> i think we digress. maybe we should start a js coder support group for ranting...
<intellectronica> is everyone cool with the increase in diff limit (and understands why it's necessary)?
<barry> intellectronica: yes :)
<sinzui> I think YUI looks to Java for inspirtation where are Javascript 1.7 looks to Python
<mars> sinzui, not the cloaked OO pining of 4.X ;)
<barry> intellectronica: it does make it more difficult to review, but it does make sense.
<intellectronica> barry: well, you don't really need to review the block delimiters and the uber-verbose documentation
<mars> intellectronica, +1
<barry> intellectronica: true
<barry> intellectronica: i'm certainly up for an experiment here.  if it's too painful we can address it again
<intellectronica> i think i'm done, unless anyone has anything to add
<intellectronica> and no, "javascript sucks" isn't a valid item. we already know that :-/
<barry> intellectronica: thanks. can you send a message to launchpad@ about the length limit?
<mars> :P
<intellectronica> barry: will do
<barry> [ACTION] intellectronica to email launchpad@ about js branch length limit increase
<MootBot> ACTION received:  intellectronica to email launchpad@ about js branch length limit increase
<sinzui> How are we increasing our JS reviewers?
<intellectronica> sinzui: i think by now pretty much everyone on the team does js reviews
<mars> sinzui, formally?
<bigjools> which team?
<intellectronica> bigjools: reviewers team (which is almost the same as the developers team)
<bigjools> intellectronica: I don't review JS then
<mars> sinzui, because js reviews are open to all, we leave it up to the reviewer's discretion
<sinzui> mars: I know a lot about javascript, but I do not consider myself a review because I do not know much about YUI, YUI unit tests, and windmill
<barry> right.  we're asking all reviewers to do js reviews, but ask the swat team for help when needed
<intellectronica> bigjools: well, time to start, then :)
<bigjools> intellectronica: I need to write some js myself first :)
<salgado> same with me
<bac`> me2
<intellectronica> bigjools: yes, i guess that's a prerequisite
<barry> one problem with this though is that there's little consistency in our js style
<mars> sinzui, right.  Depends on the review.  If it is a one-line logic bug, then you don't need a JS mentor call
<barry> for example, every branch i've written has had different recommendations during js review
<intellectronica> barry: anything in particular you've noticed?
<mars> sinzui, but if you desire a second opinion, then give someone on the AJAX team a shout
<barry> intellectronica: little things mostly, like where to stash objects, anim-reversing
<barry> intellectronica: i think of it more as refinement rather than conflicts
<flacoste> yeah
<flacoste> that pattern are not clear yet
<barry> mars: can you remind us who is on the "ajax team"?
<mars> anim-reversing is about learning, and weak docs (my fault)
<flacoste> so i think it's normal to get divergent opinion on these aspects
<barry> mars: no, i think flacoste has it right.  we're learning as we go, so consistency suffers for now.  we're just building up tech debt we know we'll have to pay off later
 * barry sees no other way around that
<flacoste> barry: EdwinGrubbs, mars, intellectronica, jtv, flacoste, rockstar
<flacoste> barry: and noodles
 * mars can't type today
<flacoste> and danilos - by virtue of having attended the Berlin sprint
<barry> flacoste: thanks.  we should capture that on a wiki page, if it isn't already
<danilos> barry: I think it is
<mars> barry, it is
<barry> cool
<barry> thanks
<intellectronica> barry: deryck too knows a lot about js and yui and can help, b.t.w
<mars> barry, just check the 'skills' column on the current reviewers page
<danilos> barry: https://dev.launchpad.net/ReviewerSchedule
<mars> s/skills/specialities/
<barry> as i said, everytime i've asked someone for some js help, y'all have been very nice and very helpful.  thanks!
<barry> we have 5 minutes left.  is there anything else to talk about today?
<flacoste> yes
<flacoste> i have
<flacoste> i'd like to get an update on the JS testing experiment
<flacoste> anyone tried it out in the last week?
<barry> nope
<mars> no, no JS landings :(
<flacoste> really?
<flacoste> ok
<intellectronica> a better question is: anyone been through review with a js branch which hasn't gone through testing?
<flacoste> yes, that's the proper way to phrase the question?
<flacoste> !
<barry> no, but i have a js branch going into review hopefully today
<flacoste> aha!
<barry> i guess i can be a guinea pig :)
<flacoste> what about the timeline branches that Edwin landed last week?
<mars> flacoste, the easiest way to push back on this may be to have reviewer's ask "Has it been tested on all browsers?"
<barry> guess not.  we're outta time, so shall we call it a day?
<flacoste> sure
<barry> flacoste: let's ask again next week!
<barry> #endmeeting
<MootBot> Meeting finished at 09:46.
<barry> thanks everyone
<intellectronica> thanks barry
<adeuring> thanks barry
<gmb> Ta barry.
<jml> lalalala
<mwhudson> hi
<thumper> hi ho
<barry> #startmeeting
<MootBot> Meeting started at 17:30. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> jml, mwhudson, thumper hi
<jml> hi
<thumper> hi
<mwhudson> hello
<barry> so, do you guys have anything or would you like me to start by reviewing the summary from ameu?
<thumper> summary is good
<mwhudson> summarizing is good
<barry> [TOPIC] summary from ameu
<MootBot> New Topic:  summary from ameu
<barry> henninge brought up a question about the order of parameters in unittest assert*() methods
<barry> we agreed that we "prefer" but won't "enforce" the order: (expected, observed)
<jml> +1
<thumper> +1
<barry> cool
<jml> that's what bzrlib does, and I think it's drifted into a lot of lp.code(hosting)?
<mwhudson> +1
<barry> yeah, consensus seemed to be behind this.  where there was some disagreement was on forcing people to do that order, so we compromised :)
<thumper> I'd probably enforce it
<barry> next, intellectronica outlined some of the things that the ajax swat team's been discussing about js branches
<barry> thumper: i would too, but there was no consensus, so "strongly prefer" seemed good enough
<thumper> barry: strongly prefer but individual reviewers may enforce L)
<barry> :)
<barry> more on this, or move on?
<thumper> move on
<jml> wait
<jml> are there any actual _points_ from the js branches?
<jml> or was it just a discussion?
<barry> jml: yes.  if we're moving on, i'll cut&paste intellectronica's points :)
<mwhudson> go go
<barry> code that is OO and modularized is much easier to work with than code that is very imperative and/or relies on closure too heavily
<barry> unit tests (aka YUI tests) are a great way to test our code. in many cases much better than integration tests
<barry> working on UI features it is often easier to first concentrate on completing a working UI than on code quality. that's fine, but it means that we should refactor the code immediately after it passes UI review. that can happen either before code review, or if not, the reviewer should encourage doing that (either as part of this branch or in a followup branch).
<barry> finally, since javascript code is so much more verbose, we propose a much higher limit, in order to encourage developers to not skip these important steps. 1600 lines
<barry> look in .../javascript/*/tests for unittest examples; only soyuz is in our tree atm. or look in lazr-js.
<barry> EOT
<jml> I would add "largely functional" to "OO and modularized"
<thumper> question
<jml> but that's just me.
<thumper> where is lp.code javascript supposed to go?
<barry> thumper: i don't know.  this morning was the first i heard of that stuff
<barry> the existing stuff is in l/c/l/javascript/*
<barry> so... old tree
<thumper> hmm..
<thumper> who is going to move this?
<barry> but i know very little about it (first looked at it about 10 minutes ago)
<barry> thumper: another good question.  i don't even know how to /run/ it
<mwhudson> it seems we have a meeting of the js-resistant!
<thumper> true
<barry> maybe when i send the minutes of the meetings, we can start a discussion of these on the ml
<barry> i really can't give you much more than what i just pasted ;)
<jml> :)
<barry> thumper has a topic when we're ready to move on
<thumper> It'd be nice if we could have the javascript for the apps in the right part of the tree
<jml> I'm ready to move on :)
<mwhudson> move on
<thumper> my topic
<barry> thumper: it's all yours
<thumper> this week the code team removed all lp.code imports from canonical.launchpad.database.__init__.py and canonical.launchpad.interfaces.__init__.py
<thumper> the team leads agreed to get this done for their projects
<thumper> we should make sure there are no imports from these modules in reviews
<thumper> to make their job easier
<thumper> I personally changed many IPerson and IProduct imports to lp.registry
<barry> thumper: awesome.  new is better :)
<jml> me too, actually.
<thumper> that's it
<mwhudson> +1
<jml> +1
<barry> +1
<barry> thanks thumper
<thumper> sold!
<barry> anything else guys?
<jml> barry, one more thing
<barry> jml: you're up
<jml> barry, I'd be kind of interested in knowing how many reviews people do per day.
<thumper> jml: we have real metrics
<jml> barry, because I'm thinking that the small size of asiapac lends itself (perversely) to everyone doing more reviews.
<thumper> jml: in LP
<jml> thumper, extract them for me :)
<barry> yes, that would be cool to know!  thumper can you get a losa to run a report?
<thumper> jml: some LP lib magic should be able to do this
<thumper> barry: I don't need no stinking losas :)
<jml> barry, very low priority, I guess. I've just been noticing how often I get interrupted, and wonder if Almighty Process can make that happen less :)
<barry> or that :)
 * mthaddon stares at thumper
<thumper> mthaddon: ... to run a script for me :)
<jml> that's it.
 * thumper can do it himself :)
<barry> jml: how does ocr work for you guys?  do you do it, or do you work on demand?
 * mthaddon is actually happy (apart from the stinking part)
<jml> barry, we do work on demand
<jml> AND
<jml> when we are ocrs, we do a lot of reviews
<thumper> barry: I don't do OCR, but do quite a few on demand
<jml> often more from the americas on OCR days.
<barry> jml: when you ocr do you just pop branches off activereviews or wait for devs to come to you.  and if the latter, do you get many non-asiapac branches?
<mwhudson> i don't really do ocr, to be honest
<jml> barry, I pop off to a limit of 3. :)
<jml> barry, or if they are small.
<barry> mwhudson, thumper gotcha
<mwhudson> generally whenever anyone says "can you do a review" i do it
<jml> barry, I do get people who come to me, but it varies from week to week.
<mwhudson> (ocr day or not)
<barry> jml: makes sense.  actually, interestingly enough, your BOD overlaps with our EOD, so you could do some on demand america reviews occasionally
<jml> barry, I sometimes do.
<barry> that's great, actually
<jml> (also, it's different in summer)
<barry> well, thumper if you run that script, do let us know.  it would be interesting
<barry> jml: who's summer? <wink>
<thumper> kk
<barry> anything else guys?
<jml> that's it from me.
 * thumper is done
<mwhudson> all from me
<mwhudson> thanks barry
<barry> thanks guys!
<barry> #endmeeting
<MootBot> Meeting finished at 17:51.
 * barry -> dinner
<thumper> thanks barry
#launchpad-meeting 2009-06-18
<danilos> Ursinha: ok, ok, I hear you
<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!
<Ursinha> me
<MootBot> Meeting started at 10:00. The chair is Ursinha.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<MootBot> New Topic:  Roll Call
<bigjools> me
<sinzui> me
<herb> me
<danilos> me
<stub> me
<Ursinha> intellectronica, rockstar, hi
<intellectronica> me
<rockstar> me
<Ursinha> hey!
<Ursinha> so we're all here
<Ursinha> apologies from matsubara, he's not here today
<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> * matsubara to check with Ursula about last week's meeting action itens - Items were done
<Ursinha> * flacoste to approve CP requests
<MootBot> New Topic:  * Actions from last meeting
<Ursinha> my items were okay
<stub> and apologies from Francis
<Ursinha> hmm, I missed flacoste
<Ursinha> stub, so he's not coming today..
<Ursinha> I'll have to check with him later then
<stub> I'm designated victim
<Ursinha> oh :)
<Ursinha> stub, so, do you know if he did that?
<stub> Nope :)
<danilos> there were a bunch of CPs done afaik
<herb> Ursinha: he did. they've been rolled out.
<Ursinha> herb, awesome
<stub> No outstanding CP requests
<Ursinha> danilos, I'm seeing them in lp list
<Ursinha> allright
<Ursinha> thanks guys
<Ursinha> moving on
<Ursinha> [TOPIC] * Oops report & Critical Bugs
<Ursinha> the bugs I had I already discussed with people
<Ursinha> I don't think I need to mention them here again :)
<Ursinha> all critical bugs are Fix Committed, so we're okay
<Ursinha> unless someone have something to say here, let's move on
<MootBot> New Topic:  * Oops report & Critical Bugs
<danilos> well, there's one that's not
<Ursinha> danilos, which one?
<danilos> pytz installation, let me look up the bug number
<danilos> bug 388825
<ubottu> Launchpad bug 388825 in rosetta "UnknownTimeZoneError on various pages" [Critical,Triaged] https://launchpad.net/bugs/388825
<sinzui> That will fix a bug in the registry
<danilos> Ursinha: we need help from LOSAs to resolve that, but there's more to it than that
<danilos> i.e. how do we prevent this from happening
<Ursinha> danilos, let me look, I checked half an hour ago and it wasn't there :)
<Ursinha> danilos, hm, I see
<danilos> Ursinha: stub marked it as critical 4 hours ago :)
<sinzui> I think bug 155334 will be fixed with the pytz landing
<ubottu> Launchpad bug 155334 in pytz "In select timezone section, "Kolkata" is shown as "Calcutta"" [Undecided,Fix released] https://launchpad.net/bugs/155334
<Ursinha> danilos, so refresh fail :)
<Ursinha> Undecided and Fix released
<Ursinha> is that correct?
<stub> pytz is updated on edge, so production is now seeing timezones it can't cope with. Fail.
<Ursinha> stub, argh, I understand the problem
<Ursinha> danilos, so you need a losa to help you with that
 * sinzui moves Kolkata for a moment
<danilos> Ursinha: well, I need losa to try to fix it, we are totally not in power of doing anything about it
<Ursinha> danilos, okay
<danilos> Ursinha: this is about date time formatter in TAL which breaks
<stub> I thought I had assigned it to Tom already?
<herb> stub, danilos: we can discuss it after the meeting.
<Ursinha> herb, can you help with that?
<Ursinha> oh, awesome
<Ursinha> :)
<danilos> herb: sure, thanks
<Ursinha> thanks herb
<sinzui> stub: danilos Who do I give credit to for fixing pytz?
<Ursinha> [action] danilos to discuss with herb a fix for bug 388825
<danilos> stub: can you join us in that discussion as well? (you seem to know more about it than I do :)
<MootBot> ACTION received:  danilos to discuss with herb a fix for bug 388825
<ubottu> Launchpad bug 388825 in rosetta "UnknownTimeZoneError on various pages" [Critical,Triaged] https://launchpad.net/bugs/388825
<herb> danilos, stub: I think we can keep it pretty short so stub can get offline for a few hours.
<danilos> herb: sure
<Ursinha> okay
<Ursinha> anything else here?
<Ursinha> moving on then
<Ursinha> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> 2009-06-12: Cherry picked r8488, r8508 and r8527 to most (all?) of soyuz.
<herb> 2009-06-16: Cherry picked r8608 to lpnet* and the librarian.
<herb> 2009-06-17: Cherry picked r8644, r8647 and bzr 1.16rc1 to just about everything. I think we only skipped soyuz.
<herb> Since the CP yesterday we've had to restart codebrowse a couple of times. Apparently it's taking a while to restart (10 minutes) because it's trying to fetch wadllib and timing out before starting. I don't have much more detail than that unfortunately.
<Ursinha> rockstar, are you aware of that?
<rockstar> Ursinha, I indeed was, although not involved, so cannot provide support.
<Ursinha> rockstar, okay, can you ask who could help then? :)
<Ursinha> herb, hmm, I guess we don't have a bug for that, do we?
<herb> Ursinha: I don't know. I saw it in scrollback when I started this morning.  I haven't experienced the problem and haven't had a chance to check with spm or mthaddon to figure out if a bug was filed.
<rockstar> Ursinha, I think everyone knows what's going on.  spm, jml, and mwhudson are quite the think tank.
<rockstar> Everyone == "the people who really can do something about it"
<Ursinha> rockstar, ok, I'll talk to matsubara and make him aware of that, as he'll be doing the late shift today
<Ursinha> thanks rockstar and herb
<mthaddon> yeah, I'm not aware of a bug report - happened after my EOD so I heard a little about it but not the full details
<Ursinha> mthaddon, I'll catch up with spm later, thanks!
<Ursinha> anything else for herb
<Ursinha> ?
<Ursinha> [action] Ursinha to talk to matsubara and spm later about the codebrowse taking 10 mins to restart
<MootBot> ACTION received:  Ursinha to talk to matsubara and spm later about the codebrowse taking 10 mins to restart
<Ursinha> moving on then
<Ursinha> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<danilos> yeah, entire LOSA team was a great help for QA last week, my thanks :)
<stub> Simulated replication lag has been turned off on staging as it was triggering the lag detection we use to make batch jobs play nicely, blocking them from running. Replication settings on staging now match production on the Launchpad trunk. I can reset things manually again if further testing is needed and there is difficulty updating the staging code base at the moment.
<stub> The Storm update has landed, and been reverted. There are issues with buildout and buildbot. Perhaps buildout is running a script without PYTHONPATH set correctly, perhaps it is a catch-22 where the environment setup process invokes scripts that require Storm which isn't found because the environment isn't setup yet. Bug #388825 reassigned to Francis as I think he is the only one around at the moment with access to investigate further?
<stub> autovacuum settings have been made less agressive on production and staging. Its still more agressive than the default. I'll keep an eyeball on it to see if it needs tweaking up or down further.
<ubottu> Launchpad bug 388825 in rosetta "UnknownTimeZoneError on various pages" [Critical,Triaged] https://launchpad.net/bugs/388825
<stub> The autovacuum change was prompted by seeing hung autovacuum jobs on staging (again) and reports of testrun failures from possibly hung vacuum processes (again). Vacuum is much nicer under PG 8.4, so I suspect we will live with it or work around it for a few months as getting anything useful for upstream will be a pain.
<stub> Erm... wrong bug.
<Ursinha> :)
<stub> Bug #352965
<ubottu> Launchpad bug 352965 in launchpad-foundations "Update Storm" [Medium,In progress] https://launchpad.net/bugs/352965
<stub> PG 8.4 RC1 is out now, yay.
<danilos> stub: are we doing any testing with PG 8.4? is it worth starting it?
<stub> Not much point until release - we only do pretty standard stuff, so unless we run it on production we are unlikely to find anything other will not find too.
 * herb suspects it's unlikely we'll move to 8.4 until the next LTS, unless it's going to be backported to hardy.
<herb> of course I can be outvoted on that.
<stub> It needs to be backported to hardy or 8.3 supported under LTS anyway or upgrades will be difficult.
<stub> Anyway - no need to make that call yet.
<danilos> yeah, let's move on; Ursinha? :)
<Ursinha> danilos, I'm seeing people discuss about that
<Ursinha> because it's important, but as stub said, no need to make that call yet
<Ursinha> moving on then, per danilos request :)
<danilos> perhaps another question first :)
<Ursinha> next topic is the end of this meeting
<danilos> stub: what's going to happen with storm upgrade? post 2.2.6 or will you try to figure it out?
<stub> It is out of my hands - needs people with buildbot access to investigate further.
<danilos> stub: ok, thanks
<stub> The branch is ready and waiting to land (again)
<Ursinha> stub, who could help you with that?
<danilos> stub: perhaps we can test it on staging today even if it's not landed?
<Ursinha> testing, that is
<danilos> stub: I'd hate to have a change that big land (I am referring to storm upgrade itself) without proper QA for 2.2.6
<Ursinha> +1
<stub> Ursinha: I've assigned the bug to Francis. As far as I'm aware, only Francis and Gary have the required buildbot access to look further. If other people also have access and the debugging skills, they can look at it too.
<stub> There is no reason we can't test it on staging if we want.
<Ursinha> stub, good.
<stub> Someone can make another attempt at switching from buildout back to keeping storm in sourcecode if they want - I just tried and failed, but it is new to me too.
<Ursinha> stub, I see, I'll talk to flacoste about that later today
<Ursinha> anything else here?
<Ursinha> [action] talk to flacoste about buildbot and storm updating for testing when he's available today
<MootBot> ACTION received:  talk to flacoste about buildbot and storm updating for testing when he's available today
<Ursinha> okay
<Ursinha> let's finish this
<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:33.
<Ursinha> thanks guys
<danilos> Ursinha, all, thanks
<herb> thanks Ursinha
#launchpad-meeting 2010-06-23
<henninge> date -u
<henninge> ;-)
#launchpad-meeting 2011-06-21
<deryck> ok....
<deryck> we can just meet without all the formal meeting begin stuff. :)
<deryck> henning is away today unexpectedly if you all didn't know yet.
<abentley> deryck: sounds like you're having an interesting day.
<deryck> abentley, dude!  A rough start, but it's all good now.
<abentley> deryck: yes, he said something to us.
<deryck> the 5-10 mins late was my own fault, as usual.  the keys were Wendy's :)
<deryck> So let's start with landing lane....
<deryck> adeuring, I see you finished up that work yesterday.  Is it in ec2 or buildbot at this point?
<adeuring> it's in ec2; I had to fix a failing test
<deryck> ok, cool.
<deryck> and now you're on to a new bug.  a timeout again?
<adeuring> right
<adeuring> deryck: 'll ask you to run an Explain analyze"
<deryck> adeuring, ok, cool.  I can do that whenever you need.
<adeuring> cool, thanks
<deryck> thanks again for taking on another timeout! :)
<deryck> abentley, and your work is in the process of landing too?
<adeuring> timeouts are fun :)
<abentley> deryck: I've just fixed the failing tests, so I'll get it landing after the stand-up.
<deryck> abentley, ok, great.  and the on to some new bug, I assume?
<deryck> s/the/then/
<abentley> adeuring: I'm glad you think so, because we're running out of anything but timeouts.  Maybe you can teach me.
<abentley> deryck: Gonna focus on the presentation for now.
<deryck> abentley, ah, right.  Good call.
<deryck> abentley, and can we move our call either later today or later in the week, being that I can't get in my own office yet? :)
<adeuring> abentley: sure, but my method is mainly: stare long enough at the OOPS report, if things aren't obvious :)
<abentley> deryck: of course.
<deryck> abentley, great, thanks.
<deryck> adeuring, actually, I think you have a good sense of how to track down timeouts.  a very practical approach....
<adeuring> deryck: mybe, but it's hard to explain...
<deryck> adeuring, you should consider sharing you approach more widely.  start with abentley, of course. :)
<abentley> deryck: the presentation is mainly why I'm interested in YUITestLayer right now.
<deryck> abentley, right.
<adeuring> sure, I'll try...
<deryck> so that brings me to me.... :)
<deryck> I'm trying to land some YUI test improvements I did at Velocity but can't run them like abentley because of seq fault....
<deryck> so I'll try working with sinzui more today and get that resolved.
<deryck> then I'll land my work, when I'm sure it's actually helped.
<deryck> I also have a presentation to work on, and some email/blogging to follow up from the conference last week.
<deryck> that's it for me, I think.
<abentley> Me too.
<deryck> adeuring, anything else?
<adeuring> no
<deryck> adeuring, abentley -- great, thanks guys! Have a great day.
<adeuring> abentley: bug 799785 (what I'm working on) is for a start obvious: one SQL statement needs 9 seconds or so. I have no clue what's wrong with the statement, so I'll ask deryck to run an "explain analyze".
<ubot5> Launchpad bug 799785 in Launchpad itself "Timeout when trying to set the translation focus for Ubuntu" [Critical,In progress] https://launchpad.net/bugs/799785
<abentley> deryck: you too.
<adeuring> abentley: next step will be to see what postgresql tell me.
<deryck> thanks!
<deryck> adeuring, abentley -- do you guys mind moving the timeout/tech discussion back to #launchpad-dev?
<deryck> others could find this useful.
<adeuring> ah, right ...
