[03:00] <barry> #startmeeting
[03:00] <MootBot> Meeting started at 21:02. The chair is barry.
[03:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[03:01] <barry> hi everybody and welcome to this week's asiapac reviewers's meeting.  who's here today?
[03:01] <barry> jml, mwhudson ping?
[03:02] <jml> hi!
[03:02] <jml> I'm here
[03:02] <mwhudson> oh hi
[03:02] <barry> hi!  any word from thumper?
[03:02] <mwhudson> well, he's at guadec
[03:02] <spiv> Hi
[03:02] <barry> mwhudson: ah, right
[03:02] <barry> spiv: hi!
[03:03] <barry> [TOPIC] agenda
[03:03] <MootBot> New Topic:  agenda
[03:03] <barry>  * Roll call
[03:03] <barry>  * Next meeting
[03:03] <barry>  * Action items
[03:03] <barry>  * Queue status
[03:03] <barry>  * Mentoring update
[03:03] <barry>   * cprov mentor, abentley mentor
[03:03] <barry>  * Review process
[03:03] <barry>   * Ensure that all outgoing http connections go through a proxy (intellectronica)
[03:03] <barry>   * Ensure in database code that non-DB state is reset at transaction
[03:03] <barry>   boundaries (flacoste)
[03:03] <barry> [TOPIC] next meeting
[03:03] <MootBot> New Topic:  next meeting
[03:04] <barry> next week, same time and place?
[03:04] <mwhudson> sure
[03:04] <barry> that will likely be my last meeting until august
[03:05] <mwhudson> hm
[03:05] <mwhudson> would another time be more convenient for you?
[03:05] <barry> mwhudson: probably not.  i'll be sprinting on the 22nd and camping on the 29th (for you, my 21st and 28th)
[03:05] <barry> mwhudson: but would you like to chair those meetings instead?
[03:06] <mwhudson> um, ok
[03:07] <barry> [AGREED] mwhudson to chair last two asiapac meetings in july
[03:07] <MootBot> AGREED received:  mwhudson to chair last two asiapac meetings in july
[03:07] <barry> [TOPIC] Action items
[03:07] <MootBot> New Topic:  Action items
[03:07] <barry>  * mwhudson to start discussion on page test purpose
[03:07] <mwhudson> um, yeah, sorry
[03:08] <mwhudson> carry it forward, i do really mean to do this :)
[03:08] <barry> mwhudson: np, but can you start that up before our montreal sprint?  i'm hoping we can actually jfdi on some things when we're up there
[03:08] <mwhudson> barry: that's in two weeks time?
[03:08] <barry> mwhudson: yep
[03:08] <mwhudson> ok
[03:08] <barry> mwhudson: awesome, thanks
[03:08] <barry>  * thumper to submit a bug for moving ftests contents to tests
[03:08] <barry> he's not here but i think this wasn't done
[03:09] <mwhudson> i don't think so either
[03:09] <barry> cool, we'll just carry it forward
[03:09] <barry>  * barry to ask lifeless to summarize what he knows about the PQM Mysteries (e.g. autopacking bug losing branches)
[03:09] <barry> i suck
[03:09] <barry>  * jml to find out how divmodders test their javascript
[03:09] <jml> barry: I emailed their list and got some interesting replies.
[03:10] <jml> barry: I'll actually need to get my hands dirty to finish the exercise.
[03:10] <jml> barry: and I haven't had a chance yet.
[03:10] <barry> jml: cool.  this is another thing i'm hoping we attack in montreal, so any information you can provide before then will be great
[03:11] <barry> [TOPIC]  * Queue status
[03:11] <MootBot> New Topic:   * Queue status
[03:11] <barry> nothing really from me on that.  anything from you guys?
[03:11] <jml> barry: the summary is (from memory): JSUnit + subunit run in tests, boy we wish we had a well-tested fake DOM.
[03:11] <jml> none from me.
[03:11] <barry> jml: very interesting
[03:12] <mwhudson> we still have a queue? :)
[03:12] <barry> mwhudson: :)
[03:12] <barry> 1.99 baby!
[03:12] <jml> barry: i.e. they haven't actually changed it much since I set it up.
[03:12] <barry> jml: ah.  are they having much success with it?
[03:13] <jml> barry: I think so. They say the lack of integration tests is kind of forcing them to separate as much logic as possible.
[03:14] <jml> which is kind of a pyrrhic victory
[03:14]  * barry nods
[03:15] <barry> jml: thanks for the feedback.  we're going to see a lot more js this next release and i think many of us are worried about testing (if we aren't already)
[03:15] <jml> barry: anyway, I'll hack around with their stuff and send an email to the list.
[03:15] <barry> jml: thanks!
[03:16]  * barry skips the mentoring topic
[03:16] <barry> [TOPIC]  * Review process
[03:16] <MootBot> New Topic:   * Review process
[03:16] <barry>   * Ensure that all outgoing http connections go through a proxy (intellectronica)
[03:16] <barry> let me see if i can channel him
[03:16] <mwhudson> ok, so this is a bit wrong
[03:16] <barry> mwhudson: ?  (go ahead)
[03:16] <mwhudson> a better summary would be 'be aware of the network environment your code will see in production'
[03:17] <mwhudson> because, for example, on vostok you _don't_ have to go through a proxy
[03:18] <barry> mwhudson: very good point.  do we have any kind of comprehensive description of the environment code will see on various machines?
[03:18] <mwhudson> i don't know if it's because i spend a lot of time talking to the OSAs for one reason and another, but i do feel that i perhaps know more about the production systems than most developers
[03:19] <jml> having shell access to some of the helps :)
[03:19] <barry> mwhudson: i would dearly love to have a wiki page describing the prod system environments *for the developers and reviewers*
[03:19] <mwhudson> there is https://devpad.canonical.com/~mthaddon/Launchpad_Production_System.png
[03:19] <mwhudson> but it doesn't have outgoing connections
[03:19] <mwhudson> jml: yeah, probably
[03:19] <barry> mwhudson: right
[03:20] <jml> barry: there's https://launchpad.canonical.com/LaunchpadProductionDocumentation linked to from https://devpad.canonical.com/~joey/
[03:20] <jml> barry: I agree that more docs on the production systems would be a good thing.
[03:20] <mwhudson> jml: right, and i've already found a bunch of out of date stuff on this :)
[03:20] <mwhudson> (it doesn't have the new code import system on it)
[03:20] <jml> barry: perhaps the solution is to incrementally improve the ones we have.
[03:21] <jml> mwhudson: *nod* I saw that too :)
[03:21] <Rinchen> (if you have changes, send them to Joey :-)
[03:21] <barry> Rinchen: howdy!
[03:21] <barry> Rinchen: do you think LaunchpadProductionDocumentation is the right place to capture this information?
[03:21] <Rinchen> hi :-)
[03:21] <barry> if so, i will send a message to the ml asking people to update it with what they know
[03:22] <barry> if not, we can start another page
[03:22] <Rinchen> probably.... but that page is "owned" by the LOSAs
[03:22] <jml> Rinchen: hi
[03:22] <Rinchen> so one thing we should do is ask them to fill in any holes we have
[03:22] <barry> Rinchen: ah, then it's probably /not/ the right place.  i want a page that is for devs and reviewers
[03:22] <Rinchen> the goal of the devpage page was to capture all of the more operational aspects in one place
[03:23] <mwhudson> barry: i'm not sure that's a very meaningful distinction
[03:23] <Rinchen> it depends really on what kinds of documentation you want captured
[03:23] <jml> use cases!
[03:23] <Rinchen> there is no reason that page can't be used by devs and reviewers for example
[03:24] <barry> what i think would be useful would be special environmental considerations you need to know when writing code or reviewing code destined for some production machine
[03:24] <barry> e.g. vostok can make outgoing connections
[03:24] <barry> Rinchen: cool, if you tell me LPD is the right place, we'll use that!
[03:24] <mwhudson> i think as a practical thing, launchpad devs do really need to know a fair bit about operational things
[03:25] <Rinchen> from you said barry, yep that's the right place.
[03:25] <barry> mwhudson: +1
[03:25] <Rinchen> there is also a lot of config information that sinzui build into the config tests
[03:25] <barry> Rinchen: cool
[03:25] <mwhudson> at least in part because there are 30 devs and 3 OSAs
[03:25] <spiv> mwhudson: I agree.  Developers can't ignore deployment reality, as much as they might like to :)
[03:25] <Rinchen> it's like a whole config user guide in the tests
[03:26] <Rinchen> barry, your other option would be a separate reviewer checklist
[03:26] <barry> Rinchen: i think i'd like to keep it all in one place, ideally
[03:26] <spiv> barry: +1 for one place
[03:26] <barry> Rinchen: mind if i email the list asking to update that page with operational details for the dev & reviewer?
[03:26] <Rinchen> then LPD is probably the right place.  I don't think the LOSAs would mind
[03:26] <Rinchen> barry,  go4it
[03:27] <mwhudson> maybe we could add "will the code be able to make the network connections it needs to make" and a link to LPD to the codereviewerchecklist
[03:27] <Rinchen> you can probably just email the losas and ask them
[03:27] <barry> mwhudson: +1
[03:27] <barry> Rinchen: +1
[03:27] <barry> [ACTION] barry to email losas and devs about LPD page
[03:27] <MootBot> ACTION received:  barry to email losas and devs about LPD page
[03:28] <Rinchen> ok, I'm up by 2 so it's time to cash out while my luck is good. :-) Enjoy your meeting.
[03:28] <barry> Rinchen: cheers!
[03:28] <mwhudson> we should/could ask tom to include outgoing traffic on one of those diagrams
[03:28] <barry> mwhudson: good idea
[03:28] <barry>   * Ensure in database code that non-DB state is reset at transaction
[03:28] <barry>   boundaries (flacoste)
[03:29] <barry> i think i know what this is about, but it's a new item so i want to give flacoste a shot at it on wednesday
[03:29] <barry> unless y'all have any comments about it?
[03:29] <mwhudson> well, step 1 is "try not to have non-DB state" isn't it?
[03:30] <barry> mwhudson: i would think so
[03:31] <mwhudson> but i admit it had totally failed to occur to me that cachedproperty might muck around with this
[03:31] <barry> yep
[03:32] <barry> well, that's it from me.  anything from you guys?
[03:32] <jml> umm one thing
[03:32] <jml> why is review-submit checking for sampledata changes?
[03:32] <jml> maybe it's something in my local set up, but I'm getting false positives all the time.
[03:33] <barry> jml: that was added by sinzui as a defense against sampledata getting out of date
[03:33] <barry> the problem is that it was /already/ out of date, so we need to land a branch to just fix the damn thing
[03:33] <barry> i almost got to it today, but will probably do one tomorrow
[03:33] <jml> what does "out of date" mean here?
[03:33] <barry> jml: changes to the database not reflected in sampledata
[03:34] <barry> i.e. a column gets added with no default
[03:34] <barry> or, really, e.g. :)
[03:34] <jml> barry: hmm. so it will flag the developer if they've been mucking around with their launchpad.dev?
[03:34] <barry> jml: yep
[03:34] <jml> barry: I don't think that's such a good idea.
[03:34] <barry> jml: or at least, i think so
[03:35] <barry> jml: the issue is that we've had problems with sampledata not matching the schema and this is suposed to prevent such breakage
[03:36] <spiv> That sounds like something the test suite should check, rather than review-submit?
[03:36] <jml> barry: I think the test suite is a better place to put such a check.
[03:36] <spiv> jml: snap
[03:37] <barry> it's currently a 'make lint'.  i don't remember exactly why it was done that way
[03:37] <barry> i seem to remember the reasoning was sound at the time ;)
[03:38] <jml> well, pylint already gives me enough false positives. having more checks that do so seems like a step backwards to me.
[03:38] <spiv> Mail the list/sinzui about it?
[03:38] <barry> spiv: +1
[03:38] <jml> ok.
[03:39] <barry> anything else?
[03:39] <jml> nope
[03:39] <barry> cool.  have a great week everybody!
[03:39] <barry> #endmeeting
[03:39] <MootBot> Meeting finished at 21:41.
[03:39] <jml> barry: thanks
[03:40]  * mwhudson disagrees with MootBot's clock