[03:00] <barry> #startmeeting
[03:00] <thumper> hi barry
[03:00] <thumper> I'll have to duck out a bit early
[03:00] <barry> thumper: np, we can make it short
[03:00] <thumper> barry: you'll be happy to know I'm working on branch merge queues
[03:00] <mwhudson> me
[03:00] <barry> welcome to this weeks' asiapac reviewers meeting.  who's here today?
[03:00] <barry> thumper: excellent!
[03:00] <spiv> Hello.
[03:00] <barry> spiv: hi
[03:00] <barry> mwhudson: hi
[03:01] <barry> jml: ping?
[03:01] <jml> hi
[03:01] <barry> jamesh: hi
[03:01] <barry> jml: hi
[03:01] <jamesh> hi
[03:01] <barry> [TOPIC] agenda
[03:01] <barry> ok, screw you mootbot
[03:02] <barry>  * Roll call
[03:02] <barry>  * Next meeting
[03:02] <barry>  * Action items
[03:02] <barry>  * Queue status
[03:02] <barry>  * Mentoring update
[03:02] <barry>    * new recruits?  (leonardr, abentley, mars)
[03:02] <barry>  * Review process
[03:02] <thumper> barry: mootbot isn't listening
[03:02] <barry>   * (intellectronica) JS-related templates should be tested (as much as possible).
[03:02] <barry>   * (barry) don't assign GQ after on-call session?
[03:02] <barry> thumper: like a child in front of a wii
[03:02] <barry>  * Next meeting
[03:02] <barry> same time next week?
[03:02] <spiv> barry: also like an adult in front a wii...
[03:03] <barry> spiv: :)
[03:03] <mwhudson> barry: sure
[03:03] <barry> i may miss next week though.  i'm not sure yet, but i might be picking my wife up from the airport at this time
[03:03] <barry> i'll send an email if i have to switch/cancel
[03:03] <thumper> ok
[03:04] <barry>  * Action items
[03:04] <barry>  * mwhudson to start discussion on page test purpose
[03:04]  * thumper didn't file that bug
[03:04] <mwhudson> didn't do this mostly through slackness
[03:04] <mwhudson> will do it before the next meeting
[03:04] <barry> k, we'll just continue them both ;)
[03:05] <barry> there was definitely some hearty discussion on both subjects at the last ameu so i think these are good things to start talking about
[03:05] <barry>  * Queue status
[03:05] <mwhudson> i noticed flacoste said something that made me aaargh
[03:05] <barry> not much from me here.  any comments on your side?
[03:06] <barry> mwhudson: what?
[03:06] <mwhudson> the pqm queue is more of a bother than the review queue at the moment
[03:06] <barry> mwhudson: definitely.  pqm needs some serious love
[03:06] <barry> it's driving people crazy
[03:06] <jml> mwhudson: is that what flacoste said?
[03:07] <mwhudson> <flacoste>      sinzui: testing template in doc/*-pages is not our standard, although it might make a good idea
[03:07]  * thumper stabs doc/*-pages
[03:07] <mwhudson> "aaaaaargh, no, doc/* should be documentation!"
[03:07] <jml> mwhudson: +1
[03:07] <thumper> should be browser/tests in unit tests!!!
[03:07] <mwhudson> but anyway, --> mailing list
[03:07] <barry> +1
[03:07] <jml> thumper: +1
[03:07] <barry> yeah -> ml
[03:08] <mwhudson> barry: (about the queues again) to be fair, it's mostly not pqm
[03:08] <mwhudson> it's our test suite
[03:08] <barry> well, there /are/ issues with pqm losing branches, sending false success emails, etc
[03:08] <mwhudson> though the disappearing merges thing seems to be a bzrlib/pqm thing
[03:08] <mwhudson> yes
[03:08] <mwhudson> btw, mthaddon and lifeless uncovered some clues about that this morning
[03:09] <barry> do tell!
[03:09] <thumper> thank <insert deity here>
[03:09] <mwhudson> barry: it's something to do with autopacks
[03:10] <jamesh> so every tenth commit disappears or something?
[03:10] <spiv> That's Weird(TM).
[03:10] <barry> wow
[03:10] <mwhudson> when pqm pushes to devpad after a successful test suite, it can trigger an autopack
[03:10] <mwhudson> and sometimes 'things go wrong"
[03:10] <thumper> oh FFS
[03:11] <mwhudson> for example: https://pastebin.canonical.com/6500/
[03:11] <mwhudson> so there are two bugs really, that this happens (a bzr problem)
[03:11] <mwhudson> and that the user visible symptom is so mysterious (a pqm problem)
[03:11] <mwhudson> by chance, beuno had the same problem pushing to launchpad today
[03:12] <barry> mwhudson: can we turn autopacks off?
[03:12] <spiv> Not without hacking bzr.
[03:12] <barry> :-(
[03:12] <mwhudson> and we probably managed to grab enough data to reproduce
[03:12] <mwhudson> barry: now you know as much as me, we should get lifeless to summarize what he knows to the list
[03:12] <mars> mwhudson, related question: lifeless was wondering if PQM was sending emails - he hadn't seen an exception email for a long time.  Was it sending them?
[03:12] <barry> [ACTION] barry will ask lifeless to summarize what he knows about The PQM Mystery to the ml
[03:13] <jamesh> autopacking is desirable when it works
[03:13] <mwhudson> mars: yes, it seems that they disappeared somewhere in his own email setup
[03:13] <barry> btw, do any of you have any thoughts about pqm groking looms?
[03:13] <mars> mwhudson, sorry, he was wondering about PQM *error emails*
[03:13] <mars> ah
[03:13] <mars> mwhudson, cool
[03:13] <mwhudson> mars: probably easier to ask him than me :)
[03:13] <jamesh> barry: if PQM grokked loom threads, sure.
[03:14] <jml> barry: I think it would be good to clarify what that meant.
[03:14] <barry> really, i just want to pqm-submit a loomed branch
[03:14] <thumper> barry: I think we'd just have to have the loom plugin on the pqm instance
[03:14] <jml> barry: like jamesh is getting at, we probably want to land a thread of a loom, rather than a whole loom
[03:14] <thumper> barry: and fix the push bug
[03:14] <jamesh> just loading the plugin would probably give you "merge which ever thread was active when I just published to devpad"
[03:14] <spiv> If a) PQM received merge directives, and b) had the loom plugin installed
[03:14] <spiv> Then it would Just Work.
[03:14] <barry> jml: interesting, that's not quite how i use looms, but i can see what you mean
[03:15] <barry> it gets tricky, eh?
[03:15] <thumper> jamesh: there is a bug where push over bzr+ssh doesn't work properly
[03:15] <barry> let me ask a meta-question: are we submitting bug reports for these issues (he ask, knowing that he has not done so)
[03:16] <jml> barry: sometimes we are.
[03:16] <thumper> bzr-loom product
[03:16] <jml> barry: I file bugs on bzr-loom fairly often :)
[03:16] <barry> :)
[03:16] <barry> cool, thanks
[03:16] <thumper> https://bugs.edge.launchpad.net/bzr-loom/+bug/201613
[03:16] <ubottu> Launchpad bug 201613 in bzr-loom "pushing looms does not work properly" [Critical,Triaged]
[03:17] <jamesh> having PQM do merge directives might be the way forward
[03:17] <jml> yeah.
[03:17] <thumper> I think Odd_Blok1 may be looking at this
[03:17] <thumper> *may*
[03:18] <thumper> and moving along...
[03:18] <jamesh> of course, the way merge directives specify the revision ID to merge might cause a bit of havoc with the way we use PQM, pushing fixes after submitting the merge
[03:18] <barry> i'm just afraid that pqm is currently hampering productivity (it is mine) so we should spend some Real Time fixing things
[03:19] <thumper> jamesh: right now, we'll have the same problem with my current work
[03:19] <barry> jamesh: yeah, i kind of wish we couldn't do that, although i've used it to my advantage before
[03:19] <thumper> jamesh: however I'm thinking of a work around
[03:19] <spiv> jamesh: well, the proper fix to that is having actual queue management
[03:19] <barry> sorry for getting off track... back to the agenda
[03:19] <barry>  * Mentoring update
[03:20] <barry> folks were generally positive in ameu about inviting new reviewers.  gmb, intellectronica, and i all offered to mentor after 2.0 is out
[03:20] <barry> i think abentley will be the first invitee
[03:20] <thumper> abentley said he is happy to have a go after 2.0
[03:20] <barry> with leonardr and mars following
[03:21] <barry> thumper: great
[03:21] <barry> any other thoughts here?
[03:22] <barry>  * Review process
[03:22] <barry>   * (intellectronica) JS-related templates should be tested (as much as possible).
[03:22] <barry> that's a new one, so i don't know much about where tom's going with it
[03:22] <barry> but i can guess that as we use more js, we need to find a way to test it
[03:22] <thumper> right
[03:22] <thumper> I was bitten by this recently
[03:23] <thumper> the pagetests passed
[03:23] <thumper> but oopsed in reality
[03:23] <barry> that's not good :)
[03:23] <jamesh> Xvfb + firefox + AppServerLayer + ?
[03:24] <jml> can we find out what google do?
[03:24] <mwhudson> i wonder if it involves selenium and a very large number of machines
[03:24] <jamesh> jml: the google web toolkit they released a while ago had "compile java code to javascript"
[03:24] <jamesh> and test with java tools
[03:25] <mars> barry, I think I know
[03:25] <jml> hmm.
[03:25] <mars> about intellectronica's idea
[03:25] <barry> mars: go ahead
[03:25] <mwhudson> it is quite hard to google for things about google
[03:25] <jml> jamesh: I don't see how that gets you a way to test "how does this work in firefox"
[03:26] <mars> the iframe bug, and the rollback issue from edge with bad JS ruining everything, was a result of us not testing any JavaScript.
[03:28] <barry> yep.  it's only going to get more serious as we move forward
[03:28] <mars> testing JS with JSUnit or something similar would at least give us an idea of which code could cause failure if it doesn't load properly.
[03:28] <mars> barry, exactly
[03:28] <barry> anyway, we'll see what comes up on wednesday
[03:28] <jml> jsunit would definitely be a step in the right direction
[03:28] <jml> and you can run it from your python test suite using subunit
[03:29]  * jml did something like that at divmod.
[03:29] <mars> interesting
[03:29] <mars> it may not even take extensive testing, just 'what happens if X bombs out'
[03:29] <barry> indeed.  jml if you want to post some of your experience to the ml, that would be great
[03:29] <jml> the big issue that stopped us from using it more was that spidermonkey had no dom.
[03:30] <mars> in this case, inlinehelp.js error'd out, and took the portlets expansion code with it :(
[03:30] <jml> barry: sure. I'll find out what the divmodders are doing for js testing nowadays and post something.
[03:31]  * jml might have a spare moment to do that soon.
[03:31] <barry> i'll just add that 1) we need a more extensive js coding guideline, and 2) reviewing js is difficult!
[03:31] <barry> jml: thanks
[03:31] <barry> moving on...
[03:31] <barry>   * (barry) don't assign GQ after on-call session?
[03:32] <barry> so, i know it's our policy that we should be assigning any left over GQ branches at the end of our on-call, but i think maybe we should stop that practice
[03:32] <barry> i think instead, we should just leave them there for the next day's ocr
[03:32] <mwhudson> i think that probably makes sense
[03:32] <barry> thing is, i think few people have time to do reviews outside their ocr
[03:32] <thumper> sounds reasonable
[03:33] <mwhudson> if someone assigns a branch to me, i can guarantee that i wouldn't notice unless i got emailed about it too
[03:33] <barry> i run bac's pr script, but still, i know what you mean
[03:33] <mwhudson> jml just sms-ed me to say that his machine just hung
[03:33] <barry> okay cool.  i run all the crazy ideas by you guys first.  we'll see what the ameus have to say
[03:34] <barry> dang
[03:34] <barry> well, i'm done anyway.  anything from y'all?
[03:34] <mwhudson> nothing leaps to mind
[03:34] <barry> #endmeeting
[03:35]  * thumper has to go now
[03:35] <thumper> barry: good timing
[03:35] <barry> thanks everyone, have a good week
[03:35] <barry> :)
[03:40] <jml> back.
=== Odd_Blok1 is now known as Odd_Bloke
=== mrevell is now known as mrevell-lunch
=== salgado-afk is now known as salgado
=== EdwinGrub is now known as EdwinGrubbs
=== salgado is now known as salgado-lunch
=== salgado-lunch is now known as salgado
=== salgado is now known as salgado-afk
=== salgado-afk is now known as salgado
=== mwhudson__ is now known as mwhudson