#launchpad-meeting 2006-09-04
<mpool> ddaa: hi, here?
<ddaa> Hello
<ddaa> https://launchpad.canonical.com/BazaarMeetingAgenda
<mpool> hm, so?
<ddaa> Meeting in 54 minutes
<mpool> really?
<ddaa> Well, like every week...
<mpool> oh, i used to have another one at 7
<mpool> ok, see you then
<ddaa> Yay
<ddaa> MEETING STARTS
<ddaa> This is the launchpad-bazaar meeting, so there are more branches for use bazaar monkeys to hang about
<ddaa> == Agenda ==
<ddaa> Next meeting 2006-09-11, 10:00 UTC.
<ddaa> mpool will be on leave.
<ddaa> Say bzzzt if that does not fit.
<ddaa>  * roll call
<ddaa>  * production status
<ddaa>  * invalid branches
<ddaa>  * smart server
<ddaa>  * advertising
<ddaa>  * vcs-import knits
<ddaa>  * release finder
<ddaa>  * Python import
<mpool> ddaa: both next week and the following week
<ddaa>  * bzr lp://
<ddaa>  * 1.0 targets
<ddaa>  * critical bugs
<ddaa>  * pending sysadmin tasks
<ddaa>  * proritizing important tasks
<ddaa>  * any other business
<ddaa> == Roll call ==
<ddaa> Spiv is on leave until September 10th.
<SteveA> length of meeting is?
<SteveA> (in minutes)
<ddaa> 45 mins
<SteveA> ok
<jamesh> I'm here.
<SteveA> i'm here
<lifeless> my fingers are here
<ddaa> good enough
<ddaa> == Prodution status ==
<ddaa> Early last week, abnormally long delay for mirroring sftp branches were reported. It was caused by a routing issue on escudero that caused time-outs for all vcs-imports branches.
<ddaa> Once escudero was restored, normal service resumed.
<ddaa> A discussion is in progress (CC Launchpad mailing list) on how to rearchiture the branch puller to minimize latency in a future-proof way.
<ddaa> I'm having trouble understanding lifeless' last email, but that's off-topic for this meeting.
<ddaa> == Invalid branches ==
<ddaa> Last week actions:
<ddaa>  * ddaa to bother jelmer about the bzr-svn bug
<ddaa>  * ddaa and lifeless to discuss bzrlib data validation. Not done.
<ddaa> Following up on last week. I ack bzr should prevent bad data from getting in, but since shit happens, the supermirror should be able to recover without needing administrator intervention.
<ddaa> I'm not too sure about how to do that. Does somebody has a plan and want to start the discussion?
<ddaa> I do not think I got it across to jelmer last week.
<ddaa> lifeless and I did not have that discussion.
<ddaa> jamesh: lifeless: any clue about "supermirror recovery from invalid data"?
<lifeless> ddaa: like I said, I dont think there is a discussion to have
<SteveA> is it a problem that is happening right now?
<lifeless> I thought you had changed that as per the discussion we had *in last weeks meeting*
<jamesh> ddaa: can the puller overwrite the invalid branch?
<ddaa> jamesh: I do not expect so, that's the issue
<ddaa> ACTION: ddaa to email to explain what he sees as a problem, since apparently it's not obvious
<SteveA> if the problem is not occuring right now...
<ddaa> SteveA: it's occuring right now
<ddaa> let's move on
<jamesh> ddaa: ideally we'd handle it in the same way as a branch format change: blow away the mirror and start again.  The question is whether we can differentiate between invalid data and bzrlib bugs
<SteveA> how much is it occuring?
<ddaa> SteveA: all samba branches produced by bzr-svn
<jamesh> (i.e. do we get a specific exception or random failures inside bzrlib?)
<ddaa> potentially random failures, although this specific problem causes a BzrError.
<ddaa> == Smart server ==
<ddaa> Last week spiv said: lifeless & mpool & I will be meeting in person tomorrow to continue work on the smart server.  lifeless has figured out some good goals w.r.t. supermirror integration and HTTP integration that's the next step.
<ddaa> mpool: status?
<mpool> we did meet, 
<mpool> lifeless: what was the last status you had from spiv before he left?
<lifeless> he was part way through splitting those branches
<lifeless> I hope/imagine he has pushed his current set to chinstrap/sodium
<mpool> i hope we can merge at least part of it for 0.11, and have andrew merge the corresponding bits to the supermirror when he gets back
<mpool> i'm not sure if this is realistiic
<lifeless> hes back with a week to spare for 0.11
<lifeless> some at least will land, I'm sure of it
<ddaa> Do you think it's still on track for deployment before october 8th?
<mpool> ddaa: not as much slack as i would like, but possible
<ddaa> (I think that's the Launchpad 1.0 time)
<lifeless> Full smart server deployment, no
<ddaa> lifeless: as opposed to what?
<lifeless> we're aiming for the RPC transport deployed into both the hosting and mirror environments
<ddaa> I'm not clear on what is "full deployment" as opposed to "core support"
<lifeless> the smart server will be a launchpad-code-free addition on top of that as it goes into bzr
<ddaa> lifeless: so you mean that the smart server may be used for the publishing side, but the hosting side will be post 1.0?
<lifeless> no
<mpool> ddaa: i think we mean
<mpool> all the launchpad-specific code will be done by then (dog willing)
<mpool> but it need more pulls from bzrlib to be really exciting
<ddaa> what is the risk level of those "extra pulls", is that just some tuning that needs to go through review and merge, or is there some tricky outstanding issues?
<mpool> ddaa: where are you driving with these questions?
* lifeless up the wall
<lifeless> sorry, thats *what*
<mpool> heh
<ddaa> trying to get a hang on the progress and Lauchpad 1.0 target delivery, since it seems I'm the one reporting on that
<ddaa> and it's all very fuzzy to me
<ddaa> but maybe it's a pointless excercice since it will be done when it's done and there is not anything we can do to make it happen faster
<mpool> ok, so let's say it's likely we will have approximately alpha-level smart server support fielded by that date
<mpool> the additional work in bzr will be to speed it up by doing higher-level operations
<SteveA> i'm keen to be running a smart-server on the supermirror soon, even if it provides no benefit over regular sftp
<mpool> it is not risky in an architectural sense, i am confident it will go according to plan
<SteveA> so that we will know about how it works practically
<mpool> SteveA: right, that's what we're aiming for first
<mpool> right
<mpool> and also to shake out any lp integration issues
<lifeless> SteveA: thats exactly what we've mapped out
<SteveA> and we can then add extra commands/calls or whatever you call it
<mpool> i think we should get spiv on that as soon as we can when he returngs
<lifeless> mpool: hes already on it
<SteveA> later to incrementally improve it
<mpool> cool
<mpool> so can we call that closed?
<lifeless> SteveA: yes exactly
<ddaa> Yup. I feel enlightened.
<SteveA> the 1.0 goal should be to have the smart server in operation
<lifeless> how about we talk about something that has not changed in the last week
<SteveA> not that it actually buys users anything immediately#
<ddaa> == Advertising ==
<ddaa> Last meeting actions:
<ddaa>  * spiv: blog about similarities between SVN and bzr checkouts, in relation to Launchpad.
<ddaa>  * ddaa: when rolled out, to blog about branch UI improvements.
<ddaa>  * unassigned: when rolled out, blog about --create-prefix not being needed anymore.
<ddaa> spiv on vacation
<ddaa> ddaa and unassigned, waiting on rollout
<ddaa> moving on
<mpool> ddaa: i think we need in the medium term to do something more than blog to communicate about this
<ddaa> The blog thing appears to be working well enough for new.
<ddaa> for *now*
<mpool> how do you assess that?
<jamesh> but how do people find these scattered howtos 6 months from now?
<ddaa> mpool: I throw some chicken bones and read in them
<jamesh> It'd be good to get them in a central location (or at least linked from a central location)
<lifeless> any post should be put on bazaar-vcs.org/Welcome
<lifeless> in the news area
<mpool> they should be reachable from launchpad in an organized way
<ddaa> yeah, we need something more structured, maybe like the Malone/Rosetta docs, and link from that.
<mpool> lifeless: somethin g kg like that
<jamesh> help.launchpad.net maybe?
<mpool> we don't need to sort that out now
<mpool> indeeed it may be good to seek UI opinions from Uman or mpt or similar folks about where to put it
<ddaa> action for someone?
<mpool> yes
<mpool> SteveA: agree? who should do it?
<SteveA> I'd like you or ddaa to put it on help.launchpad.net
<ddaa> mh... since mpool is working on critical things like the smart server, it might be a better idea to use my time for that
<mpool> ddaa: that would be great
<ddaa> ACTION: ddaa to start compiling blog data on help.launchpad.net
<SteveA> to start with, it's just a matter of making a page, linking it to the front page
<ddaa> SteveA: happy to do no more than that, then :)
<mpool> ddaa: actually, to *really* start with, just write a very small spec for how this is documented, and seek comments on hat
<SteveA> I'd go the other way
<ddaa> SteveA++
<SteveA> have a single place where we collect the documentation
<mpool> SteveA: implement first, comments later?
<SteveA> that is publicly accessible
<SteveA> and then look for opportunities to better link it and put it on the bzr website or whatever
<SteveA> but we need to have the resource before we can use it
<ddaa> I like the idea of producing raw material as blog posts and integrate that material in a central place.
<ddaa> but, hey, we have more critical stuff to do now
<SteveA> and jamesh made a good point about how people find the articles N months from now
<ddaa> Moving on?
<SteveA> another option is having a "using bzr with launchpad" section on the bzr website
<SteveA> done
<ddaa> == vcs-imports knits ==
<ddaa> It appears that the outstanding bzr patches have been merged to bzr.dev, what's needed now is a bzr update on rocketfuel.
<ddaa> lifeless: can you sync/cherrypick rocketfuel's bzr?
<ddaa> The last outstanding patch is launchpad/import-batch-progress. Should the BatchProgress code be submitted to bzr upstream, or should it stay in Launchpad?
<ddaa> https://devpad.canonical.com/~jamesh/pending-reviews/david/launchpad/importd-batch-progress/full-diff
<lifeless> we should just update to 0.10
<lifeless> which has been released
<ddaa> lifeless: by all means
<lifeless> that may or may not include all the patches
<lifeless> I think it has 1 of them
<lifeless> its also much faster than the current bzr we're running
<ddaa> can you cherrypick the missing bits as well?
<jamesh> might even protect us from Jelmer's branches :)
<ddaa> performance is not our big issue ATM
<lifeless> you have already applied the fix to our branch right ?
<ddaa> lifeless: I cannot commit to rocketfuel's bzr
<lifeless> ok
<ddaa> I rolled out a custom branch to importd when deploying the knits conversion code
<lifeless> I suggest just updating to stock bzr 0.10 and keeping your extra fix whereever it is now
<lifeless> the second fix will be in 0.11
<lifeless> and AFAIK we've done all the knit conversions right 
<lifeless> ?
<ddaa> lifeless: right, but it looks like there's a new upgrade to do soon.
<lifeless> ddaa: ???
<ddaa> about root id
<lifeless> 0.11 at the earliest
<ddaa> okay, then it should be okay to temporarily regress on format converision support
<lifeless> and as that will come in via bzr, I dont see that theres any relevance for these fixes to 'our bzrlib' - them being in the bzr that comes is is all thats needed
<ddaa> the relevance is avoiding deploying custom bzr code to importd
<ddaa> but I guess it's no longer necessary, as you point out
<ddaa> What about the BatchProgress thing?
<lifeless> what thing ?
<ddaa> it's the Progress class that gives heartbeat output for buildbot
<ddaa> Bah, let's move on.
<lifeless> I dont know anything about that, other than you wrote it
<ddaa> ACTION: ddaa sort out what to do with BatchProgress with lifeless and mpool
<jamesh> (we're 2/3 the way through the meeting timeslot, btw)
<ddaa> == Release finder ==
<ddaa> Last meeting action:
<ddaa>  * jamesh: report on Dyson full test run.
<ddaa> yeah, we're running late :(
<lifeless> less discussion, more yes/no. DeferToList
<SteveA> meta: the thing to do here is either to agree to trip certain agenda points from the meeting, or agree with attendees for an extended meeting.
<jamesh> It is definitely working better than before, but we got a new exception in the HTTP walker class when trying to read docbook.org indexes
<SteveA> s/trip/strip/
<ddaa> SteveA: I can just speed up some status report items
<jamesh> Looks like a simple mis-use of BeautifulSoup, so hopefully we'll have a better result next week
<ddaa> okay, so still in the works, progress being made
<jamesh> (I should be able to add tests for this failure pretty easily too)
<ddaa> == Python import ==
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/56360
<ddaa> Was busy catching up, merging stuff and having design discussions via email. No progress on that. Need to decide on prioritization later this meeting.
<lifeless> ya, I'm nagging on the release finder regularly ;)
<ddaa> no need to discuss python import right now, later/post-meeting...
<lifeless> didn't we have prioritisation discussions for it last week ?
<SteveA> jamesh: note that I updated our BeautifulSoup in mainline launchpad
<ddaa> == bzr lp:// ==
<ddaa> Last meeting action:
<ddaa>  * mpool: integrate comments to BranchIndirection
<SteveA> ...to the latest release
<ddaa> lifeless: not as such, as far as I recall
<jamesh> SteveA: yeah.  The way the code was using beautiful soup seemed to bypass the encoding detection, leading to problems with the non-ASCII page data
<ddaa> I think that spec has not changed since last week. mpool, can you spend some time on that? (yes/no)
<SteveA> jamesh: latest B.S. is stricter about unicode output
<SteveA> ddaa: mpool, mark and I talked a little about this today
<SteveA> mpool said he'd update the spec
<ddaa> okay, see you next week about BranchIndirection
<jamesh> SteveA: the p-r-f code is doing "soup = BeautifulSoup(); soup.feed(data)", which fails.  Doing "soup = BeautifulSoup(data)" works.
<ddaa> == 1.0 targets ==
<ddaa> [stripping some stuff that needs no discussion] 
<ddaa> bzr-roundtrip-svn: not for 1.0, but discussion is in progress on the bazaar-ng mailing list about how to make bzr-svn acceptable to importd.
<ddaa> mpool: SteveA wanted to know what you were thinking of the general direction of this discussion.
<mpool> i have not updated the BranchIndirection spec
<SteveA> feeding a soup is not usually adding things to a soup, but rather consuming the soup
<mpool> the roundtripping discussion seemed ok to me...
<ddaa> == Critical bugs ==
<ddaa> [skipping that, simple status reporting, see the BazaarMeetingAgenda] 
<mpool> action: mbp: read up/tick off svn roundtripping discussion
<lifeless> FWIW sivs latest work is missing stuff done thursday and friday
<ddaa> mpool: that would be nice
<ddaa> == Sysadmin tasks ==
<ddaa> [skipping that, see BazaarMeetingAgenda] 
<ddaa> == Prioritizing important tasks ==
<ddaa> There are several important new tasks competing for our time. Spiv is out being even more smart and serving than usual, so it's between jamesh and me.
<ddaa>  * Removing Arch support. Low risk, relatively large (est. 16h ddaa). 1.0 target.
<ddaa>  * Python import, currently bug 56360. High risk (may have other hidden blockers), unknown size (est. at least 6h, at most ???).
<ddaa>  * Bug 31308 (native productseries branch) Low risk, medium sized (est. 8h).
* SteveA wonders about having a "before you go on leave" wiki article... (1. mail people about outstanding work.  2. push all your branches...)
<ddaa> To that, I would like to add: bug 34540 (cannot delete a branch) which I think is the largest remaining barrier to adoption of the branch registry. Just allowing to disable branches, without implementing garbage collection should be relatively simple.
<ddaa>  * Bug 34540 (cannot delete a branch). Low risk, medium sized (est. 8h).
<ddaa> Since all those tasks look very important and urgent to me, I suggest:
<ddaa>  * ddaa: removing arch support and python import.
<ddaa>  * jamesh: productseries branch and deleting a branch.
<ddaa> SteveA: what do you think?
<ddaa> Okay, that's one item I want a decision on, but can be discussed post meeting (lifeless and mpool not really required for that)
<jamesh> ddaa: I'm also working on automatic BugBranch link creation now, btw
<SteveA> I'd like to see the python import set off, cos I want to see whether it will break and how.
<ddaa> SteveA: IMO arch support removal takes priority as it's a 1.0 goal
<SteveA> removing arch support doesn't cost us anything to delay a while
<jamesh> "productseries branch" refers to switching to import_branch and user_branch, right?
<ddaa> jamesh: yes
<SteveA> ddaa: it doesn't buy us anything this week, but having a python import does
<ddaa> SteveA: okay
<lifeless> ddaa: removing arch support has been turned down by steve in the last 4-5 meetings I can recall
<lifeless> ddaa: I'd really like it to stop being an agenda item, its wasting cycles
<SteveA> ddaa proposed it as a task for him and tim p. to do together, which I rejected
<SteveA> I think ddaa should do it, but I think it is better to do python first
<SteveA> because it is estimated as less time
<SteveA> and it has more overall benefit, imo
<mpool> after that i'd like to suggest working on a firefox import
<mpool> if there is not already one
<mpool> they're looking at moving from cvs
<mpool> SteveA: maybe you should add "before you go on leave" to the policies wiki?
<lifeless> ok, piss-break before the review meeting
<jamesh> mozilla/firefox makes heavy use of CVSROOT/modules aliases
<ddaa> which is not really supported by importd
<lifeless> mozilla will melt your brain
<ddaa> anyway, that's offtopic for that discussion.
<ddaa> SteveA: jamesh: I think native-branch-for-series and deleting-branch are more important than bug-branch stuff
<ddaa> are they are important blockers in the existing system
<ddaa> I'd like very much to see progress on those, but I do not think I will have the time soon.
<SteveA> ddaa: let's talk about your priorities etc. later today
<ddaa> Fine.
<jamesh> I've only done some speccing for the bugbranch stuff, so I can easily move over to the productseries branch stuff
<ddaa> == Any other business? ==
<ddaa> One minute to say "hey!".
<mpool> hey!
<mpool> two things
<jamesh> I wouldn't mind some comments on https://launchpad.canonical.com/AutomaticBugBranchLinks after I flesh it out a bit more
<mpool> firstly, everyone in this meeting should read the 32/Bazaar spec
<mpool> https://wiki.canonical.com/32/Bazaar
<mpool> ddaa, thanks for your commens
<mpool> if you have not, please do so before next week
<ddaa> jamesh: post to the LP mailing list CC key people when you've done the fleshing out
<SteveA> ddaa: jamesh, mpool and lifeless and I had a meeting earlier today about getting jamesh to do some work on the bug-branch stuff and lp://// stuff.
<mpool> secondly, following on from what you just mentioned
<mpool> there are a few bzr-lp features we need to focus on 
<mpool> - launchpad-url
<mpool> aka branch indirection
<mpool> - redirecting from a branch page to branch content
<mpool> - native branches for products, as you just mentioned
<mpool> and bug-branch connections
<mpool> many of these require both bzr and lp changes
<mpool> i think jamesh owns bug-branch connections now,
<mpool> how about the others?  any comments on who's looking after them, or relative priority?
<mpool> or whether they're for lp 1.0?
<ddaa> my pet peeve ATM is branch-delete
<ddaa> I really think it's an adoption blocker
<SteveA> ddaa: i want to learn why you think that, but let's talk later today about it
<jamesh> branch-delete may be in less demand when branch move/rename is available
<mpool> not having any main branch for bzr is a peeve for me
<jamesh> it is often a case of "I put the branch in the wrong place and now want it deleted"
<ddaa> jamesh: certainly
<mpool> ddaa, it sounded like you worked out with mark the changes that would be necessary to fix that, is that true?
<ddaa> mpool: there was an email discussion between sabdfl and jamesh while I was on vacation
<jamesh> mpool: ddaa proposed I look at this bug (see "productseries branch" earlier)
<ddaa> sabdfl essentially approved the direction we are taking, without reservation, after a few explanations from jamesh
<mpool> ok, so it's all good? not blocked?
<ddaa> blocked on getting somebody to actually do it :)
<ddaa> If jamesh can do it this week, I'm cool with that. Delete can wait another week or two.
<ddaa> since it's not a technical prereq for anything else
<mpool> ok, well, it's not for me to say who will do it
<mpool> that's between you, stevea, jamesh & others
<mpool> i just want to make sure it's flowing along
<mpool> branch indirection is blocked on me fixing the spec
<mpool> for example.
<ddaa> Okay, I'll put it on the top of my "jamesh please" list :)
<jamesh> okay
<mpool> ok, how about redirecting from pages to brnahces?
<SteveA> meta: should have agreed an extension to the meeting.
<mpool> there are bugs open, i don't know their numbers.
* ddaa flogs himself
<jamesh> setting the productseries branch is a prereq for a bunch of other stuff, so I'll try and get it sorted this week
<jamesh> (e.g. the branch indirection spec)
<mpool> jamesh: that's true; doing it soon would be great
<mpool> good point
<ddaa> mpool: I sugges that you revive the discussion that on the mailing list, so we can take the time to dig up the bugs etc.
<mpool> ok
<mpool> ok, that's all then
<ddaa> MEETING CLOSED
<SteveA> thanks david
<ddaa> Thank you all for your attention.
<ddaa> Sorry for being late.
<SteveA> after the review meeting, i'll be going for some lunch
* ddaa will going for lunch now
<SteveA> and when I get back, I'd like to talk with you about these tasks
<ddaa> unless somebody wants to talk to me about something right now
* ddaa -> lunch
<ddaa> SteveA: ping
<SteveA> hi ddaa
<SteveA> ddaa: ping
<ddaa> was workraving
<ddaa> SteveA: you wanted to talk about the tasks for the next weeks
<ddaa> first, I'd like to talk meta-meeting
<SteveA> ok
<SteveA> shall we have a voice call?
<ddaa> please no
<SteveA> porquoi?
<SteveA> ^u
<ddaa> I have some distraction at home, between the kittens and the gf who is having a one week sick leave
<SteveA> that's not really a good reason
<ddaa> well okay
<ddaa> let's have voice
<SteveA> skype okay?
<ddaa> should work
<ddaa> or ekiga if you prefer, works okay here
<SteveA> i've had not much success with ekiga
<SteveA> probably need to change my router
<SteveA> so, let's do skype today
<SteveA> i'm running skyep
<ddaa> setting up
<SteveA> but i don't seem to have you listed at all in my addressbook
<ddaa> david.allouche
<ddaa> I cannot seem to get online for some reason...
<ddaa> It seems I cannot get online.
<SteveA> well
<SteveA> i just tried adding you to my skype contacts 
<SteveA> and I get an error
<SteveA> "david.allouche was added to your Contacts, even though the Skype Name was not found
<SteveA> The Skye Name does not exist or this person has not been online for a long time"
<ddaa> I got online like a couple of moths ago
<ddaa> but it does not work now
<ddaa> let's try ekiga
<SteveA> after a few months, they remove your account
<SteveA> i'm running ekiga now
<ddaa> one minute please
<SteveA> https://wiki.canonical.com/VOIP/Extensions
<ddaa> bingo, she got angry at me because I wanted to be alone for the call
<ddaa> oops
<SteveA> what happen?
<SteveA> someone set up us the bomb?
<ddaa> sound got scrambled, I reset the connection
<SteveA> ok, i just hung up
#launchpad-meeting 2008-09-03
<jtv> hey barry
<barry> jtv: hi
<barry> #startmeeting
<barry> hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
<gmb> me
<jtv> Reviewers meeting?  I came here for the Revue Girls Meeting...
<sinzui> me
<jtv> me
<sinzui> jtv: it immediately follows this meeting.
<jtv> sinzui: ta
<allenap> me
<jtv> abentley: "me" :)
<abentley> me me me
<bac> me
<BjornT> me
<bigjools> me
<cprov-afk> me
<barry> danilos: flacoste ping
<flacoste> me
<barry> salgado: ping
<jtv> barry: danilos was going to be here
<salgado> me!
<barry> intellectronica sends apologies
<barry> jtv: thanks
<barry> i think that's everyone...
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>    * watch for dead end links ([[https://bugs.edge.launchpad.net/launchpad/+bug/254436|bug 254436]] - flacoste)
<ubottu> Launchpad bug 254436 in launchpad-foundations "Launchpad contains lots of dead-end links" [Undecided,Incomplete]
<ubottu> Launchpad bug 254436 in launchpad-foundations "Launchpad contains lots of dead-end links" [Undecided,Incomplete] https://launchpad.net/bugs/254436
<barry>    * extended demo explanation in cover letter (salgado, celso)
<barry> [TOPIC] next meeting
<barry> week +=1 ?
<barry> if you can't make it, please update ReviewerMeetingAgenda with your apologies
<barry> [TOPIC]  * Action items
<barry>  * sinzui to put XXX report into Makefile
<sinzui> Done.
<barry> sinzui: awesome, thanks
<barry>  * barry to propose new bug tag for tech debt paydown
<barry> done
 * barry remembers that abentley already updated UsingMergeProposals
<barry> [TOPIC]  * Queue status
<barry> don't forget to cleanup your PR branches when they land (he says as an offender)
<barry> only 4 pink branches
<barry> danilos: any word on stub/launchpad/trivial?
<danilos> barry: haven't heard from stub, it's needs-reply
<barry> danilos: ah, the PR status just hasn't been updated then?
<danilos> barry: that's right
<barry> danilos: cool, thanks for the update
<barry> the PR queue doesn't look too bad.  does anybody have comments on the review queue?
<danilos> it looked bad yesterday, thanks to bac for doing most of the work on it
 * barry applauds bac!
<bac> actually it wasn't *that* bad
<barry> apologies for slacking on monday due to u.s. holiday
<barry> [TOPIC]  * Mentoring update
<barry> abentley: i think you're the only mentat right now.  anything you want to mention?
<abentley> No, haven't done anything since last week.
<barry> abentley: cool
<barry> let me just mention that i think we have slots available, if anybody has ideas for new recruits, please let me know
<barry> [TOPIC]  * Review process
<barry>    * watch for dead end links ([[https://bugs.edge.launchpad.net/launchpad/+bug/254436|bug 254436]] - flacoste)
<ubottu> Launchpad bug 254436 in launchpad-foundations "Launchpad contains lots of dead-end links" [Undecided,Incomplete] https://launchpad.net/bugs/254436
<ubottu> Launchpad bug 254436 in launchpad-foundations "Launchpad contains lots of dead-end links" [Undecided,Incomplete]
<barry> flacoste: the floor is yours
<barry> flacoste: ^^
<flacoste> that bug describe an issue where we have alot of dead end links
<flacoste> link to empty pages
<sinzui> Pages with structure and nothing else?
<flacoste> so that's something we need to look for in reviews
<flacoste> UI review ideally
<barry> flacoste: can you reiterate here what you mentioned in our standup meeting, re: ui reviews?
<flacoste> sure
<flacoste> actually, it's more about ui pre-implementation
<flacoste> so I discussed with beuno last week how he wanted to interact with the team for UI considerations
<flacoste> i suggested that when we work on a feature involving UI it would be great if he could join the pre-implentation call
<flacoste> to discuss the UI aspect
<flacoste> he agreed that it would be a good idea
<flacoste> so it's something to try out
<flacoste> so if somebody asks you for a pre-impl and it involves UI
<flacoste> try to get beuno involved
<barry> flacoste: +1  ...done?
<flacoste> yes
<barry> flacoste: thanks, i'm really glad beuno will be more involved in ui preimps
<barry>    * extended demo explanation in cover letter (salgado, celso)
<barry> salgado, cprov-afk the floor is yours
<salgado> celso?
<salgado> I'm not sure what this is about
<salgado> okay, I think I know
<cprov> right, I know
<barry>  * Salgado and Celso will propose an extended version of the current DemoURL section in our review cover-letter. Most of the times features and/or bugfixes are not properly expressed by a single URL, they involve a sequence of steps (a story) and should be described like that. This way, we expect reviewers (and readers in general) to observe the proposed change in a more holistic aspect, possibly catching details that will result in a
<barry> more consistent revision.
 * sinzui often needs to state several URLs and which user to use.
 * barry too
 * sinzui also needs to remark that there is no URL, check the oops reports or database.
<cprov> exactly, most of the times a single URL is not enough to represent an UI change.
<salgado> I think this is different than a demo URL
<salgado> I see the demo URL as something to show a new UI you added
<EdwinGrubbs> me
<jtv> Maybe a "how to reproduce/demonstrate" section?
<barry> shouldn't this be captured in a story doctest in the branch?
<salgado> barry, in general it is
<barry> e.g. "to demonstrate, read .../story/frobnicate.txt"
<jtv> But it's nice to have a quick guide to doing it interactively
<sinzui> This issue relates to how we verify this works on staging.
<barry> jtv: maybe story doctests should have a summary section at the top?
<jtv> barry: they should do that already
<barry> jtv: +1
<jtv> barry: but make it too long and it becomes a drag on development
<barry> jtv: if you've got to write it anyway, put it in the test and keep it short and sweet
<barry> jtv: followed by detailed user story
<sinzui> I think the demo section should be transformed into a statement about how to verify the feature/fix in development, staging, production.
<jtv> Maybe the problem here is that our doctests and pagetest stories are too long to get a good overview.
<barry> jtv: yes, definitely a problem already identified
<sinzui> A bug fix is does not necessarily change a user story
<barry> sinzui: that's different.  that's like a q/a plan
<sinzui> I don't think this id different
<cprov> sinzui: I like this idea, a guide to reproduce the problem in production and check the fix in development then in staging/edge when it gets committed
<barry> sinzui: different in the sense: you probably wouldn't put that in our tree
<sinzui> What is the purpose of providing demo steps if it is not to verify that the code works as expected
<barry> sinzui: you'd put that in our q/a artifacts
<sinzui> barry: that is exactly what I am saying
<barry> sinzui: then we agree! :)
<sinzui> a bug probably does not have a use story because we captured the story when created the feature
<barry> sinzui: this is a good idea because we've already said we want two people to do q/a for each issue
<allenap> sinzui: For UI, say, it gives the reviewer an immediate handle on the end result, then they can review the changes in that light.
<cprov> barry: i agree it's q/a, the idea is to introduce those artifacts earlier in the development workflow.
<barry> cprov: +1.  so where/how do we capture these?  wiki?  pastebin?  tree?
<cprov> barry: i'd say it must be in the review cover-letter
<cprov> review-proposal summary, to be precise.
<barry> cprov: it's probably not a bad thing to begin to hash out during preimp either
<barry> iow, during pre-imp ask how you would q/a the change
<flacoste> i like these ideas
<flacoste> discussing qa during pre-impl
<cprov> barry: agreed, it should be considered as part of 'understanding/reproducing the problem'
<flacoste> and putting the QA validation steps in the cover letter
<barry> +1
<sinzui> +1
 * abentley is a bit worried about how much we keep saying "pre-impl"
<abentley> In my experience that doesn't happen much.
<sinzui> abentley: make it happen
 * sinzui does
 * gmb does, too
 * abentley lacks a time machine.
 * sinzui uses good habits to compensate for poor skilz
<barry> salgado, cprov i'd like to capture this in our documentation. can i give one of you the following action: email the list and add it to the wiki?
<cprov> barry: sure
<barry> sinzui: do you suggest, as a reviewer, outright rejection of non preimp'd (and q/a planned) branches?
<barry> cprov: thanks
<salgado> thanks for taking it, cprov
<abentley> To be clear, I'm speaking as a reviewer, not a submitter.  All *my* stuff has a pre-impl.
<barry> [ACTION] cprov will email the list and update the wiki, re: review q/a plan during preimp,and include that in the cover letter
<cprov> salgado: np, I reckon you already have enough in your plate ;)
<sinzui> barry: I think Rinchen might want that. QA signoff after landing is in our process
<gmb> abentley: It's not unheard of for a reviewer to say "this is bong; go and have a call with someone about it..."
<gmb> Though with OCR that seems to happen less, AFAICT
<abentley> Also, I think that open-sourcing Launchpad will probably reduce the likelihood of pre-impls.
<barry> gmb: that's been my observation as well, but as a reviewer, i've let it slide (probably too much)
<barry> abentley: tasty can of worms there
<gmb> Om nom nom
<barry> so, should we hard-assed about requiring pre-imps?
<barry> and q/a plans?
<gmb> I think, re: pre-imps, it really depends on branch size.
<jtv> gmb: +1
<abentley> barry: I was a guest in the bzr stand-up, and it's clear they think pre-impls won't happen in a real open-source project.
<flacoste> i think the only thing we should be hard-assed about is rejecting bad branches
<gmb> For less than, say, 200 lines of diff, a pre-imp might not be necessary (particularly if it's mopstly removals)
<barry> one thing i'm worried about is possible effect on increasing overhead (and thus discouraging) cleanup branches
<sinzui> I hate to be a Nazi on this issue, but this issue comes up every month. We need to take some form of action to improve the quality of our branches.
<flacoste> if pre-impl avoids bad branches, then people will do it
<gmb> Right.
<flacoste> because otherwise they'll be rejected in review
<gmb> Even a mid-imp is better than nothing, because at least someone has said "yes, your approach is sane"
<gmb> Which isn't the reviewer's first job
<gmb> Since sanity can be domain specific.
<flacoste> hmm
<flacoste> good point
 * abentley cannot judge sanity of 75% of things submitted to him for review.
<gmb> (So, Soyuz makes my brain bleed, but when bigjools says he's discussed a change with cprov I can accept there's some sanity to it)
<barry> flacoste, sinzui maybe reviewers should be more willing to punt on a branch early if it's had no preimp, lacks a q/a plan, looks like crack
<flacoste> i think abentley and gmb have a valid points here
<sinzui> barry: I have done that as a sanity check
<cprov> gmb: and 'vice-versa' ;)
<gmb> cprov: No, I trust *you* implicitly ;)
<barry> abentley: i agree.  in mailman, we occasionally have email discussions about approaches, but it's mostly rare
 * gmb waits for bigjools' boot to descend
<cprov> gmb: historically, I've done the most insane changes, you know that :)
<barry> flacoste: i agree, all good points
 * bigjools -> winds up
<sinzui> I expect someone on my team to accept my tests and implementation plan. I also expect that person to agree with how many branches it will take to complete.
<barry> sinzui, abentley so preimps are probably best done with team mates, rather than the general lpdev population?
<barry> then reviewers with less domain knowledge will have more confidence that the approach is sound, and will have a q/a plan in the cover letter to guide them
<abentley> barry: Yes.  And reviews submitted to team mates are less likely to need pre-impl.
<jtv> barry: definitely, unless you're unsure of your footing in some other important area of your branch.
<sinzui> barry: often, but I have used BjornT for example when he was person with the most experience with the issue.
<barry> abentley: i still don't want to give up on reviewers can review anything
<barry> jtv: yes, you might need multiple pre-imps (i've done that)
 * sinzui tends to bounce around domains.
<barry> sinzui: good point
<gmb> barry: Reviewers *can* review anything. But, for example, if allenap reviews one of my branches, he doesn't necessarily need me to have had a pre-impl because he can call me on its crack-ness pretty quickly.
<abentley> barry: I'm not suggesting giving up on that, just noting a corollary.
<barry> gmb: good point
<gmb> barry: In which case pre/mid-imp and review become one.
<flacoste> gmb: well
<gmb> (Although that's not an excuse to not have had one, I'll grant you)
<flacoste> the point of the pre-implentation is not only to bounce crack branch at review time
 * barry apologies for going over 45 minutes, but wants to let this good discussion continue for a bit
<flacoste> but to make sure that you don't work on crack branch
<flacoste> it's about building quality in
<flacoste> if pre-impl ensures quality in, we should do it more
<gmb> flacoste: You're right, of course.
<flacoste> if not, we should drop it as waste
<barry> flacoste: and also to not waste time
<barry> reduce waste
<barry> flacoste: +1
<gmb> I think it's definately a positive that we have pre-imps. BjornT has saved me from myself many times during a pre-imp ;)
<jtv> amen
<barry> so we've run over.  i'd like to carry this forward on the main lp list, so that we can come up with action items next week
<barry> [ACTION] barry will move the preimp discussion to the ml
<barry> thank you everyone for some very good points
<barry> apologies for going long
<barry> #endmeeting
<jtv> yay!
<abentley> Thanks barry
<jtv> thanks barry
#launchpad-meeting 2008-09-04
<mrevell> hey gmb, leonardr, barry: I have a minor sound problem that I'm working to fix
<leonardr> mrevell: i have a question. is this going to be edited later? i'm expecting a package within the next hour
<leonardr> so i may need to take a short break
<mrevell> leonardr: Yeah, it'll be edited later. I think it'll only take ten to fifteen mins
<leonardr> cool
<mrevell> this is all on the assumption that I can get my audio problem sorted
<barry> mrevell: brb
<barry> mrevell: ready
<mrevell> sorry barry, I've had to find another laptop and am waiting for it to boot
<Ursinha> matsubara, are you going to be the host?
<matsubara> Ursinha: yes
<Ursinha> great
<matsubara> #startmeeting
<MootBot> Meeting started at 13:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<mrevell> meme
<beuno> me
<abentley> me
<bac> me
<gmb> me
<flacoste> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<salgado> me
<henninge> me
<mars> me
<adeuring> me
<matsubara> me
<sinzui> me
<barry> me
<thumper> me
<Ursinha> me
<stub> me
<cprov-afk> me
<kiko> em
<matsubara> Releases is here
<BjornT> me
<matsubara> TLs please check if your team members are here
<thumper> rockstar: ping
<BjornT> allenap and intellectornica are off today
<kiko> are the TLs here, is the real question? ;)
<matsubara> thanks BjornT
<BjornT> rest of bugs team is here
<bigjools> me
<jtv> me
<rockstar> me
<thumper> Code is here
<flacoste> Foundations is missing leonardr and EdwinGrubbs
<kiko> they are being printed on milk cartons as we speak
<leonardr> me
<matsubara> bigjools, jtv: soyuz, translations?
<bigjools> soyuz all present
<jtv> matsubara: Translations almost complete
<kiko> al-maisan is excused this week
<herb> me
<matsubara> all right then. let's move on
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Next meeting
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs (matsubara/ursinha)
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (stub)
<matsubara>  * Sysadmin requests (Rinchen)
<matsubara>  * New packages required (salgado)
<mthaddon> me
<matsubara> so next meeting same time, same channel?
<Ursinha> +1
<kiko> YES!
<matsubara> done
<kiko> good idea
<matsubara> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<matsubara>     * salgado to test query that fixes oops in +participation on staging and after that run the query on production db. Query approved by stub
<matsubara>     * Ursinha to ask danilo /jtv about bug 261507
<matsubara>     * Ursinha to ask Bjornt about bug 252674
<matsubara>     * Ursinha to ask mthaddon about bug 259947
<kiko> beuno will tell us that consistency is an absolutely desireable goal :)
<ubottu> Bug 261507 on http://launchpad.net/bugs/261507 is private
<ubottu> Bug 252674 on http://launchpad.net/bugs/252674 is private
<ubottu> Bug 259947 on http://launchpad.net/bugs/259947 is private
<salgado> matsubara, done
<matsubara> thanks salgado
<EdwinGrubbs> me
<Ursinha> matsubara, bug 261507 was workarounded and then lowered to High, danilo said that they're w
<Ursinha> orking on the fix
<ubottu> Bug 261507 on http://launchpad.net/bugs/261507 is private
<Ursinha> bug 252674, it is now in progress, cool
<ubottu> Bug 252674 on http://launchpad.net/bugs/252674 is private
<kiko> I hate private bugs
<thumper> kiko: you have the power
<kiko> are these security sensitive?
<Ursinha> i haven't spoken with mthaddon about bug 259947 yet
<ubottu> Bug 259947 on http://launchpad.net/bugs/259947 is private
<Ursinha> kiko, i'm not sure of that
<jtv> kiko: 261507 isn't very security sensitive
<matsubara> Ursinha: I don't think any of those shipit OOPSes happened again.
<matsubara> since last week, I mean
<Ursinha> matsubara, no, they stopped happening
<kiko> I think if you're going to list them in a public channel they had better be public
<kiko> I think
<Ursinha> kiko, +1
<sinzui> +1
<kiko> an the beautiful sound of consensus
<matsubara> please assignees disclose your bugs if you think they're ok to be public
<matsubara> [TOPIC] * Oops report & Critical Bugs (matsubara/ursinha)
<MootBot> New Topic:  * Oops report & Critical Bugs (matsubara/ursinha)
<Ursinha> bugs for today: 259440 (MailinglistApiView), 263672, 260206 (resolve_lp_path), 260140 (revisions.atom), 160236 and 174368 (last two pretty much the same)
<Ursinha> bug 259440, it was CP but already causing a lot of oopses in production, barry?
<ubottu> Launchpad bug 259440 in launchpad-foundations "OOPS in MailingListAPIView" [Critical,Fix released] https://launchpad.net/bugs/259440
<barry> Ursinha: no more than it was, but the oops reports are much smaller now
<thumper> bug 260140 bounced pqm due to conflict, resolving as we speak and resubmitting
<ubottu> Bug 260140 on http://launchpad.net/bugs/260140 is private
<matsubara> [ACTION] matsubara to add a note in the MeetingAgenda page about disclosing private bugs that will be discussed during the meeting
<MootBot> ACTION received:  matsubara to add a note in the MeetingAgenda page about disclosing private bugs that will be discussed during the meeting
<Ursinha> i saw a lot
<barry> Ursinha: flacoste and i have discussed further refinements to (hopefully) eliminate the oopses
<kiko> barry, so it still times out, but less often?
<barry> kiko: i think so
<Ursinha> kiko, considering the oopses, yes
<Ursinha> but there are a lot still
<barry> kiko: many fewer queries, but the ones it does still take a long time
<thumper> the resolve_lp_path was being worked on by mwhudson, I'll chase the status
<Ursinha> thanks thumper
<Ursinha> barry, so you're working on it?
<matsubara> [ACTION] thumper to chase status of resolve_lp_path bug
<MootBot> ACTION received:  thumper to chase status of resolve_lp_path bug
<kiko> thanks thumper really
<barry> Ursinha: can you open a new bug and attach some of the latest oopses?
<Ursinha> barry, sure
<matsubara> [ACTION] barry to work on more refinements for MailingListAPIView bug
<MootBot> ACTION received:  barry to work on more refinements for MailingListAPIView bug
<barry> Ursinha: not at the moment, but it's on the list!
<barry> thanks
<Ursinha> barry, ok... i'll file the bug and send you
<Ursinha> ok, next
<Ursinha> bug 263672, matsubara filed this one and asked salgado about it, it seems that it belongs to Bugs. Anyone from bugs to take care of it
<ubottu> Launchpad bug 263672 in launchpad-foundations "account merging triggering database constraint" [Undecided,New] https://launchpad.net/bugs/263672
<Ursinha> maybe BjornT
<Ursinha> anyone?
 * Ursinha pokes bugs team
<kiko> oh how interesting
<kiko> is that a bug in the merge code I wonder?
<stub> I normally fix them
<kiko> stub, salgado: is this a case in which we can't automatically handle it?
<sinzui> kiko: I think so
<stub> It means we have a unique constraint to handle, or handle better.
 * Ursinha pokes salgado 
<salgado> Ursinha, stub already explained
<Ursinha> okay so
<kiko> yeah
<salgado> he knows that a lot better than myself
<kiko> and I think stub's volunteering
<stub> Ok
<Ursinha> so the last one
<matsubara> [ACTION] stub to fix bug on account merging raising db constraint
<MootBot> ACTION received:  stub to fix bug on account merging raising db constraint
<Ursinha> two actually
<stub> Other people are welcome to learn how it all works though ;)
<matsubara> MootBot is really handy
<Ursinha> bug 160236 and 174368, similar oopses happened yesterday. Can anyone of foundations take care of it?
<ubottu> Bug 160236 on http://launchpad.net/bugs/160236 is private
<Ursinha> matsubara, indeed
<Ursinha> these bugs are about problem when searching for bugs
<Ursinha> bug 174368
<ubottu> Launchpad bug 174368 in launchpad-foundations "Search query triggering error in tsearch" [Undecided,Confirmed] https://launchpad.net/bugs/174368
<matsubara> Ursinha: that's another one for stub perhaps?
<stub> So there is this really disgusting python method embedded as a string in fti.py.... it transforms the query string a human enters into tsearch2 syntax.
<flacoste> stub: feel like revamping the fti regexp?
<stub> I hate revamping that.
<stub> Its a pile of poo
<flacoste> time for redesign maybe?
<stub> I'd love someone who knows how to do tokenization properly to have a go, but I can patch it :)
<Ursinha> hm, good
<Ursinha> ok
<Ursinha> this is all for now guys
<Ursinha> thanks a lot
<kiko> stub, does jtv know how to do that?
<kiko> I know he is a genius at some sorts of things
<jtv> kiko: I know nothing
<kiko> jtv, brownie points--
<matsubara> [ACTION] stub to patch our fti regexp
<stub> Its not magic - you just need to transform (foo AND bar OR (baz AND NOT boom) to foo & bar | (baz & ! boom)
<MootBot> ACTION received:  stub to patch our fti regexp
<jtv> stub: can we talk about this, oh, tomorrow?
<stub> And probably pull out the hyphenation crack
<stub> yer
<matsubara> ok. moving on then. thanks Ursinha. Thanks everyone.
<matsubara> [ACTION] stub and jtv to discuss a proper fix to our fti regexp (bug 174368)
<MootBot> ACTION received:  stub and jtv to discuss a proper fix to our fti regexp (bug 174368)
<ubottu> Launchpad bug 174368 in launchpad-foundations "Search query triggering error in tsearch" [Undecided,Confirmed] https://launchpad.net/bugs/174368
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<mthaddon> â¢ CP to xmlrpc-internal that has reduced size of xmlrpc-internal oopses
<mthaddon> â¢ Have begun work on migrating to new version of psycopg2
<mthaddon> â¢ App servers still dying, but as above may help
<mthaddon> â¢ Codebrowse still having issues, but not as many as immediately after the rollout
<mthaddon> â¢ In the process of migrating RF branches (where possible) to be hosted on LP itself
<mthaddon> â¢ Any comments on jamesh' suggestion that some branches can be removed from RF?
<mthaddon> â¢ IS sprint next week means we'll all be in London (i.e. on the same timezone)
<mthaddon> â¢ That's it from the LOSA team unless there are any questions
<kiko> ooooh, utf-8 bullets
<stub> If the test suite passes without em, they aren't needed
<kiko> mthaddon, is psycopg2 on staging?
<kiko> ah, it's the same appservers
<mthaddon> kiko, it is, yes
<kiko> mthaddon, and crashes since?
<matsubara> those bullets come from tomboy, I presume
<mthaddon> kiko, hasn't crashed since
<mthaddon> matsubara, correct!
<kiko> no way!
<mthaddon> kiko, hasn't been on that long though
<kiko> still...!
<matsubara> I guess, I can move on then. thanks mthaddon and LOSAs
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<kiko> thanks guys
<stub> DB patch reviews in my queue where discussed with Mark and all approved. I'll be sending out the reviews with any necessary tweaks tomorrow. At least one has come in after the cutoff (which I haven't looked at yet). I'll see if I can get approval for it to land this cycle, but it might have to wait until next.
<stub> The read-only-launchpad branch has finally landed, yay. getUtility(IZStorm).get('main') now blows up. I need to update the wiki pages when I find them.
<stub> Done.
<kiko> stub, it landed today, so we should be on the lookout tomorrow, right?
<kiko> i.e. staging and edge issues
<stub> Yup
<stub> There are config changes...
<flacoste> stub: any formal QA we can do on it?
<mthaddon> stub, anything we need to be aware of?
<stub> I think I got them right :)
<mthaddon> stub, such as chokecherry is now a production machine? :)
<kiko> FLW
<stub> mthaddon: Nothing you can't work out ;)
<stub> mthaddon: The appservers still only talk to a single database, despite there being config for a master and a slave
<stub> mthaddon: Which is why the connection strings should be identical
<mthaddon> ok, cool
<matsubara> stub: so, no QA needed for the read-only db yet?
<kiko> well
<kiko> keep an eye on production
<stub> It should still work tomorrow like it does today.
<kiko> that's what he meant :)
<matsubara> ok. thanks stub.
<matsubara> [TOPIC] * Sysadmin requests (Rinchen)
<MootBot> New Topic:  * Sysadmin requests (Rinchen)
<matsubara> if you have any outstanding RT, let me know and I'll forward those to Joey and/or IS
<kiko> now that psycopg2 is delivered and I have salgado's list
<kiko> I think I'm a happy camper!
<kiko> salgado, you got that yesterday mid-stream?
<salgado> kiko, I did.  will write the SQL to delete the unused ones today
<matsubara> all right, moving on then
<matsubara> [TOPIC] * New packages required (salgado)
<MootBot> New Topic:  * New packages required (salgado)
<salgado> anything for me this week?
<salgado> I didn't hear back whether or not we need to depend on the new psycopg2 package
<salgado> does anybody know for sure?  I'm pretty sure we do
<kiko> salgado, let's wait to see how it handles production first
<salgado> ok
<matsubara> ok. thanks salgado
<stub> We do, or we need to revert my branch for the test suite to pass
<flacoste> it's already deployed on PQM
<flacoste> so that shouldn't be a problem
<kiko> but if it's okay by monday then I say yes
<kiko> just to avoid the shell-shock of downgrading
<stub> Yer, but devs who haven't updated could trip over it.
<salgado> I guess stub meant for the tests to pass locally
<kiko> maybe I'm being too careful?
<matsubara> [TOPIC] Improving review kwality - bigjools
<MootBot> New Topic:  Improving review kwality - bigjools
<mthaddon> stub, so is the new psycopg2 going to be a dependency on edge from tomorrow?
<bigjools> ok
<kiko> mthaddon, unless we don't roll out..
<bigjools> are you done? :)
<mthaddon> i.e. yes
<stub> I don't think so, no. Our test suite excercises the bug now purely by accident
<mthaddon> ah, okay
<kiko> ah
<bigjools> So, the issue of quality of reviews came up recently
<bigjools> I talked to Barry and Bjorn and we have some things to propose
<flacoste> quality of reviews or of branches submitted to review?
<bigjools> reviews
<flacoste> interesting!
<kiko> damn, busted
<bigjools> the upshot is that reviewers need to:
<bigjools> 1. ask more questions and not take the dev's word for things
<bigjools> 2. the reviewer should try and call the dev if it's a non-trivial branch, so they can discuss it
<bigjools> 3. Team leads should allow time for their members OCR in planning
<bigjools> (I know Francis does this already)
<bigjools> and lastly, we should consider doing half or 3/4 day shifts to reduce OCR workload
<bigjools> any questions?
<kiko> I don't understand the last point
<barry> taking into account that there /will/ be review follow ups
<bigjools> what he said
<kiko> I am all for questions and calls fwiw
<bigjools> full day OCR is tiring
<sinzui> bigjools: I have mastered asking stupid questions, does that count?
<bigjools> sinzui: there's no such thing as a stupid question
<sinzui> bigjools: yes this is.
<flacoste> lol
 * sinzui looks for his list
<kiko> bigjools, well... yes, but so is other sorts of work
<kiko> bigjools, and full day OCR AIUI doesn't actually mean 8h of reviews
<flacoste> indeed, we should aim for half or 3/4 of work days
<bigjools> kiko: there should be enough reviewers to spread the load a bit more evenly
<kiko> though it may feel like 12h of them :)
<flacoste> since there /will/ be overtime :-)
<bigjools> I get the feeling that some of them do the lion's share
<barry> kiko: ask sinzui about that :)
<bigjools> *cough* Fridays *cough* :)
<kiko> fridays are overrated
<kiko> every day feels like friday to me
<bigjools> anyway that's it from me, I just wanted to raise awareness of this issue
<matsubara> [ACTION] update reviewers process to account for half or 3/4 of work days for on call reviewing
<MootBot> ACTION received:  update reviewers process to account for half or 3/4 of work days for on call reviewing
<kiko> bigjools, thanks for bringing it up, more seriously. I know this bothers us from time to time and we need to address a process for review feedback
<bigjools> indeed
<barry> kiko: +1
<matsubara> thanks bigjools. moving on.
<matsubara> [TOPIC] matsubara - early pre release QA
<MootBot> New Topic:  matsubara - early pre release QA
<barry> btw, anybody can ping me any time if they want to talk about reviews they're doing or reviews they're getting
<Ursinha> awesome
<matsubara> so, how's the early pre release QA coming? What do you guys think about it? Is it helping? How can Ursinha and I help more there?
<kiko> has anyone done any pre-release QA?
<kiko> :)
<matsubara> kiko: yes!
<flacoste> my team has
<Ursinha> kiko, foundations, i guess
<Ursinha> :)
 * thumper raises his hand
<salgado> I did!
<matsubara> soyuz had
<cprov-afk> yes, soyuz did.
<bac> yes.
<matsubara> but there are still lots of items there in NEEDSTESTING
<flacoste> kiko: have you, that's the question?
<kiko> I haven't fixed any bugs, I'm afraid
<kiko> matsubara, who are the biggest offenders?
<matsubara> Please do contact me or Ursinha to help with testing.
<Ursinha> yes, please
<kiko> well
<kiko> I'm asking to figure out if somebody doesn't know about PRQA yet
<jtv> kiko: Translations knows
<Ursinha> kiko, matsubara sent emails to the teams
<matsubara> I have had no answer from code and translations
<kiko> the usual culprits! easternlings
<kiko> jtv, thumper: so.. you guys not doing it?
<kiko> jtv, thumper: the expectation is for the tests to be done 24h from the landing
 * thumper has only just landed something
<jtv> kiko: yes, we just learned about it though
<thumper> I'll poke the team
<Ursinha> great thumper
<kiko> thumper, thanks, please help us get everybody on the same pageeee
<matsubara> thanks guys, and please, if you guys are too busy with coding, let us know and we can land a pair of hand for testing stuff, but you need to let us know!
<matsubara> and the final topic
<matsubara> [TOPIC] BCTL - kiko
<MootBot> New Topic:  BCTL - kiko
<kiko> okay
<kiko> I don't want to remind people of this again
<kiko> but tomorrow is the deadline for BCTL
<kiko> if you are confused ask your team lead
<kiko> it means a lot though
<kiko> kthxbye!
 * beuno wonders what BCTL is
<matsubara> well, that's it then. thanks everyone
<matsubara> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 13:44.
 * abentley votes for Big Chees Taco Land.
<mrevell> nice work matsubara
<matsubara> right on time! cool
<barry> Badly Coordinated Transactional Lobsters
 * thumper is confused with BCTL
<thumper> perhaps it is just the early morning
<mrevell> Big chested... No, I shan't go on
<stub> thumper: Ask your team lead.... oh...
<thumper> :)
<beuno>  /me emails the marketing director about it
<thumper> Badly Coordinated Team Leads?
<bigjools> lol
<flacoste> thumper: i think that's the one
#launchpad-meeting 2009-09-02
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello and welcome to this week's ameu reviewer's meeting.  who's here today?
<sinzui> me
<henninge> me
<deryck_> me
<noodles775> me
<intellectronica> me
<salgado> me
<gmb> me
<bac> me
<barry> flacoste: adeuring gary_poster leonardr bigjools ping
<abentley> me
<flacoste> me
<leonardr> me
<bigjools> me
<adeuring> me
<gary_poster> me
<barry> cprov: danilos mars allenap ping
<danilos> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<danilos> barry: thanks
<barry> np!  it's a full agenda today...
<barry>  * Roll call
<barry>  * Action items
<barry>  * UI review call update
<allenap> me
<barry>  * On-call review responsiveness, [intellectronica]
<barry>  * cls.links should be a tuple, never a list (menu.py), [bigjools, barry]
<barry>  * `__iter__()` in model objects? [cprov, barry]
<barry>  * mkstemp()/open() combination leaks file-descriptors [cprov]
<barry>  * Guidelines changes for tests checking systems pre-requisites (specific umasks, app configurations) [maxb, cprov]
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * beuno to add a 'ui' specialty to ReviewerSchedule
<barry> he did this, so if you have any questions about who can do a ui review for you, check the ReviewerSchedule page
<barry>  * gary_poster and barry will transfer review guidelines from the old wiki and old old wiki to the new wiki
<barry> not done :(
<gary_poster> Let's set a time.
<gary_poster> Or at least together make a list of what needs to be done
<barry> gary_poster: +1 we can coordinate off-channel
<gary_poster> so we can divvy it up
<gary_poster> cool
<barry>  * UI review call update
<barry> beuno's not here.  intellectronica do you or anyone else want to give an update on that c/c?
<intellectronica> barry: i wasn't on the last one, so not me
<barry> ah right
<barry> i don't remember everything we talked about, but i will say that i am currently trying to fix the global issues with page titles, h1, h2 etc. headings
<flacoste> that's the most important issue i think
<barry> ping me with any questions or problems in that area.
<barry> your pages will /not/ currently look right until i fix certain things
<flacoste> we clarified the rules for that
<barry> and then you may have to go back and adjust your pages (e.g. remove heading slots, etc)
<flacoste> did you update the wiki?
<intellectronica> flacoste: is that written somewhere?
<barry> flacoste: i did.  i have maybe one small round of corrections, but it's darn close
<intellectronica> barry: url?
<barry> i sent an email to lp-dev with details, but here's the url:
<barry> https://dev.launchpad.net/VersionThreeDotO/UI/Conversion#Heading%20rules
<intellectronica> thanks
<barry> let's move on.  please read the email & wiki and respond to that thread with any feedback
<barry> [TOPIC]  * On-call review responsiveness, [intellectronica]
<MootBot> New Topic:   * On-call review responsiveness, [intellectronica]
<intellectronica> on call reviews are wonderful, but i feel that sometimes people don't make the best use of them
<intellectronica> at best, on call reviews are an approximation of pair programming, not a queuing mechanism
<intellectronica> it's hard to set any clear rules, because reviews are subject to variation in patch size and complexity, personal style, etc
<intellectronica> but i would just like to remind reviewers that there is a lot of value in having a very interactive reviews
<intellectronica> at the very least, it's important to communicate what the status of a review is
<danilos> intellectronica: I think the main problem is that we are using them as queuing system as well; I can't come talk to an OCR person about something I just want to do since when I come back with the implementation, someone will be in the queue having their branch reviewed
<intellectronica> occassionally ive had reviews where i didn't get a reply until after a few hours, or even a day later, and i think that's a shame
<abentley> intellectronica: There may be tension between wanting to capture everything in Code Review and doing it on IRC.
<intellectronica> danilos: in very busy times, that can be a problem, but in many cases, you can literally work on the changes together
<intellectronica> danilos: a really great way to ensure that is to do the review on the phone
<barry> intellectronica: i agree that reviewers should let the dev know what's happening with their branch.  i try to follow up in irc with a "hey intellectronica, r=me" or whatever when i'm done, but maybe that's not enough
<bigjools> there is another problem - the OCR queue overrides the +active-reviews queue
<intellectronica> abentley: indeed, and for some patches a very thorough offline review is better than a very dynamic but potentially not exhaustive online review
<danilos> bigjools: I think the idea is that people should do on-call reviews, so +active-reviews is a very last resort
<bigjools> leave a branch in the latter and it can get left behind until much later
<abentley> bigjools: Why is it a problem?  OCR is for interactive reviews.  A branch from a sleeping Australian shouldn't take precedence over someone who asked for a review in IRC.
<intellectronica> yeah, i think of +activereviews as offline reviews, a different beast altogether
<danilos> bigjools: well, if you don't want to be around for a review, then it will happen; otoh, you can go with an OCR through the branch together and it won't be left behind
<barry> bigjools: it should always be possible to prod a reviewer into taking one of yours on +activereviews
<bigjools> my point is that often a branch will languish unless you get an OCR to look at it
<danilos> bigjools: you seem to be saying that you don't like to use OCRs :P
<bigjools> hence the problem that intellectronica points out
<intellectronica> bigjools: you could coordinate an offline review with a reviewer who isn't on call
<bigjools> sometimes an interactive review is totally inappropriate
<bigjools> intellectronica: that's what I do
<intellectronica> bigjools: absolutely, but i'm not talking about these cases
<bigjools> I am just pointing out a possible reason for the behaviour you see
<barry> btw, asking questions and resolving issues on irc is a great way to do it.  very interactive and often, cuts down on needsfixing round trips.  just try to capture the conversation (in summary) on the review.  e.g. "you and i talked about your frobnification of baz, and you agreed on irc to frobnicate foo too"
<barry> intellectronica: do you have any thoughts on improving the responsiveness, effectiveness, or throughput of reviews?
<intellectronica> barry: one thing that i take from this discussion, is that we should make the preference for an online review explicit
<abentley> bigjools: I think that if there's a problem, it's that the OCR doesn't do +activereviews when the OCR queue is empty.
<barry> intellectronica: instead of just taking a branch off the queue and disappearing for an hour or so?
<gary_poster> I agree with abentley, and have been so guilty
<barry> abentley: agreed.  let's make that explicit too
<intellectronica> barry: yes. i would go as far as say that the OCR's main responsibility is to do online reviews. if he has extra time, taking stuff off +activereviews is great, but these branches can also be scheduled for reviewing in other ways
<abentley> gary_poster: I have also been so guilty.
<barry> agreed.  i'll take an action item to communicate these two ideas to the team
<barry> [ACTION] barry to communicate about +activereviews and doing on-line reviews
<MootBot> ACTION received:  barry to communicate about +activereviews and doing on-line reviews
<danilos> I disagree with the concept that +activereviews should be the next resort, what happens when someone pops in and you are in the middle of the review?
<bigjools> you finish it
<danilos> i.e. it's fine only if you should stop working on offline review, because people wanting to use OCR don't get the full benefit then
<barry> danilos: last resort.  i.e. when you have nothing else on the queue, there's an implicit off-line queue in +activereviews
<danilos> barry: yeah, but offline reviews are usually longer (I am not doing OCR anymore, but I remember spending over 2h on a complicated branch), and that means that there's no OCR for that time
<intellectronica> danilos: don't take an 800 lines branch for review from an author who is asleep if you're on call reviewer
<bigjools> danilos: citation needed ;)
<barry> danilos: channel your inner kiko and send a partial review.  do your ocr, then if you have time, follow up with the online review
<barry> intellectronica: that too
<bigjools> remember kiko's guide to reviewing ...
<barry> bigjools: +1
<danilos> barry: I am not worried as an OCR person (as I remember, I am not doing it anyway), but as an OCR customer
<bigjools> I don't get nitpicky if it's a big branch
<barry> danilos: as on ocr customer, you should get preference over off-line reviews
<danilos> barry: that's exactly what I am saying, and that's exactly what I want communicated in the announcement: i.e. if someone pops up asking for OC review, drop work you've been doing on offline branch if at all possible (i.e. you are not halfway through or something)
<danilos> s/offline branch/offline review/
<flacoste> i don't agree with that
<flacoste> if you started a review, finish it
<flacoste> don't interrupt for online review
<flacoste> never interrupt work
<flacoste> it leaves work-in-progress
<flacoste> and that's bad
<danilos> flacoste: I agree with that, but my point is, I want OCR to be OCR
<flacoste> is it a problem
<barry> flacoste: that's why i say, ask yourself WWKD
<danilos> flacoste: if the only way to get that is to make people suffer before they understand why OCR is valuable, I'd be happy to do that
<barry> danilos: also, as deryck_ and i were discussing today, team leads are not official ocr's but they should be available to do reviews when the load gets too big for the ocr.  at least, i know sinzui and flacoste are almost always willing to jump in and help.
<bac> WWKD about this discussion?
<barry> :)
<flacoste> didn't we have multiple OCR coverage
<gary_poster> heh
<flacoste> they can coordinate between them
<danilos> barry: I do reviews, and all I do I do OCR
<gary_poster> do be do be do?
<flacoste> to make sure that one is available for interactive review
<noodles775> On that note, thurs/euro is quite thin if anyone else is available.
<danilos> flacoste: again, that's another requirement people have not been mentioning
<flacoste> i also think it's fine to say, i'll have time for an interactive review in x time
<flacoste> i need to finish this review
<barry> danilos: that is great. it really helps!
<abentley> communication improves most problems.
<barry> noodles775: is not yourself and cprov on that slot?
<noodles775> barry: cprov is no longer in Euro...
 * barry can't keep it all straight
<noodles775> So he's around from about 2pm my time.
<danilos> flacoste: I think our original idea behind OCRs was to have people you can sort of do pre-imp calls with as well... if developers have to break their workflow because there's noone to talk to, it's as bad as reviewers stopping to answer something else
<barry> i guess we need to move cprov to thurs/west?
<flacoste> danilos: i'm not sure we were successfull about the pre-impl with OCR
<danilos> anyway, I'd say this: if there's sufficient OCR coverage for people asking for interactive reviews, please go for +activereviews
<abentley> danilos: It depends on the situation, but I usually want someone who knows the domain intimately for a pre-imp.
<flacoste> and i've come to think that random pre-impl aren't that effective
<bigjools> flacoste: I agree
<flacoste> better to have a pre-impl with somebody with some knowledge in the area
<danilos> flacoste, abentley: I am only talking about rough "pre-imp"... sometimes you'd like to discuss a few things mid-implementation
<flacoste> i think it's fine not to put that responsability on OCR
<barry> flacoste: agreed.  we've tried it enough that we should really re-think pre-imps and not keep trying what doesn't work
<flacoste> well, pre-impl works if you do them
<danilos> anyway, I am happy to try this out, but if I suddenly start seeing a lot more delay in getting reviews because people are working on branches from developers who weren't willing to spend their time to go through a branch together, I'd come back complaining :)
<flacoste> but pre-impl is a separate topic
<flacoste> danilos: sure, that is right
<intellectronica> flacoste: i guess that's a different subject, of how to optimize for collaborative work. it doesn't really have much to do with reviews per-se
<barry> flacoste: right, but lots of branches don't pre-imp, or do mid-imps (which is okay with me).  so if people are often jumping into branches w/o pre-imps we should ask why that is and what problem we're trying to solve with a pre-imp
<barry> flacoste: but yeah, this is off-topic and we're running out of time ;)
<danilos> sorry everyone for making this longer than everybody expected :)
<barry> danilos: yes, please do!
<barry> thanks everybody for this excellent topic.  i think we can continue to discuss it but i'd like to move on now
<barry> [TOPIC]  * cls.links should be a tuple, never a list (menu.py), [bigjools, barry]
<MootBot> New Topic:   * cls.links should be a tuple, never a list (menu.py), [bigjools, barry]
<barry> seems so minor compared to the previous, but in a branch i reviewed for bigjools, i suggested that links = (...) is a better way to go than links = [...]
<barry> class attributes should not be mutable
<barry> but we've lots of established code that uses lists
<sinzui> barry: some do mutate. I was stung by that
<barry> sinzui: right.  if you need an instance to override the class attribute, make a copy
<sinzui> barry: I advised tuples in documentation, but there are some subclasses trying to mutate I think
<danilos> if some do, I'd go for the consistency over the minimal performance gains
<danilos> or, if we can work them around like barry suggests, that's fine too
<barry> danilos: it's not about performance, it's about not getting bit by mutation
<barry> so, i would suggest, always default to a tuple, and rs=me for any such changes in existing code
<barry> if you /have/ to mutate in a subclass, make a copy
<barry> and make the copy nonmutable
<barry> if those rules don't work for a specific case, ping me and we'll try to figure something out
<barry> any objections?
<sinzui> Menus have a lot of overlap. We are doing a lot of typing to make them work. I think we need a one-true-menu-design
<barry> sinzui: indeed.  but that's a whole 'nuther tasty can of worms :)
<bac> and after the migration will we change menu.py to enforce it, since it already makes a check for list or tuple?
<barry> bac: yes, we should do that (and maybe add a deprecation warning for using lists)
<barry> [ACTION] barry to update coding guidelines and look into deprecation warning in menu.py for using links = []
<MootBot> ACTION received:  barry to update coding guidelines and look into deprecation warning in menu.py for using links = []
<bigjools> +1 for good error text if you use the wrong thing
<barry> cprov: are you here?
<bigjools> he's not around
<barry> [TOPIC] cprov: are
<MootBot> New Topic:  cprov: are
<barry> er
<barry> bigjools: okay, the next three items are proposed by cprov, so i think we'll just carry those forward until next week
<bigjools> sounds good
<barry> that leaves 5 minutes for...
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<bigjools> mmm peanuts
<barry> anything on your mind?  or if not, we can take up any previous discussion from today?
<henninge> just saw that you were using "cls" for the class variable
<henninge> taht is good
<barry> henninge: yep.  pep 8
<henninge> I have seen places where klass is still used
<henninge> just mentioning
<barry> (though i had misremembered it as class_ ;)
<abentley> barry: I actually thought intellectronica's topic was going to be about OCRs not giving priority to that activity and doing their own work instead.
<bigjools> were they discriminating against KDE users? :)
<barry> abentley: has that been a problem in practice?
<henninge> bigjools: no, against Germans
<henninge> ;)
<abentley> barry: Now and then.
 * sinzui incorporates pep8.py into his lint checker
 * sinzui removed pylint
<barry> abentley: i think the ocr really has to make arrangements with another ocr if that's the case
<intellectronica> abentley: my advice is, be shameless. if you get bad service, complain. this shouldn't be a problem
<barry> intellectronica: +1
<abentley> barry, intellectronica: Okay.
<barry> cool.  i think with 1 minute left, let's call it a day.  great discussions everyone.  and please feel free to bring issues up on the mlist or to me
<barry> #endmeeting
<MootBot> Meeting finished at 09:44.
<abentley> barry: Thanks.
#launchpad-meeting 2009-09-03
 * Ursinha looks at MootBot
<Ursinha> oh, he's here
<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
<sinzui> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<henninge> me
<rockstar> ni!
<bigjools> me
<henninge> rockstar: that's plural, 'mi' is singular.
<Ursinha> me
<intellectronica> me
<matsubara> Chex, hi
<matsubara> gary_poster, hi
<rockstar> henninge, :)  Making a Monty Python reference.
<gary_poster> me
<gary_poster> thanks
<henninge> oh, don't know that one.
<matsubara> apologies from stub
<henninge> rockstar: Mine was an Esperanto reference
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara>  * DBA report (stub)
<matsubara>  * Proposed items
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>     * barry to continue debug on bug 403606
<matsubara>     * intellectronica to take a look or find someone to take a look on bug 408738
<matsubara>     * matsubara to chase ubottu maintainer to fix regexp used to identify oopses(i.e. oops-tools shouldn't trigger the bot)
<matsubara>         * filed bug 420032 and talked to jussi01 on #ubuntu-bots about it.
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<ubottu> Launchpad bug 408738 in malone "OOPS when rendering bug activity" [High,Triaged] https://launchpad.net/bugs/408738
<ubottu> Launchpad bug 420032 in ubuntu-bots "don't trigger OOPS URL when 'oops-tools' is mentioned" [Undecided,New] https://launchpad.net/bugs/420032
<Chex> matsubara: hi
<matsubara> ubottu, oops-tools
<ubottu> Sorry, I don't know anything about oops-tools
<matsubara> oops-tools
<matsubara> cool. looks like that one was fixed :-)
<Ursinha> \o/
<gary_poster> heh
<Ursinha> ubottu, good boy
<ubottu> Sorry, I don't know anything about good boy
<gary_poster> lol
<intellectronica> matsubara: it's on the radar, but we haven't yet had the chance to fix it. as you can imagine, v3.0 UI is keeping everyone very busy
<matsubara> sinzui, any news about 403606?
<matsubara> intellectronica, right. shall I keep it in the action items list?
<sinzui> no
<intellectronica> matsubara: yes, please
<sinzui> I ask my team to only work on UI
<Ursinha> intellectronica, thanks
<matsubara> thanks intellectronica and sinzui
<matsubara> [action] * barry to continue debug on bug 403606 after finishing 3.0 UI stuff
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<MootBot> ACTION received:  * barry to continue debug on bug 403606 after finishing 3.0 UI stuff
<sinzui> matsubara: Since there was nothing obviously wrong, we cannot judge the scope of the issue
<matsubara> [action]  * intellectronica to take a look or find someone to take a look on bug 408738 after finishing 3.0 UI stuff
<ubottu> Launchpad bug 408738 in malone "OOPS when rendering bug activity" [High,Triaged] https://launchpad.net/bugs/408738
<MootBot> ACTION received:   * intellectronica to take a look or find someone to take a look on bug 408738 after finishing 3.0 UI stuff
<matsubara> sinzui, ok, let's keep on the radar though. that's the most frequent oops with have
<matsubara> right Ursinha ?
<Ursinha> right
<matsubara> ok, thanks
<matsubara> let's move on
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<Ursinha> that's me
<matsubara> Ursinha, stage is yours
<Ursinha> bugs 4-08738 and 4-03606 already mentioned and discussed
<Ursinha> I have bug 422560 for answers, but rockstar told me yesterday he's on it, right rockstar? could you update the bug, pretty please?
<ubottu> Launchpad bug 422560 in launchpad-answers ""Create a FAQ" link fails - Oops! error page" [High,Triaged] https://launchpad.net/bugs/422560
<Ursinha> gary_poster, spm reported this one yesterday: bug 422960, seems to be foundations, what do you say?
<ubottu> Launchpad bug 422960 in launchpad-foundations "appear to be failing to record oops for all +translate HTTP 503 errors" [Undecided,Incomplete] https://launchpad.net/bugs/422960
<rockstar> Ursinha, yup, getting ready to submit for review.
<gary_poster> ...looking...
<Ursinha> rockstar, cool, can you add your precious comments to the bug report? :)
<matsubara> I asked some info from spm on that foundations bug Ursinha
<Ursinha> matsubara, I see
<rockstar> Ursinha, yes ma'am
<Ursinha> thanks rockstar :)
<Ursinha> ah
<Ursinha> rockstar, bug 401631 is the one about +branches timeout, it's committed on edge but I see lots of timeouts on lpnet daily
<matsubara> Ursinha, how about: 497 ValueError: Invalid boundary in multipart form: '' ?
<Ursinha> maybe worth a cherrypick?
<ubottu> Launchpad bug 401631 in launchpad-code "Repeated timeouts when viewing profile page on edge" [High,Fix committed] https://launchpad.net/bugs/401631
<gary_poster> Ursinha, I'll say yes at least on a first take.  We'll at least do some investigation.
<rockstar> Ursinha, I'll chat with thumper about it.
<gary_poster> and either take it or figure out who else should take it :-)
<gary_poster> so it's ours now, anyway
<Ursinha> thanks gary_poster
<matsubara> Ursinha, I'm pretty sure the timeouts on person +branches was CP already
<Ursinha> matsubara, I still see timeouts
<matsubara> Ursinha, it was CP on the 1s. did the CP at least alleviated the problem?
<matsubara> Ursinha, and how about the 497 ValueErrors on edge?
<Ursinha> matsubara, wait man :)
<Ursinha> it seems the problem is better now
<matsubara> I am
<Ursinha> I'll keep watching the next days
<Ursinha> about the value error
<Ursinha> I was going to ask rockstar if that's a code problem
<Ursinha> rockstar, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1341EA197
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1341EA197
<matsubara> [action] ursinha to keep an eye on timeouts for person +branches pages and report back if the CP solved the issue or further action is needed
<MootBot> ACTION received:  ursinha to keep an eye on timeouts for person +branches pages and report back if the CP solved the issue or further action is needed
<rockstar> Ursinha, huh, that's a weird and informationless oops.
<Ursinha> rockstar, agreed about the informationless
<matsubara> [action] ursinha to file a bug for OOPS-1342EA107 (ValueError using the api) and chase someone to fix it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1342EA107
<MootBot> ACTION received:  ursinha to file a bug for OOPS-1342EA107 (ValueError using the api) and chase someone to fix it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1342EA107
<Ursinha> my only hint was the path
<Ursinha> I'll file a bug
<matsubara> thanks Ursinha and rockstar
<Ursinha> ok
<Ursinha> we have one critical bug, already fix committed
<Ursinha> about the failing script, rosetta-poimport, henninge, do you know what's causing that to fail?
<matsubara> Ursinha, isn't that the one that danilo replied to?
<henninge>  Ursinha: yes, it's got to do with sending emails.
<matsubara> s/danilo/jtv and danilo/
<Ursinha> matsubara, yes, but I don't seem to see a conclusion there
<henninge> Ursinha: jtv found the bug and the fix is on the way in
<Ursinha> henninge, awesome :) thanks!
<matsubara> cool
<henninge> Ursinha: we are going to CP it
<Ursinha> henninge, great, will jtv ask for a CP?
<henninge> yes
<henninge> I believe so, at least.
<Ursinha> henninge, that's good
<matsubara> [action] matsubara to chase jtv about CP to fix rosetta-poimport script failure
<MootBot> ACTION received:  matsubara to chase jtv about CP to fix rosetta-poimport script failure
<Ursinha> thakn you :)
<Ursinha> *thank
<Ursinha> thanks all
<Ursinha> matsubara, go ahead
<matsubara> hmm actually I think we should swap some action items Ursinha :-)
<matsubara> but I'll talk about it after the meeting
<matsubara> thanks Ursinha and everyone
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara> Chex, ?
<mbarnett> sorry, i think i might have been distracting him with a question.
<Chex> sorry
<Chex> here is our report for the week:
<Ursinha> losas.. :)
<Chex> Increasing number of 5XX errors in apache pretty much entirely from msn
<Chex> bot on translations pages
<Chex> Bug about missing OOPSes - bug 422960
<ubottu> Launchpad bug 422960 in launchpad-foundations "appear to be failing to record oops for all +translate HTTP 503 errors" [Undecided,Incomplete] https://launchpad.net/bugs/422960
<Chex> Codebrowse is still needing restarting pretty regularly per the Incident Log
<Chex> and thats all from us, unless there are any questions?
<matsubara> Chex, we (as in foundations team) will investigate the 500s. I don't think we should be logging OOPS for those as they don't seem to be hitting the app server. It looks like an issue with the load balancer or apache
<rockstar> Chex, I've looked into that.  There is more to look at, but I think we have some hints on wtf is going on.
 * mbarnett cheers 
<gary_poster> Chex, I'll follow up with you all on the 5XX later today.
<Chex> great, thanks for the response/feedback
<matsubara> Chex, would be awesome if you could add a request that generated one of the 500 to the bug report
<gary_poster> +1
<matsubara> [action] chex to trawl logs and add request that caused 500 error to bug 422960
<ubottu> Launchpad bug 422960 in launchpad-foundations "appear to be failing to record oops for all +translate HTTP 503 errors" [Undecided,Incomplete] https://launchpad.net/bugs/422960
<MootBot> ACTION received:  chex to trawl logs and add request that caused 500 error to bug 422960
<Chex> matsubara: ok, I will look into that for you
<matsubara> thanks Chex
<Chex> matsubara: welcome
<matsubara> let's move on
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> so stuart is not around. I'll email him about the dba report
<matsubara> [action] matsubara to email stub about dba report
<MootBot> ACTION received:  matsubara to email stub about dba report
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> no proposed items
<matsubara> so I think that's all for today
<matsubara> anything else before I close?
<Ursinha> nothing here
<matsubara> ok, so be it
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:27.
<gary_poster> thanks matsubara and Ursinha!
<Ursinha> thanks all!
#launchpad-meeting 2009-09-06
<truthslave> hello
#launchpad-meeting 2010-09-08
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<jelmer> me
<EdwinGrubbs> me
<gary_poster> me
<bac> hi who is here?
<sinzui> me
<adeuring> me
<leonardr> me
<henninge> me
<noodles775> me
<bigjools> me
<abentley> me
<deryck> me
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>   * Mentat update.
<bac>   * Some of the UI reviewers have graduated, but ReviewerSchedule indicates that no one has graduated. Same for UI/Reviews, which still lists people who've left the team.
<bac>   * https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<bac>   * Assertion errors and the webservice (gary)
<bac>  * Peanut gallery
<bac> [topic] outstanding actions
<MootBot> New Topic:  outstanding actions
<bac> bac and lifeless to chat about branch size.
<bac> last week in the AsiaPac meeting rockstar brought up the suggestion that we lower the limit on the diff size for reviews.
<bac> that led to a really good discussion.
<sinzui> U1 is 500 lines
<gmb> me
<bac> lifeless made the point that diff size is a bad proxy for amount of work and suggested we think about it differently
<abentley> bac, isn't there already a diff size of 800?
<bac> <lifeless> I would rather say 'Have no more than N changes in your thing to be reviewed'
<bac> [01:28] <lifeless> where we might say N is - 4.
<gary_poster> hard to count
<bac> abentley: the current soft limit is 800 lines of diff
<gary_poster> abstract
<gary_poster> difficult to communicate and agree on
<gary_poster> prefer soft 800 with negotiation, myself
<bigjools> +1
<bigjools> let's not go over this again
<bac> gary_poster: his point was if in writing up a good cover letter <cough> you would notice your branch is unfocused if you have a bunch of things to mention
<adeuring> i think too we should keep a "soft 800 lines" limit
<henninge> me too
<sinzui> bac: is the proposal about something where I rename a class (1 action) and do a find and replace creating a 3000 line diff? This is 1 change and is good. But adding a schema, mode, vocab, view, template is 5 changes and bad?
<bac> point being, he wants to discuss it with me to come up with a solid proposal.  so let's not dive into it now.
<gary_poster> I'm happy to include that as general advice, bac.  ...ok, fair enough
<bigjools> I think we should use common sense and if the reviewer rejects it, so be it
<bac> just think about the idea of how to measure the *focus* of a branch rather than just the size, although the latter is much easier to determine
<gary_poster> me too with bigjools, but if this is just an alert of a conversation that bac and lifeless will have then...I guess we can move on?
<bac> gary_poster: yes, lets
<gary_poster> cool
<bac> [topic] mentat update
<MootBot> New Topic:  mentat update
<abentley> 800 max is okay, but I find that smaller diffs are much, much easier to review.  I'd rather read 5 200 line diffs than 1 800 line diff.
<bac> stevenk and thumper say the mentoring is going very slowly.  i'm not sure how we can improve that, given the time zone differences.  perhaps if you have a non-time critical MP you can assign it to stevenk to help him get more reviews
<bac> [topic] * Some of the UI reviewers have graduated, but ReviewerSchedule indicates that no one has graduated. Same for UI/Reviews, which still lists people who've left the team.
<MootBot> New Topic:  * Some of the UI reviewers have graduated, but ReviewerSchedule indicates that no one has graduated. Same for UI/Reviews, which still lists people who've left the team.
<bac> i'm unsure who put this on the agenda last week (please put your name on items) but rockstar has updated the wiki
<EdwinGrubbs> it looks like lifeless updated the page. Are there any other graduated UI reviewers besides noodles775, sinzui, and rockstar?
<sinzui> no.
<sinzui> henninge, is in the mentat
<henninge> I am
<sinzui> does anyone else want to become a UI reviewer
<bac> salgado asked about becoming a ui reviewer so i referred him to rockstar
<noodles775> It would be great to get another ... :)
<salgado> noodles775, would you like to be my mentor? ;)
<bigjools> we need more, since one of them is leaving :(
<henninge> who is leaving?
<noodles775> salgado: yeah, I'll be moving to ISd sometime...
 * noodles775 needs to send email out.
<gary_poster> :-(
<salgado> oh, :(
<gary_poster> glad you are still around-ish though :-)
<bac> noodles775: :(
<noodles775> Yep, still around :)
<henninge> noodles775: :(
<bac> who is mentoring henninge?
<bac> perhaps the other can help salgado
<sinzui> I can mentor salgado
<bac> thanks sinzui
<bac> moving on...
<salgado> yay!
<salgado> thanks sinzui
<bac> [topic] * https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<MootBot> New Topic:  * https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<bac> lifeless wants us to read that page and the attached presentation.
<henninge> bac: rockstar is mentoring me
<bac> henninge:  thanks
<bac> and for reviewers to try to think more about architectural issues when reviewing.
<bac> i'll ask him tonight to put his thoughts into an email wrt reviewing.
<bac> [topic] Assertion errors and the webservice (gary)
<MootBot> New Topic:  Assertion errors and the webservice (gary)
<gary_poster> preparing paste 1 sec
<gary_poster> We are currently using assertions to communicate errors that have more appropriate specific exceptions.
<gary_poster> lib/lp/registry/model/product.py:720-ish
<gary_poster>             if license not in License:
<gary_poster>                 raise AssertionError("%s is not a License" % license)
<gary_poster> LookupError?
<gary_poster> lib/lp/answers/model/faq.py:184, and below
<gary_poster>         if search_text is not None:
<gary_poster>             assert isinstance(search_text, basestring), (
<gary_poster>                 'search_text should be a string, not %s' % type(search_text))
<gary_poster> ValueError/TypeError?
<gary_poster> Those are from benji, after a conversation he and I had in regards to bug 413174. He has others.
<gary_poster> If it's not already the case, I'd like to suggest that we only use assertions for communicating exceptions that should never happen, within the current code structure.
<gary_poster> This is particularly important for the webservice.  For the bug I mentioned, benji and I decided that it would be better to have a whitelist approach for exposing errors to webservice users.  He has a branch that will land with this soon, and we'll describe it later.
<ubot5> Launchpad bug 413174 in Launchpad Foundations "API AssertionError could be adapted to a http code (affected: 1, heat: 7)" [High,Triaged] https://launchpad.net/bugs/413174
<gary_poster> But for now...that's my assertion suggestion.
<gary_poster> "within the current code structure": like, method, or function.
<bac> thanks gary_poster
<sinzui> gary_poster, the case I use assertion errors is when the passed object is in the wrong state
<sinzui> Is that a valid use?
<gary_poster> I think that's a ValueError myself.  valid is in the eye of the beholder, but I'd like for us to agree for the LP code base
<sinzui> gary_poster, okay
<benji> something to remember about assertions is that when the interpreter is run with -O, they will be no-ops; so don't use an assertion for any check that shouldn't be optimized away
<bigjools> we should always return a decent error to the webservice caller, surely?  an exception without a webservice_error  files an OOPS.
<bac> benji: +1, as that's easy to forget.
<sinzui> benji, that is why we strive to use raise AssertError. I never accept the other form in a review
<gary_poster> (although I don't think "raise AssertionError()" is optimized away, right?)
<sinzui> sometime the engineer drops the assertion because of that
<gary_poster> right, sinzui
<benji> right, raise AssertionError() is not removed
<sinzui> gary_poster, In the example of deleting a milestone. If the state is bad, the method could return (false, message)
<gary_poster> bigjools: yes, we want to do that.  benji's branch is a way to do that.  some exceptions are not OK to pass back to the webservice user.  It's a security audit question.  I like whitelists for that.
<sinzui> so instead of a ValueError, a success state could be returned
<gary_poster> sinzui, the ValueError, in benji's branch, has the REST/webservice advantage that it returns a 400, plus whatever content is in the exception instantiation.
<sinzui> okay
<bac> gary_poster: thanks for bringing it up.  i look forward  to seeing benji's work
<gary_poster> cool, thanks bac.
<bac> [topic] other stuff?
<MootBot> New Topic:  other stuff?
<henninge> just a little thin
<henninge> g
<henninge> I think
<henninge> Who should set an MP to "approved"?
<gary_poster> heh, good workflow question for MP design generally, I think.
<bac> henninge: ideally, the last required reviewer
<henninge> I have been asked as a reviewer to do it but I think it is the responsibilty of the branch owner to determine when the branch has had enough reviews.
<bac> henninge: but it is so easy to forget
<gary_poster> tarmac will make it easier, IIUC
<gary_poster> because that will be the cue to try and land (again, IIUC)
<abentley> gary_poster, that's not something I've heard.
<bac> henninge: if the dev already knows he needs more reviews he should add them to the MP
<gary_poster> abentley: you know more than I about it, I'm sure
<abentley> gary_poster, oh, you mean it will become necessary with tarmac.
<gary_poster> yes
<henninge> bac: does not happen very often AFICR
<gary_poster> and it will have a more obvious meaning
<henninge> A
<gary_poster> right now it's almost pointless from a practical perspective
<abentley> gary_poster, yes, in the current iteration.  There is ongoing work to split the review state from the merge state.
<henninge> I mean, people add  a UI or r-c review after the code review
<gary_poster> ah, ok, cool
<abentley> If we want, we can write a script that will approve things when the criteria are met.  Then we'd have to decide the criteria.
<bac> henninge: if i think it needs a UI or text review, i suggest that in the code review i do or on irc.
<gary_poster> I'd almost prefer for the MP to do this for me.  If I say I need a release-critical review, a code review, and a ui review, then I can make that gesture in the MP
<gary_poster> s/almost//
<gary_poster> (where abentley's script would be one implementation of what I'm talking about, yeah)
<bac> gary_poster: i think MPs purposely didn't include a bunch of specific behavior b/c other projects have different policies
<bac> gary_poster: yeah, that could be overcome by a script
<henninge> bac: sure but it is still the responsibilty of the one seeking approval to make sure the branch gets all required reviews.
<abentley> gary_poster, variations in approval criteria are a significant obstacle to that.
<henninge> so, setting an MP to "approved" just docuemnts that he followed through on that.
<abentley> gary_poster, which is why doing it on a per-project basis is recommended.
<gary_poster> bac, abentley, gotcha.
<abentley> gary_poster, i.e. with a script.
<gary_poster> right
<gary_poster> henninge, but it can be the approval-seekers responsibility still with automation, yes?
<gary_poster> By requesting more reviews
<henninge> gary_poster: I am not opposed to automation at all! ;)
<gary_poster> ok :-)
<henninge> gary_poster: oh, misread that.
<henninge> gary_poster: you mean, by requesting more reviews an mp would go back to "needs review"?
<gary_poster> I was just about to propose that we had consensus, darn :-)
<gary_poster> yes
<henninge> fine, we do have a consensus ... ;)
<gary_poster> heh, ok
<bac> henninge: so i don't think we need a strict policy here.  the review is a conversation.  please communicate to the dev if you have concerns
<bac> henninge: ok, to move on?
<gary_poster> consensus:
<gary_poster> - approval seeker is of ultimately responsible for the review
<henninge> bac: I was not asking for a policy, just a reminder that you should not wait for the reviewer to change that state - just do it yourself. ;-)
<gary_poster> oh
<gary_poster> that's even easier I think
<bac> henninge: ok
<gary_poster> ok, /me is quiet :-)
<bac> any other topic?
<bac> 3
<bac> 2
<henninge> gary_poster: that does not contradict what you were just saying ... ;)
<bac> 1.5
<henninge> bac: continue ;)
<bac> 1
<gary_poster> aggred henninge :-)
<gary_poster> ree
<bac> #endmeeting
<MootBot> Meeting finished at 09:35.
<bac> thanks y'all
 * bac practices for dallas
<bigjools> bac: you need to practise?
<bac> bigjools: yeah, not really
<bigjools> :)
<gary_poster> :-) thanks bac
<bigjools> thanks bac
<henninge> thanks bac
<henninge> thanks gary_poster ;)
<gary_poster> :-) thank you
#launchpad-meeting 2010-09-09
<bac> lifeless, thumper, rockstar, mwhudson, StevenK: ping
<bac> #startmeeting
<MootBot> Meeting started at 19:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<thumper> here
 * rockstar  
<bac> hi guys
<lifeless> hi
<bac> thumper: did you see that article about the dunedin psycho murderer?
<lifeless> only here vaguely
<thumper> bac: ah... no
<thumper> when?
<bac> it's in the New Yorker magazin
<bac> i threw a link up on FB
<mwhudson> hi
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>   * Mentat update.
<bac>   * Some of the UI reviewers have graduated, but ReviewerSchedule indicates that no one has graduated. Same for UI/Reviews, which still lists people who've left the team.
<bac>   * https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<bac>   * Assertion errors and the webservice (gary)
<bac>  * Peanut gallery
<bac> i guess we're all here but steven
<bac> [topic] mentat update
<MootBot> New Topic:  mentat update
<bac> thumper: has steven been getting any more reviews?
<thumper> not that I've noticed
<thumper> but it has been week 3
<bac> i made an appeal to the AMEU people to direct some towards him if they weren't pressed for time
 * thumper nods
<bac> we'll see if that happens.  i'm not optimistic it will.
<thumper> heh
<thumper> everything is urgent
<bac> especially with team leads breathing down your neck to move those kanban cards...
<bac> thumper: well, do what you can...
<bac> i mentioned lifeless had thoughts about changing the metric for branch size.  i only meant to introduce it but the idea generated lots of reaction
<bac> so, lifeless, i apologize for not getting up with you last week to form a proposal as we agreed.
<rockstar> bac, what kinds of reactions?
 * rockstar COULD read the backchat, but is lazy.
<bac> "too vague", "not a metric"
<bac> nothing terribly hostile
<rockstar> bac, the backchat indicates no interest in change at all, which is disheartening to me.
<bac> i tried to introduce robert's idea:  https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<bac> rockstar: well, it was not presented properly and i think there were just some knee jerk reactions
<rockstar> bac, okay.
 * bac hopes he didn't poison the well
<rockstar> bac, as for me and my house, I will keep my diffs small.
<bac> lifeless: i think we'll need an email about what you'd like to see wrt the ArchitectureGuide
<rockstar> :)
<bac> rockstar: your wife starting to hack launchpad?
<thumper> bac: no, that is choco
<bac> finally gary raised a point about assertion errors and the API
<thumper> he has his own facebook account don't you know
<bac> rs=bac for any work by choco
<rockstar> bac, assertion errors and the API is also something I wonder about.
<bac> choco a fine LSD if ever there was one
<lifeless> bac: huh, why?
<bac> gary and benji have been looking at exception handling and the API.  they want to put together a white list of acceptable exceptions for the API.
<lifeless> bac: what I wrote is what I want
<bac> work to be forthcoming
<lifeless> bac: I can send a mail, but its all there already
<lifeless> in the meeting log from last meeting, which I saw you edit on the wiki :P
<rockstar> bac, a whitelist?  Really?  I don't like that idea.
<bac> lifeless: i think an email hitting the hightlights will be more effective than just posting a URL for people to read.
<rockstar> bac, for instance, we raise BranchMergeProposalExists in the case where someone proposes a merge against a branch where one already exists.
<rockstar> I think that's much more helpful than say, an assertion error.
<bac> lifeless: i like what you're encouraging, but i think a lot of reviewers have a fixed way they work, certain things they look for, etc.  IMO it'll take some effort to change habits.
<bac> rockstar: yes, i think that's the direction gary is headed.
<bac> rockstar: that's much better than raising an AssertionError
<rockstar> bac, okay.  My concern is that, for a whitelist, when we add an exception, we have to add it to the whitelist.
<rockstar> Currently, to make it API-compatible, we just annotate the exception with webservice_error()
<bac> rockstar: valid points you can raise when gary makes his proposal.  this was just a head up, i think.
<rockstar> bac, ah, okay.
<lifeless> bac: perhaps we can refine it here then
<lifeless> bac: the idea is that they - check the metrics; discuss the patch in the context of the values & goals on that page.
<bac> rockstar: gary and benji also made the reminder that assert() shouldn't be used as it can be optimized away...
<rockstar> bac, yeah.  assert() is less helpful than an AssertionError
<lifeless> FWIW assert and -O aren't relevant for us, though I agree in principle (and we don't use assert() for that very reason in bzr)
<mwhudson> it is (or at least was) also surprisingly common for people to break lines by doing
<mwhudson> assert (condition,
<mwhudson>     message)
<rockstar> mwhudson, ew.
<mwhudson> anyway, there seems to be a lot of talk here about partially presented ideas :-)
<bac> mwhudson: yeah, i used to see syntactically correct but completely wrong asserts a lot
<rockstar> bac, it looks like we're summing up here.  I have a proposal.
<bac> lifeless: i agree with your ideas regarding the values and goals.
<rockstar> (a full proposal)
<bac> lifeless: i just don't know how to make it happen, other than what you're already doing, which is very helpful.
<bac> rockstar: sure
<lifeless> bac: ok, so I'll send a short message asking for this.
<rockstar> bac, I propose that we abolish the "javascript" review, and just make it a regular code review.
<lifeless> bac: and perhaps you could follow up in the review team meetings asking whether folk are finding this to work well?
<bac> lifeless: certainly
<rockstar> bac, I'll be updating the JavascriptReviewGuidelines a bit more, as I've learned a bunch about writing high performance javascript recently, and our code makes me cringe.
<rockstar> I think we could make everyone a javascripter if they had to review javascript and have things explained to them.
<thumper> +1 to rockstar's proposal
<bac> rockstar: i look forward to hearing what you've learned.
<rockstar> bac, there will be an email today or tomorrow.
<bac> becoming more competent in JS is one of my goals...
<rockstar> (and I'll be participating in performance Tuesday from now on)
<bac> is there anything else you'd like to talk about?
<rockstar> Not from me.
<bac> thumper: when you see StevenK would you remind him of the meeting time?
<thumper> bac: ack
<bac> thanks guys.
<bac> #endmeeting
<MootBot> Meeting finished at 19:28.
<Ursinha> OOPS-1713EB2282
<ubot5`> https://lp-oops.canonical.com/oops.py/?oopsid=1713EB2282
#launchpad-meeting 2018-09-03
<pjdc> a
#launchpad-meeting 2020-08-31
<kylin_lux> hello
