#launchpad-meeting 2008-07-02
<barry> #startmeeting
<MootBot> Meeting started at 09:01. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> yay!
<barry> hi everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
<allenap> me
<sinzu1> me
<salgado> me
<bac> me
<sinzui> me
<bigjools> me
<EdwinGrubbs> me
<BjornT> me
<flacoste> me
<intellectronica> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>   * cprov mentor, abentley mentor
<barry>  * Review process
<barry>   * Ensure that all outgoing http connections go through a proxy (intellectronica)
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<barry> += week(1) ?
<cprov> me
<barry> same time and place next week
<barry> anybody know they will not be there?
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * intellectronica to file bug on lint issue regarding elementtree import
<intellectronica> sorry, didn't yet
<intellectronica> nor did i add any checlist items for js
<barry> intellectronica: cool, we'll carry it over
<barry> intellectronica: k
<barry>  * gmb to update PythonStyleGuide for long argument lists (use The Salgado Way)
<barry> is gmb here today?
<sinzui> That was done
<intellectronica> no, he's on leave
 * sinzui should have removed it from the agenda
<barry> intellectronica: k, thanks.  sinzui, thanks, np
<barry>  * barry to ask lifeless to summarize what he knows about the PQM Mysteries (e.g. autopacking bug losing branches)
<barry> not done
<barry> [TOPIC]  * Queue status
<MootBot> New Topic:   * Queue status
<barry> i don't really have anything on this today.  any comments from y'all on either the pqm queue or PR queue?
<barry> guess not :)
<barry> [TOPIC]  * Mentoring update
<MootBot> New Topic:   * Mentoring update
<barry> so, abentley definitely wants to start up soon as a reviewer, and i'm all for that.  he needs a mentor.  any volunteers?
<barry> okay, i'll do it
<cprov> barry: well, so do I.
<barry> also, and i haven't talked to cprov yet about this, but your name came up too.
<barry> cprov: right, we need a mentor for cprov.  can someone in his timezone volunteer?
<intellectronica> maybe allenap and i can co-mentor? it's a bit easier, since we share the shift
<allenap> I'm happy with that.
<intellectronica> we're a bit earlier than him, so if there's an american that can do it maybe it's better
<cprov> intellectronica: allenap: I'd more than happy to follow you both.
<salgado> intellectronica, you're a bit later than him, in fact
<intellectronica> of course, i forgot that :)
<sinzui> the Americans are harder?
<cprov> salgado: I'll be back to BR in August.
<flacoste> is'nt cprov in +0200 these days
<bigjools> but only for 2 more weeks!
<intellectronica> cprov: i'm sure you'll graduate by then ;)
<barry> :)
<cprov> intellectronica: ehe, couldn't start any better ;)
<barry> intellectronica, allenap i'm okay with that if you and cprov are.
<cprov> +1
<allenap> +1
<barry> great, thanks!
<intellectronica> +1
<bigjools> two mentors, is this a first? :)
<barry> bigjools: it is!
<intellectronica> two senators
<barry> bigjools: that just means intellectronica and allenap have to be doubly hard on cprov :)
<bigjools> so he should graduate in double quick time!
<barry> bigjools: or take twice as long
<cprov> barry: why ?
<barry> cprov: i'm kidding
<barry> [TOPIC]  * Review process
<MootBot> New Topic:   * Review process
<bigjools> please don't leave him in a gibbering mess, I need him to fix Soyuz bugs :)
<barry> :-D
<cprov> barry: uhm, I just thought you would come with a funny reason, nevermind ...
<barry> cprov: i'm limited to one joke per meeting, if i'm lucky
<barry>   * Ensure that all outgoing http connections go through a proxy (intellectronica)
<barry> intellectronica: you have the floor
<intellectronica> so, on production, we can only make http connections to the outside world via a proxy
<intellectronica> but time and again we get code in that doesn'y handle proxies well
<intellectronica> since we can't really test this, we must pay attention in reviews when we notice code that makes connections to the outside world and make sure that it works via proxies
<bigjools> what sort of problems arise?
<intellectronica> ehm ... we can't connent?
<sinzui> bigjools: timeouts
<bigjools> ok - terminal problems then :)
<cprov> intellectronica: do you remember any example ?
<allenap> The most recent problem was using xmlrpclib.
<allenap> It doesn't cope with proxies.
<flacoste> really?
<intellectronica> cprov: i'm currently working on one
<allenap> And just hits its shiny head on the inside of the firewall.
<intellectronica> flacoste: yeah, xmlrpclib sux
<barry> intellectronica: i wonder if a better xmlrpclib could be built ontop of httplib2?
<intellectronica> barry: there's a python bug, and a patch to fix it
<intellectronica> so hopefully not before long
<flacoste> ok, it seems you need a custom TRansport for this
<bac> intellectronica: can you point us to an example of what is the right way to do it?
<intellectronica> flacoste: yeah, that's exactly my fix
<flacoste> but i think this points to another problem
<flacoste> we are lacking tests for things that connects to the outside
<flacoste> "in end-to-end" kind of way
<intellectronica> bac: there's no right way to do it. we simply have to scrutinise any new code that makes http connections to the outside world and ask questions
<barry> intellectronica: can you forward to me the bug #?
<cprov> can we use pylint to find out callsites using xmlrpclib with bare HTTPTransport ?
<intellectronica> flacoste: indeed. but it's quite difficult to test, since we need to block normal connections
<bac> and by "outside" you mean outside the data center.  this doesn't affect connections to niobium
<barry> intellectronica: i might be able to at least convince the python RM to sneak it into py2.6 <wink>
<flacoste> well, it's not a xmlrpclib problem pe-se
<flacoste> right
<intellectronica> cprov: i wouldn't worry too much about rpclib specifically. this is a general problem
<intellectronica> barry: see https://bugs.edge.launchpad.net/malone/+bug/243634
<cprov> or in fact, monkey patch HTTPTransport in a way it couldn't be used.
<ubottu> Launchpad bug 243634 in malone "ExternalBugTrackers that use XML-RPC need an XML-RPC transport that can work across proxies" [Critical,In progress]
<cprov> intellectronica: yes, it might be too much trouble.
<barry> intellectronica: thanks
<intellectronica> and since we don't really open connections to the outside world in the test suite, i don't think there's any automated way to do that. we simply have to pay attention to that
<intellectronica> welcome
<barry> intellectronica: is there some way we can catch and elevate these bugs when testing on staging?
<intellectronica> barry: i don't understand your question
<flacoste> well
<intellectronica> on staging, things won't work
<flacoste> we could have a proxy that has to be used wihtin the test suite
<flacoste> to show that connections to the "outside" world are proxied
<intellectronica> flacoste: and what if we don't use it? how would the test fail?
<flacoste> well, the test has to show that it goes through a proxy
<barry> flacoste: yes
<intellectronica> that's a nice idea, actually
<flacoste> but i guess this is just icing over your initial comment
<flacoste> which is reviewers: pay attention to the proxy issue
<flacoste> if we had a standard way to show that it was handled, it would be easier
<flacoste> but reviewers would still have to spot a missing test
<intellectronica> yeah, i don't think there's much more to say about this issue other than that
<barry> intellectronica: please send a message to the mailing list on this issue and please add a note to TIpsForReviewers
<intellectronica> barry: ok
<barry> [ACTION] intellectronica to communicate on ml and wiki about watching for outside connections
<MootBot> ACTION received:  intellectronica to communicate on ml and wiki about watching for outside connections
<barry> thanks
<barry> that's everything on the agenda.  does anybody have anything /not/ on the agenda?
<barry> that sounds like a no.  okay everybody, thanks!  we're done 15 minutes early today
<barry> #endmeeting
<MootBot> Meeting finished at 09:31.
<bigjools> thanks barry
<intellectronica> thanks barry
#launchpad-meeting 2008-07-03
<matsubara> me
<statik> em
<barry> d'oh... ray...
<bigjools> fartso
<Rinchen> #startmeeting
<Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<MootBot> Meeting started at 13:01. The chair is Rinchen.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Rinchen> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<mrevell> me
<schwuk> me
<bigjools> me
<Rinchen> yo
<herb> me
<cprov> me
<barry> me
<mthaddon> moi
<al-maisan> me
<salgado> me
<mars> me
<BjornT> me
<thumper> me
<matsubara> me
<Rinchen> mpt, ?
<statik> me
<mpt> me
<EdwinGrubbs> me
<adeuring> me
<flacoste> me
<Rinchen> apologies from kiko, allenap, gmb
<danilos> me
<danilos> apology from jtv as well
<Rinchen> I'm also guessing Steve is not available either
<Rinchen> so releases is here
<rockstar> me
<Rinchen> bugs is here
<thumper> abentley: ?
<leonardr> me
<abentley> me
<Rinchen> bac, EdwinGrubbs ?
<statik> bac is getting some food, i'm sure he'll be joining soon
<mpt> SteveA_ says "I'm attending in spirit"
<Rinchen> thumper?
<EdwinGrubbs> I already me'ed
<statik> Edwin is already here
<thumper> Rinchen: I said me :)
<Rinchen> thanks EdwinGrubbs
<rockstar> thumper me'd
<Rinchen> ok, I'm *really* tired.
<BjornT> intellectronica: ping
<intellectronica> me
<Rinchen> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (Matsubara)
<Rinchen>  * Critical Bugs (Rinchen)
<Rinchen>  * Bug tags
<Rinchen>  * Operations report (mthaddon/herb)
<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> [TOPIC] Next Meeting
<MootBot> New Topic:  Next Meeting
<Rinchen> 10th, same time same place.
<matsubara> Rinchen, I won't be around
<Rinchen> thanks
<Rinchen> anyone else?
<thumper> I may not be around
<schwuk> I won't be here - School Governor's meeting
<Rinchen> kiko and steve are also not here that week
<danilos> I wonÄt be around
<danilos> ok, that's Serbian Latin keyboard
<Rinchen> thanks
<danilos> I won't be around for the next 3 weeks (guadec then holidays)
<Rinchen> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<Rinchen> none
<Rinchen> [TOPIC] Oops report (Matsubara)
<MootBot> New Topic:  Oops report (Matsubara)
<matsubara> Hi, this is just a heads up for next week. I'd like to keep two oopses in the radar:
<matsubara> https://bugs.edge.launchpad.net/blueprint/+bug/244957 and https://bugs.edge.launchpad.net/malone/+bug/245260
<ubottu> Launchpad bug 244957 in blueprint "time out linking blueprint dependencies" [Undecided,New]
<matsubara> apart from that, I'll continue with the usual nagging based on the CurrentRolloutBlockers
<matsubara> thanks everyone for the effort on fixing the outstanding issues. I really appreciate
<Rinchen> I hear sinzui (who's not here) has volunteered to help next week
<matsubara> that's all Rinchen
<matsubara> yes, Curtis is going to back me up while I'm on vacation
<Rinchen> excellent, many thanks to him!
<Rinchen> thanks matsubara
<Rinchen> [TOPIC] Critical Bugs (Rinchen)
<MootBot> New Topic:  Critical Bugs (Rinchen)
<Rinchen> we have a few but I know the status of them all
<Rinchen> they are actively being merged into a branch destined for PQM
<Rinchen> So I won't cover them here
<Rinchen> Are there any questions about any of these?
<Rinchen> https://edge.launchpad.net/launchpad-project/+bugs
<sinzui> me
<Rinchen> :-)
<Rinchen> Ok, since I have the floor...
<Rinchen> after bigjools's branch lands, RC is closing
<Rinchen> pqm will open
<Rinchen> (after the update of course)
<thumper> eta?
<Rinchen> 2 hours at least
<BjornT> Rinchen: we're not waiting for that storm fix?
<salgado> BjornT, already landed
<Rinchen> BjornT, there are 2
<Rinchen> 1 is landed, other is in bigjools branch
<Rinchen> (the librarian patch)
<BjornT> ah, cool. misread the e-mail sent to the list
<Rinchen> I'm just missing the review for EdwinGrubbs branch and we'll be set
<bigjools> it's probably a good idea if someone else lands it, as I am going out right after the meeting
<sinzui> BjornT: You mean flacoste's twisted email?
<Rinchen> any volunteers?
<BjornT> sinzui: yes
<cprov> bigjools: I can land it.
<bigjools> the branch is pushed to devpad and the commit message is on CRB
<flacoste> BjornT: no, that won't be fixed today
<Rinchen> thanks cprov
<cprov> bigjools: I will be around 'forever'.
<bigjools> thank you cprov
 * bigjools thinks that cprov is really a robot who doesn't sleep
<Rinchen> if the branch fails, I'm currently thinking of resubmitting it and holding off on the update
<Rinchen> anyway, stay tuned to normal channels
<Rinchen> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<Rinchen> we have none
<Rinchen> proposed
<flacoste> bigjools, the story is that coffee is what actually runs in his veins
<cprov> :)
<Rinchen> [TOPIC] Operations report (mthaddon/herb)
<bigjools> lol
<MootBot> New Topic:  Operations report (mthaddon/herb)
<herb> Our new OSA in AU started this week. Welcome spm to the team.
<Rinchen> welcome spm!
<herb> Early Tuesday (2008-07-01) 1.2.6 was rolled out.
<herb> Yesterday we did a secondary roll out and we have another tentatively scheduledfor today.
<herb> Yesterday a couple of app servers died seemingly without error. I collected logs and notified Rinchen. I didn't file a bug report and we haven't seen any such problems today.
<herb> That's it for mthaddon, spm and me this week unless there are any questions.
<mrevell> hi spm
<bigjools> hi spm!
<al-maisan> hello spm !
<mars> hi spm, welcome to the team!
<thumper> it is 4am for spm :)
<matsubara> welcome spm!
<Rinchen> herb, it will be really interesting to see if we have any of those after today's (Hopeful) update
<barry> spm: there's no sleeping here!
<danilos> wake up spm!
<mthaddon> he'll be in in about 3 hours :)
 * flacoste channels the irc2dream bot
 * thumper is SO pleased to have an OSA in AU
<Rinchen> thanks herb
<Rinchen> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<stub> The Storm switch caused a load jump on the main db server. Plenty of landings have been made migrating the worst offending pages to storm native code or just fixing whatever issue was caused by the migration.
<stub> This extra load of course slowed down other pages too, pushing them over the edge so pages that where previously slow became timeouts.
<stub> In hindsight we should have been able to avoid this by tuning the soft timeout on edge and chasing them to zero rather than just worrying about the hard timeouts.
<stub> Load is back at more acceptible levels now most of the time. Load of 6-8 is fine. When we spike to 10 things start sucking. We get a couple of spikes during the day when load goes over 12, with the worst offender being the 6:00 UTC load of 20 spike. I can't see what that is from the debug logs, so will need to watch when it happens.
<stub> And that is all I've typed so far...
<Rinchen> Anything else for stub?
<stub> I thought my network had died ;)
<stub> Just the conversation.
<Rinchen> stub, you'll be around at 6am UTC today to have a look?
<stub> Yer - after my coffee and everything.
<Rinchen> thanks
<Rinchen> [TOPIC] Sysadmin requests (Rinchen)
<Rinchen> Is anyone blocked on an RT or have any that are becoming urgent? I know about Thumper's, JML's two, and Soyuz P3A.
<MootBot> New Topic:  Sysadmin requests (Rinchen)
<Rinchen> ok, that was easy :-)
<Rinchen> [TOPIC] New packages required (salgado
<MootBot> New Topic:  New packages required (salgado
<Rinchen> )
<salgado> anything for this week?
<salgado> I hope not
<Rinchen> dearly hope not
<thumper> salgado: do we have the new loggerhead dependencies?
<salgado> thumper, no
<thumper> salgado: I'll email you later
<salgado> thumper, I need a bug against meta-lp-deps and an RT
<thumper> k
<Rinchen> anything else for salgado ?
<Rinchen> thanks salgado
<Rinchen> [TOPIC] A top user-affecting issue (mrevell)
<MootBot> New Topic:  A top user-affecting issue (mrevell)
<mrevell> The main user-affecting issue this week has clearly been that some people have been unable to access their Launchpad accounts. When attempting to log in, Launchpad has given them the error message "This account cannot be used".
<mrevell> I understand sinzui has been working on this and that we should expect the fix imminently.
<sinzui> mrevell: correct
<mrevell> Other than that, we've had our usual batch of "please unsubscribe" me requests.
<sinzui> mrevell: The final fix will be rolled out today
<mrevell> Great, thanks sinzui
 * Rinchen crosses his fingers.
<mrevell> Unless we need to discuss either issue, back to you Rinchen
<mpt> mrevell, how many of those do you get per week?
<mrevell> mpt: Unsubscribe requests?
 * sinzui crosses his eyes and toes
<mpt> mrevell, and how many of those are subscribed to all Ubuntu bug reports?
<mpt> mrevell, yes
<mrevell> mpt: Most of them are structural subs to Ubuntu and I'd say I get four a week, sometimes more.
<mrevell> mpt: They have no idea how to unsubscribe, but we've discussed that here before.
<mpt> Maybe that could be taken into account in prioritizing the relevant fixes
<mpt> thanks mrevell
<Rinchen> [TOPIC] Doc Team report (mrevell)
<MootBot> New Topic:  Doc Team report (mrevell)
<mrevell> I posted a Blueprint section of the user guide to the team list. All feedback appreciated, but I understand it's a busy time.
<mrevell> Thanks to everyone who's sent feedback on the latest revision of the tour to hit the team list. All feedback gratefull received.
<mrevell> That version of the tour content is slightly out of date, so I'll send a revised version soon.
<mrevell> No actual doc team news this week.
<mrevell> Thanks Rinchen.
<Rinchen> thanks mrevell ....just punt the files to me and I'll refresh
<mrevell> ok, thanks Rinchen
<Rinchen> ok, and one last item.....before we go
<Rinchen> [TOPIC] New MOTU Rep - mrevell
<MootBot> New Topic:  New MOTU Rep - mrevell
<mrevell> As you may know, Jordan Mantha is taking a break from Ubuntu-related activities. As a result, he's no longer our MOTU liaison. Instead, Reinhard Tartler (siretart) has stepped up to the job. Unfortunately, he can't join us this evening as he has a LUG meeting.
<mrevell> He'd like to improve communication between LP and MOTU and would like to try out a regular meeting. I've posted details to the team list.
<mrevell> I'd be grateful if you could think of ways in which we can make use of Reinhard's time in order to improve the way we work with MOTU.
<mrevell> Thanks Rinchen and everyone.
<Rinchen> Thanks mrevell.
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
<Rinchen> #endmeeting
<MootBot> Meeting finished at 13:26.
<Rinchen> not a record finish but early!
<thumper> OMG
<thumper> thanks Rinchen
<mrevell> :) Thanks Rinchen
<barry> Rinchen: wow, thanks.  i aspire to keeping the reviewer's meetings as short :)
<bac> me
<salgado> bac, just 1h late. ;)
<bac> salgado: yeah.  but it only took me 10 minutes to read the backlog!
<CWii> Did I miss the meeting?
<CWii> Yeah, I did :(
 * CWii reads the logs
#launchpad-meeting 2008-07-04
<bigjools>  /msg NickServ
<bigjools> fail
#launchpad-meeting 2009-07-01
<noodles775> me (just to get in early)
<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 meeting.  who's here today?
<rockstar> ni
<adeuring> me
<noodles775> yup
<henninge> me
<intellectronica> ×× ×
<sinzui> me
<deryck> me
<gmb> me
<barry> good one intellectronica :)
 * gmb keeps needing to remind himself that it's not a problem with X when intellectronica has his keyboard in Hebrew mode.
<cprov> me
<danilos> me
<mars> me
<leonardr> me
<bac> me
<mars> barry, flacoste sends his apologies, he is celebrating Canada's birthday today
<barry> mars: thanks
<barry> allenap: ping
<barry> bigjools: ping
<BjornT> me
<mars> barry, and gary is off sick
<barry> BjornT: ping
<barry> mars: k, thanks
<allenap> me
<barry> EdwinGrubbs: ping
<EdwinGrubbs> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> * Roll call
<barry>  * Action items
<barry>  * Mentoring update
<barry>  * jtv: if code catches {{{Exception}}}, make sure {{{KeyboardInterrupt}}} and {{{SystemExit}}} are not swallowed.
<barry>  * Peanut gallery (anything not on the agenda)
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * intellectronica to email list about higher JS branch limits
<intellectronica> sorry, i didn't
<barry> k
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> first, let's welcome leonardr to our cabal!
<leonardr> thanks, barry
<rockstar> leonardr did great last week.  He'll be graduating in no time.
<gmb> barry: And deryck
<barry> gmb: you type faster than me :)
<gmb> :)
<barry> and deryck
<jtv1> me
<henninge> jtv1: you're not deryck
<bigjools> me, sorry
<barry> also, noodles775 you're graduated!  cprov has nothing but glowing reports.  congratulations
<noodles775> great! Thanks barry!
<cprov> noodles775: congrats!
<danilos> woohoo, noodles775 congratulations!
<henninge> noodles775: GlÃ¼ckwunsch!
<noodles775> And thanks cprov for all the time you spend helping me :)
<intellectronica> congratulations noodles775!
<noodles775> Cheers everyone :)
<bigjools> felicitats
<jtv> congratulations noodles775
<barry> noodles775: you can stay on thursdays/euros or switch to monday or friday if you want.  you're call and just ping me after the meeting if you want to rearrange your schedule
<noodles775> barry: will do, thanks.
<barry> does anybody have any other mentoring items today?
<barry> k, moving on...
<barry> [TOPIC]  * jtv: if code catches {{{Exception}}}, make sure {{{KeyboardInterrupt}}} and {{{SystemExit}}} are not swallowed.
<MootBot> New Topic:   * jtv: if code catches {{{Exception}}}, make sure {{{KeyboardInterrupt}}} and {{{SystemExit}}} are not swallowed.
<barry> jtv: this will go away in python 2.5 :)
<jtv> Hmm, that wiki markup doesn't look half as good on irc
<jtv> barry: are we there yet?  :-)
 * barry looks to flacoste and gary... damn!
<mars> jtv, barry, why not add a lint tool warning for "catch Exception"?
<jtv> There is one, actually.  But it's not clear what it wants you to do.
<mars> jtv, ah, fix the string it spits back at you?
<jtv> But yes, corollary: once we've upgraded, maybe that should go away :-)
<barry> does anybody not know what we're talking about here?
<mars> saying "This is bad" is one thing, saying "This is bad, ensure foobar" is another
<jtv> mars: right, it just notes that you're catching Exception.  Which isn't the surprising part.
<mars> :)
<intellectronica> is there an easy, or at least obvious, way to do that?
<intellectronica> or should you simply never catch Exception?
<barry> intellectronica: until py2.5, you need separate except (KeyboardInterrupt, SystemExit) clause
<barry> intellectronica: catching Exception is way better than a bare except (usually)
<barry> intellectronica: except that in py2.4, "except Exception" catches KI and SE exceptions too
<barry> in 2.5 the exception hierarchy was rearranged so that KI and SE are siblings of Exception, not children
<barry> BaseException is the mother of all exceptions, and it rarely needs to be caught
<intellectronica> so, except KI: raise \n except SE: raise \n except Exception: stuff... ?
<barry> intellectronica: yep, or except (KI, SE): raise
<bigjools> can we just upgrade Python already ...
<barry> bigjools: yes please
<sinzui> We need more eggs I think
<jtv> bigjools: can you have it ready by Monday?
<adeuring> i think an "except Exception" is in most cases bad as well:, unless you log an OOPS
<bigjools> jtv: I'll get my wife to do it
<gmb> adeuring: +1
 * barry hopes we do it before the open source release
<cprov> adeuring: right, I think that's the rule.
<rockstar> adeuring, +1
<jtv> it's right, but we have a few scripts that don't do that.
<barry> adeuring: certainly, if you as a reviewer see "except Exception" or <gasp> bare-except, you should ask lots of questions
<adeuring> barry: right; but it can't hurt to update the wiki page ;)
<jtv> barry: right, that is the real point here.
<barry> adeuring: sure.  would you or jtv like to take that action?
<adeuring> barry: I'll do it
<barry> adeuring: thanks
 * jtv bows to adeuring who beat him to the
<jtv> *ow!
<barry> [ACTION] adeuring to update wiki to describe 'except Exception'
<MootBot> ACTION received:  adeuring to update wiki to describe 'except Exception'
<barry> adeuring: please also do include info on KI and SE, and that py2.5 changes things
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<adeuring> barry: I'm already wrote a note about that ;)
<barry> that's everything on the agenda, does anybody have any other topics today?
<barry> adeuring: thanks :)
<barry> 5
<barry> 4
<mars> barry, me
<barry> mars: go ahead
<mars> so yesterday we had an issue with unescaped HTML data appearing in the browser
<mars> the fix was to remove a "structure foo" statement from the TAL template
<mars> given that the TAL "structure" statment is potentially dangerous, should it raise a lint warning?
<intellectronica> mars: Â no, it's used legitimately way too often
<danilos> intellectronica: +1
<bac> intellectronica: +1
<mars> ok
<mars> barry, that's all then :)
<barry> mars: thanks
<barry> anything else guys?
<barry> 5
<jtv> oh come on already, we've been through that!
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 09:23.
<jtv> thanks barry :)
<barry> thanks everythone
<intellectronica> cheers barry
<barry> #startmeeting
<MootBot> Meeting started at 17:29. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> thumper, mwhudson hi
<thumper> hi
<barry> mwhudson: wanted to speed through today's meeting, so shall we start with a recap of ameu?
<barry> noodle graduates, deryck and leonardr are new mentats
<thumper> barry: yep, I ready the backlog :)
<barry> thumper: ah cool.  i don't need to explain "except Exception" then :)
<thumper> not to me
<barry> i'm sure not to mwhudson either
<barry> other than that. i have nothing on my list.  do you or mwhudson have anything?
<thumper> one thing
<thumper> the other day stub landed a method to help printing unicode in doctests
 * thumper looks for the method
<thumper> hmm...
<thumper> I recall a commit flying past, but I can't see it in pages.py
<barry> it rings a vague memory
 * thumper checks loggerhead
<mwhudson> hi oops sorry
<thumper> hmm, can't find it right now
<mwhudson> barry: what was it about except Exception?
<mwhudson> oh right
 * mwhudson read enough backscroll
<thumper> r8714
<barry> mwhudson: cool
<thumper> added to doctest but not pages
<barry> that always drives me crazy that they have different globs
<thumper> a bug should be filed :)
<thumper> also it needs to move to lp.testing
<barry> thumper: jfdi man!
<mwhudson> barry: i heard a rumour that all javascript changes are supposed to be QAed before landing or something
<mwhudson> barry: do you know anything about that?
<barry> mwhudson: we talked about that on the list a few weeks ago, but i don't know that anybody has actually done that
<mwhudson> ok
<mwhudson> over this side of the world it sometimes seems like decisions on process get made but that noone tells us :)
<barry> mwhudson: we only do that when we don't follow those decisions ourselves :)
<barry> but yeah, i hear ya.  hopefully these meetings can help that
<barry> anything else guys?
<thumper> nope
<mwhudson> barry: i guess a single place on the wiki to go and look this sort of thing up would be good
<mwhudson> barry: maybe there is one already!
<mwhudson> barry: nothing else
<barry> mwhudson: agreed!  it should be here if anywhere: https://dev.launchpad.net/Reviews
<barry> cool.  thanks guys
<barry> #endmeeting
<MootBot> Meeting finished at 17:44.
 * mwhudson subscribes
<mwhudson> You are not allowed to perform this action.
<thumper> mwhudson: heh
 * mwhudson subscribes the other way
 * thumper subscribes too
#launchpad-meeting 2009-07-02
<matsubara> #startmeeting
<MootBot> Meeting started at 10:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<flacoste> me
<sinzui> me
<henninge> me/2
<herb> me
<matsubara> only half of you henninge ? :-)
<matsubara> stub, hi
<matsubara> rockstar, hi
<intellectronica> me
<matsubara> bigjools, hello
<rockstar> ni!
<bigjools> me
<henninge> matsubara: yes, sorry, concurrent meeting in #ubuntu-meeting
<matsubara> ok, everyone is here
<matsubara> Ursinha sends apologies as she's still ill
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (stub)
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>  * Ursinha to talk to flacoste about buildbot and storm updating for testing when he's available today
<matsubara> I've asked Ursinha and she did that
<matsubara> so, moving on
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<matsubara> I have 1 bug and 2 oopses for today. bug 394560 for malone, OOPS-1274A1231 for translations and OOPS-1274ED146 for registry
<ubottu> Launchpad bug 394560 in launchpad "LookupError: unknown encoding: processing email" [Undecided,New] https://launchpad.net/bugs/394560
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1274A1231
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1274ED146
<matsubara> who should I talk to to update ubottu oops urls?
<matsubara> [action] matsubara to chase owner of ubottu to update the oops url
<MootBot> ACTION received:  matsubara to chase owner of ubottu to update the oops url
<matsubara> intellectronica, I need to try to reproduce bug 394560 and add more info
<ubottu> Launchpad bug 394560 in launchpad "LookupError: unknown encoding: processing email" [Undecided,New] https://launchpad.net/bugs/394560
<rockstar> matsubara, you should chase the owner with a bit of wood.
<matsubara> intellectronica, once I do that, do you think you can assign someone for a fix?
 * intellectronica looking
<matsubara> rockstar, you mean like a club?
<flacoste> i hate to say this, but this looks like a Foundations issue :-(
<matsubara> hehe
<intellectronica> matsubara: sure, i'll assign to myself and investigate. i have no idea, off the top of my head, what the problem is
<matsubara> flacoste, intellectronica: ok, I'll try to reproduce the issue today and let you know. I'll move the bug to the right project accordingly
<rockstar> matsubara, :)
<flacoste> intellectronica: well, it seems that we are trying to decode the string
<flacoste> based on the encoding specified in the email
<flacoste> and that encoding is x-unknown
<flacoste> which of course doesn't exist
<flacoste> so i'd say from the face of it it's a client-side problem
<matsubara> [action] matsubara to reproduce bug 394560, add more info and work with team responsible to have it prioritized
<ubottu> Launchpad bug 394560 in launchpad "LookupError: unknown encoding: processing email" [Undecided,New] https://launchpad.net/bugs/394560
<MootBot> ACTION received:  matsubara to reproduce bug 394560, add more info and work with team responsible to have it prioritized
<henninge> matsubara: that oops is covered by bug 394224
<ubottu> Launchpad bug 394224 in rosetta "More unique constraints in updateTranslation" [High,Triaged] https://launchpad.net/bugs/394224
<matsubara> henninge, I see it's already triaged and prioritized, so thanks!
<intellectronica> flacoste: yeah, if that's the case then it's not a bug
<matsubara> sinzui, the other one is a OOPS-1274ED146 a timeout on team membership view
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1274ED146
<matsubara> sinzui, it's issuing > 3000 queries
<matsubara> so it probably can be optimized further
<matsubara> [action] matsubara to file a bug for OOPS-1274ED146
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1274ED146
<MootBot> ACTION received:  matsubara to file a bug for OOPS-1274ED146
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1274ED146
<intellectronica> flacoste: or maybe it's worth coercing x-unknown to None, if that's a common behaviour for mailers
<sinzui> This looks just like the timout for merging teams
<sinzui> matsubara: I will ask Edwin to look into this since the problem look identical
<matsubara> sinzui, thanks. once I have a bug for it I'll assign to him
<matsubara> sinzui, looking at the page where the oops happened, doesn't seem related to team merge
<sinzui> The two repeat queries are the same that I looked at two hours
<matsubara> I see. I'll file a bug anyway and can dupe later on to the team merge bug if that's the case
<matsubara> sinzui, thanks
<sinzui> matsubara: We have a systemic problem in that we do not have a standard method to get a lot of IPerson
<matsubara> sinzui, so the fix for the team merge one will include such a method?
<sinzui> No not at all, We need a big spec to fix a systemic problem
 * sinzui created a spec yesterday to end the nightmare of deactivated account being members or owners of other Launchpad objects
<matsubara> sinzui, by spec you mean a blueprint or a new story or something else?
<sinzui> I mean both. It is a project that requires lots of planning and breakdown into work
<matsubara> for the critical bugs: we have two, one in progress which the fix is ready (according to the bug report) and another one in Triaged state
<matsubara> bug 391903 and bug 390563
<ubottu> Launchpad bug 391903 in launchpad-code "Scanner user needs more database permissions" [Critical,In progress] https://launchpad.net/bugs/391903
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563
<matsubara> rockstar, do you know about the latter one? the lp-code bugtask is in triaged state
<rockstar> matsubara, so, there were two issues here, one client side, one server side.  The server side one has been fixed on Launchpad.
<matsubara> sinzui, all right. where are you keeping track of this work? I'd like to link bugs that might benefit from it to the spec
<stub> bug 391903 should probably not be critical - a patch and test update needs to land this cycle sometime. Production is fine at the moment.
<ubottu> Launchpad bug 391903 in launchpad-code "Scanner user needs more database permissions" [Critical,In progress] https://launchpad.net/bugs/391903
<sinzui> A blueprint. I have not scheduled it since my team may state it requires an infinite number of monkeys to complete
<matsubara> stub, is it not critical anymore because the permissions were granted on the production db?
<stub> I think so. The patch does have to land before next rollout though or that will revert. Does that count as critical?
<matsubara> sinzui, right. let me know the URL please
<flacoste> stub, matsubara: that should simply be high
<matsubara> I'll lower the importance. thanks flacoste and stub
<matsubara> rockstar, since it was fixed on LP, could you set the bug as fix released?
<sinzui> matsubara: systemic problems are not fixed in critical issues. I am mearly stating that I expect to continue to allocate staff to fix these timeout issues until we have new tools to get masses of users and teams from the db
<matsubara> s/bug/bugtask/
<matsubara> sinzui, the oops I brought to you today is not critical.
<rockstar> matsubara, I think there are some other things we're trying to track (like the client side issue), but I'll raise it in the standup today.
<sinzui> matsubara: So I do not need to fix this this cycle?
<matsubara> sinzui, what I'm trying to do is link those bugs to the blueprint, so when the systemic problem is fixed, we can fix the oopses with the new infrastructure (or at least consider those bugs while implementing the new infrastructure)
<matsubara> sinzui, I don't think they are critical, since it's a soft time out. I'm bringing the issue to you to keep it on your radar
<sinzui> matsubara: I must create a blueprint for this class of problem first
<matsubara> [action] sinzui to create a blueprint about the systemic problem in retrieving lots of IPerson and let matsubara know
<MootBot> ACTION received:  sinzui to create a blueprint about the systemic problem in retrieving lots of IPerson and let matsubara know
<matsubara> rockstar, thanks!
<matsubara> I think that's all for the oops & critical bugs section
<matsubara> thanks everyone
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<matsubara> herb, ?
<herb> Since I totally slacked off last week on the OSA report, I'll cover the last two weeks here.
<herb> 2009-06-24 - Production rollout to r2.2.6. Rollout took longer and caused unforseen downtime. Details can be found in the incident report.
<herb> 2009-06-26 - Cherry picked r8204 to codehost
<herb> 2009-06-26 - Cherry picked r8205 to lpnet*, edge* and the scripts server.
<herb> 2009-06-26 - Cherry picked r8701 and r8703 to lpnet* and (part of) soyuz.
<herb> Since the 2.2.6 rollout we've seen a slight uptick in load on the app servers and, early on at least, significant load on the code importers.
<herb> Staging has seen signifcant memory leaks. The app server has often been 5-10GB resident. This is a pretty bug that will clearly need to be resolved before we can push to production.
<flacoste> herb: it's because of the storm update, stub thinks he landed a fix today
<flacoste> herb: plan is to land this storm update on edge once it clears staging
<herb> flacoste: I figured. I'd like to see it running on staging for a couple of days without leaks before seeing it on edge.
<flacoste> herb: sure
<herb> cool
<matsubara> I'll assign bug 393990 to stub and move to -foundations.
<ubottu> Launchpad bug 393990 in launchpad "staging app server using too much memory" [Undecided,New] https://launchpad.net/bugs/393990
<flacoste> matsubara: that's actually a dupe
<herb> matsubara: that's probably a dupe of 390861
<herb> sorry #390861
<matsubara> bug 390861
<ubottu> Launchpad bug 390861 in launchpad-foundations "Appserver memory issues with Storm 0.14" [High,Triaged] https://launchpad.net/bugs/390861
<herb> dammit!
<herb> :)
<matsubara> ah, ok. so it's all fine
<flacoste> matsubara: bug 390861
<matsubara> well, not fine, but at least it's being tracked :-)
<matsubara> thanks herb and flacoste
<matsubara> let's move on
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> Staging is now hopefully running a non-leaking version of Storm (0.14 + r290 from lp:storm). Its been up for maybe an hour now with no sign of memory bloat, so it is looking promising. if all goes well, next step is to land this on launchpad/devel for testing on edge.
<stub> I repaired about 1300 invalid crosslinks between Person and EmailAddress as best I could. Hopefully these were caused by manual updates or since fixed bugs. The other 2.7 million records are fine. Admins or myself should be able to recover any lost permissions of branches if the reclaim account and merge processes don't suffice. garbo-nightly.py is growing detection of this case (code done, tests to go).
<stub> .
<matsubara> question to stub?
<matsubara> ok, I think that's all for today then.
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<herb> stub: is the permissions reclamation process documented?
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:35.
<matsubara> oops, sorry herb
<herb> no problem
<intellectronica> thanks matsubara
<stub> herb: No - it will depend what the problem is. Most people affected (assuming they are active users) should be able to recover things using their registered email addresses.
<herb> ok
<stub> herb: It should be like a forgotten password...
 * stub crosses fingers
<herb> heh. got it.
<sinzui> matsubara: https://blueprints.edge.launchpad.net/launchpad-registry/+spec/efficient-user-sets
<matsubara> sinzui, thanks
#launchpad-meeting 2010-07-07
<abentley> me
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> hi, whose here?
<bigjools> me
<sinzui> me
<gmb> me
<jtv> me
<bigjools> who's here, too :)
<bac> :)
<deryck> me
<jtv> nice cascade we had there
<mars> me
<EdwinGrubbs> me
<bac> bigjools: no, i found a very nice "here" and was wondering who'd claim it
<gary_poster> me
<henninge> me
<gary_poster> I'll take it
<noodles775> me
<gary_poster> well, it's probably not mine
<bac> well, let's get started then
<adeuring> me
<bac> not much on the agenda so we should zip right through
<bac>  * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>    * PQM commit messages: I don't f***ing care what you're currently listening to.  See also https://dev.launchpad.net/PQMCommitMessages [bigjools]
<bac>  * Peanut gallery
<bac> * jml(?) to set a policy on what can live in lib/lp, lib/services, and lib/coop
<bac> since bjornt left us, this item was assigned to jml...but i forgot to tell him about it, so clearly nothing was done.
<bac> my bad
<flacoste> me
<bac> sinzui: how goes your lint replacement?  good, no?
<sinzui> lint is queued for landing
<bac> \o/
<sinzui> I will send an email announcing this today
<sinzui> + instructions about embedding it in your editor
<bac> very nice, thank you.
<bac> as to new items we only have one
<bac> [topic] PQM commit messages: I don't f***ing care what you're currently listening to.  See also https://dev.launchpad.net/PQMCommitMessages [bigjools]
<MootBot> New Topic:  PQM commit messages: I don't f***ing care what you're currently listening to.  See also https://dev.launchpad.net/PQMCommitMessages [bigjools]
<bac> bigjools: the floor is yours.
<bigjools> well first, I was in a bad mood when I added that topic title, but I think you get the gist
<bigjools> the commit messages should follow the style guide
<bigjools> EOT
<sinzui> okay
 * sinzui stops work to change editor
<bac> any other thoughts?
<henninge> Is that spec up to date?
<henninge> e.g. Include bugs fixed in this landing. For each bug, include the bug number and the bug summary next to it. e.g. "Fixes: bug 12345: Mozilla Firefox lacks SVG support; bug 54321: Lack of spacing in new account form."
<ubot5> Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?) (affected: 0, heat: 3)" [Medium,Fix released] https://launchpad.net/bugs/12345
<ubot5> Launchpad bug 54321 in zope-archetypes (Ubuntu) "Please sync zope-archetypes 1.3.9-2 from Debian unstable (affected: 0, heat: 2)" [Undecided,Fix released] https://launchpad.net/bugs/54321
<henninge> I never do that, I thought that's what [bug=xxx] is for
<jtv> same here
<bac> henninge: you are correct
<bac> the guide is out of date
<abentley> henninge, agreed.  ec2 land and lp-land use your syntax.
<sinzui> bigjools, fixed
<bac> i'll fix it this week
<bac> thanks sinzui
<bigjools> sinzui: sorry, I didn't meant to pick on you specifically.  I've just seen some poor commit messages lately.
<bac> [action] bac to update https://dev.launchpad.net/PQMCommitMessages
<MootBot> ACTION received:  bac to update https://dev.launchpad.net/PQMCommitMessages
<sinzui> bigjools, I agree about the poor commit messages...I brought the issue up with Urshina when I was RM. There were 30 bugs un QAed and I could not say what they changed.
<gary_poster> we're working on that and will have a report at epic
<bigjools> totally
<bigjools> oh cool
<abentley> merge proposals have a slot for the commit message.  Maybe we should encourage people to fill it out as part of the review.
<bac> [topic] other stuff
<MootBot> New Topic:  other stuff
<bac> abentley: +1
<bigjools> +1
<bac> anything else to discuss today
<bac> ?
<gary_poster> benji is a new launchpadder
<gary_poster> he's doing new launchpaddy things now
<gary_poster> but he will be asking for reviews
<bac> great gary_poster
<gary_poster> and will eventually want to go through the mentat process
<henninge> I had a few issues come up in a recent review, let me pick one.
<bac> everyone should make an effort to say hi to benji this week
<gary_poster> +1, was hoping I could get him at this meeting
<henninge> Anybody ever heard a guideline "one assert per test" in functional test cases?
<bac> i have not
<abentley> henninge, no.
<henninge> The problem with multiple asserts is that the test will abort and the remaing asserts will not be executed.
<abentley> henninge, the problem with one assert per test is that set-up time increases.
<abentley> henninge, not to mention much more finger-typing.
<henninge> abentley: it's either that or smarter asserts.
<bac> and probably a less readable test
<gmb> henninge, I'm not clear on how the abort is really a problem. For a start, it means you get to fix one test failure at a time rather than having to dig through many.
<abentley> henninge, what's the disadvantage of having the test abort and not executing the remaining asserts?
<henninge> hang on
<henninge> Code like this:
<henninge> > +        self.assertEquals(1, len(result_set))
<henninge> > >>> +        self.assertEquals(self.ppa, result_set[0].archive)
<henninge> > >>> +        self.assertEquals(self.cell_proc, result_set[0].processorfamily)
<henninge> >>
<henninge> You can test all three conditions at the same time. You can see how many rows
<henninge> were returned instead and what their values are. Much more useful.
<henninge> The problem with multiple assert statements in one test method is that not all
<henninge> will be executed if one fails and you are missing valuable information that
<henninge> you can only gain by changing the test code and running the test again.
<henninge> For example, if result_set contained 2 instead of the expected 1 elements,
<abentley> And how often would the test have failed anyway, because the remaining asserts assume the first assert passed?
<henninge> you'd want to know what the two contain but this test would not even tell you
<henninge> what the first contains because the asserts don't get called.
<bigjools> abentley: point
<abentley> henninge, so in your example, what if len==0?
<henninge> abentley: sure, we should just make sure that is really the case. The dependency i mean.
<henninge> The example is missing my proposed solution which would be comparing lists.
<abentley> henninge, and since you're getting results you're not expecting, how do you know that result_set[0] is testing the right thing?
<henninge> if len == 0, the list would be empty.
<adeuring> you can have a test for "method X changes A into B". The test may need something like "assert(A); do_something(); assert(B)".  "assert(A)" may not be strictly needed, but it can help to ensure that you have a proper test setup.
<abentley> henninge, right, and the rest of the asserts will raise IndexError.  Which seems like meaningless exceptions to me.
<henninge> My suggestion:
<henninge> result = [(row.archive, row.processorfamily) for row in result_set]
<henninge> self.assertEqual([(self.ppa, self.cell_proc)], result)
<henninge> From the review^
<henninge> abentley: there are no other asserts to fail.
<abentley> I thought self.assertEquals(self.ppa, result_set[0].archive) is an assert that would fail
<henninge> abentley: with len== 0? yes
<bac> henninge: i like your suggestion in this instance.  i don't think we'd want to generalize to a restriction of one assert per test case as other situations may not lend themselves so nicely.
<abentley> henninge, If we followed a "one assert per test" rule, we might have the same test three times, with the different asserts.
<henninge> I was not proposing a rule
<bac> ok, i see you said 'guideline'.
<henninge> just to have people think about smart asserts.
<abentley> henninge, sorry, *guideline*
<abentley> henninge, I like your solution.
<abentley> henninge, but if you hadn't thought of it, I don't think applying the guideline would make sense.
<sinzui> I recall the reason for "one assert per test" was not 10 asserts in a test, but that the test was actually several tests.
<abentley> henninge, because it would multiply the number of tests and failures in ways that are not useful.
<henninge> just make sure that functional tests suffer not from similar dependency problems like doctest might do.
<sinzui> When an object is transitioned to a new state, it may be legitimate to very 3 aspects of the state, but not to then do another state change
<sinzui> We had several tests that did that a few years ago
<henninge> sinzui: jtv and I just looked at one this morning ... ;)
<henninge> anyway, I have made my point.
<jtv> henninge: I think that one did go through multiple state changes
<jtv> ...with separate assertions
<abentley> sinzui, I'm very much in favour of "test only one thing" as a guideline.
<sinzui> abentley, I have read your tests, and I know you are
<henninge> I had it mentioned to me in a review when I first started and just wanted to check if that is the general opinion.
<bigjools> the exception to that is where the setup is very expensive
<henninge> jtv: right.
<abentley> bigjools, though often those are integration tests, so what you're testing is the integration, not the units.
<bigjools> possibly
<abentley> bigjools, YMMV
<bac> henninge: thanks for bringing this up.  i think reducing the asserts, as you did in your example, is a good idea where practical.
<jtv> Another form of testing-too-many-things is where the test sets up a large set of data, and then either performs the operation once and checks all the outputs; or several times with separate checks but without a clear reason why the output should be as expected.
<bigjools> abentley: especially in Soyuz :)
<bac> any other topics?
<bac> 3
<bac> 2
<bac> 1
<bac> thanks everyone
<bigjools> thanks
<bac> #endmeeting
<MootBot> Meeting finished at 09:29.
<bac> go read http://elliotmurphy.com/2010/07/06/teambuilding-and-culture-in-a-distributed-workplace/ for a canonical warm-n-fuzzy
<bigjools> bac: that blog post is awesome, I read it yesterday and had a huge smile on my face
<bac> thumper, rockstar: reviewer meeting?
<thumper> bac: rockstar just went for a walk
<bac> thumper: ok.  we didn't get up to much in the earlier meeting.
<bac> thumper: main item was bigjools requesting that we follow the PQM submit message guidelines
<bac> thumper: by that he meant cut out extraneous stuff like what music is playing, etc.
<bac> everyone agreed
<bac> henninge brought up the topic of a single assert per test case in functional tests which led to a pretty long discussion
<bac> he was concerned that after the first assertion fails the test stops and you don't see the results of the later assertions
<thumper> hmm
<bac> we agreed that in the cases where you can do something clever to avoid multiple assertions then that was ok but we didn't want to codify such a thing
<thumper> personally I don't care about the commit message thing
<thumper> I'm happy to go either way
<bac> henning agreed it should be a guildeline
<bac> me too
<thumper> I don't like the single assert in a test thing
<thumper> if you want to see the others, I think there is a flag
<bac> really?
 * thumper thinks
<thumper> maybe?
<bac> dunno
<thumper> lifeless would probably know
<thumper> if there isn't one, we could add one
<thumper> it isn't rocket science
<bac> i'll look into it
<thumper> ta
<thumper> WRT unit tests
<bac> often if an earlier assert dies then those following don't have much chance
<bigjools> the commit message thing was more about writing something that actually explained the fix properly
<thumper> I would say that the test should be short
<thumper> and primarily test one thing
<thumper> but that one thing may well need multiple asserts
<bac> thumper: yes, you're channeling the gist of our discussion
<thumper> ok
<thumper> we're on the the same page then
<bac> yeppers
<bac> that was it.
<bac> thumper: you have anything to pass on?
<thumper> ok, I guess we are done then
<bac> right.  have a good day.
<thumper> not, not really
<thumper> see you next week
