| === rocksta`` is now known as rockstar | ||
| === salgado-afk is now known as salgado | ||
| === bigjools-afk is now known as bigjools | ||
| barry | #startmeeting | 15:00 |
|---|---|---|
| MootBot | Meeting started at 09:00. The chair is barry. | 15:00 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 15:00 |
| barry | hello everyone and welcome to this week's ameu reveiwers meeting. who's here today? | 15:00 |
| bigjools | me | 15:00 |
| bac` | me | 15:00 |
| allenap | me | 15:00 |
| gmb | me | 15:00 |
| adeuring | me | 15:00 |
| salgado | me | 15:00 |
| henninge | me | 15:00 |
| jtv | me | 15:00 |
| beuno | me | 15:01 |
| intellectronica | me | 15:01 |
| mars | me | 15:01 |
| flacoste | me | 15:02 |
| barry | BjornT: ping | 15:02 |
| barry | cprov: ping | 15:02 |
| barry | danilos: ping | 15:02 |
| barry | EdwinGrubbs: ping | 15:02 |
| cprov | me | 15:02 |
| danilos | me | 15:02 |
| EdwinGrubbs | me | 15:02 |
| barry | rockstar: ping | 15:03 |
| barry | sinzui: ping | 15:03 |
| sinzui | me | 15:03 |
| barry | i think that's everyone | 15:03 |
| barry | [TOPIC] agenda | 15:03 |
| MootBot | New Topic: agenda | 15:03 |
| barry | * Roll call | 15:03 |
| barry | * Action items | 15:03 |
| barry | * Mentoring update | 15:03 |
| barry | * Peanut gallery (anything not on the agenda) | 15:03 |
| barry | * naming of unittest methods (Camel``Case or under_scores) (henninge) | 15:03 |
| barry | * order of assert parameters (expected, observed) (hennige) | 15:03 |
| barry | * Driving maintainable Javascript code (intellectronica) | 15:03 |
| barry | * Modularization and unit testing are strongly encouraged | 15:03 |
| barry | * Refactoring code after a UI review is often a good idea | 15:03 |
| barry | * The upper limit for JS diffs is 1600 lines (because javascript is so verbose) | 15:03 |
| barry | [TOPIC] action items | 15:03 |
| MootBot | New Topic: action items | 15:03 |
| barry | i think the only one outstanding is gary's and he's away today | 15:04 |
| barry | so... | 15:04 |
| barry | [TOPIC] mentoring update | 15:04 |
| MootBot | New Topic: mentoring update | 15:04 |
| barry | i think we have just one mentored reviewer left, and noodles isn't here today | 15:04 |
| barry | so... | 15:04 |
| barry | [TOPIC] peanut gallery | 15:05 |
| MootBot | New Topic: peanut gallery | 15:05 |
| barry | * naming of unittest methods (Camel``Case or under_scores) (henninge) | 15:05 |
| barry | * order of assert parameters (expected, observed) (hennige) | 15:05 |
| barry | henninge: the floor is yours | 15:05 |
| henninge | Hi | 15:05 |
| henninge | Yesterday cprov and I ran into this discussion about how to name unittest methods. | 15:05 |
| henninge | I have always done test_the_frobnob, while his branch had testTheFrobnob | 15:06 |
| henninge | The argument is: Coding style for methods is CamelCase | 15:06 |
| cprov | yes, and I've used CamelCase for most of the soyuz unittest, and it's not looking good. | 15:06 |
| salgado | isn't the policy to use test_methodName()? | 15:07 |
| intellectronica | i have a feeling of deja vu | 15:07 |
| * barry would greatly prefer anything make makes us more pep 8-y | 15:07 | |
| intellectronica | salgado: exactly | 15:07 |
| mars | I thought unit_tests_were_the_exception? | 15:07 |
| henninge | but these methods are never called directly and only appear in test runner | 15:07 |
| henninge | output | 15:07 |
| bigjools | salgado: +1 | 15:07 |
| jtv | this was changed a few months back, but I don't remember what it was changed to exactly. | 15:07 |
| gmb | barry: +1 | 15:07 |
| flacoste | we already discussed that | 15:07 |
| flacoste | the convention for unit test is: | 15:08 |
| flacoste | test_methodName_with_particular_condition | 15:08 |
| bac` | flacoste: that's what i remember too. | 15:08 |
| henninge | ah, that was my faint memory, too. | 15:08 |
| flacoste | we had this discussion like 6-8 months ago | 15:08 |
| barry | flacoste: yes | 15:08 |
| salgado | When testing a specific Launchpad method, a mix of PEP 8 and camel case is | 15:08 |
| salgado | used, e.g. test_fooBarBaz() | 15:08 |
| bigjools | is it not in the style guide? | 15:08 |
| flacoste | barry: somebody should have updated the wiki ;-) | 15:08 |
| salgado | https://dev.launchpad.net/TestsStyleGuide#Functional and Unit Tests | 15:09 |
| salgado | flacoste, it's there! | 15:09 |
| salgado | In general, you should follow Launchpad coding conventions (see PythonStyleGuide), however when naming test methods: | 15:09 |
| salgado | ... | 15:09 |
| flacoste | perfect! | 15:09 |
| barry | flacoste: time machine activated! | 15:09 |
| * bigjools sees a rapid end to the discussion coming | 15:09 | |
| flacoste | anybody wants to rehash this? | 15:09 |
| cprov | cool, problem solved. | 15:09 |
| henninge | second item | 15:09 |
| henninge | I have seen that LaunchpadTestCase uses assert(expected, observed) | 15:10 |
| henninge | and have used the asserts that way. | 15:10 |
| henninge | But I see a lot of (obseved, expected). | 15:10 |
| barry | henninge: +1 for (expected, observed) | 15:11 |
| henninge | barry: me, too | 15:11 |
| bigjools | do you mean assertEqual? | 15:11 |
| henninge | is there a guide line for that already? | 15:11 |
| intellectronica | i don't understand | 15:11 |
| henninge | bigjools: yeah | 15:11 |
| henninge | oh sorry, I meant assert*(e,o) | 15:11 |
| henninge | btw, I found out that not everybody knows about LaunchpadTestCase | 15:12 |
| salgado | intellectronica, self.assertEquals(sut_output, 'what I expect') instead of self.assertEquals('what I expect', sut_output) | 15:12 |
| barry | henninge: could you please update https://dev.launchpad.net/TestsStyleGuide | 15:12 |
| intellectronica | i don't think it's worth having a policy on that. it doesn't matter | 15:12 |
| bigjools | I don't either | 15:13 |
| salgado | agreed | 15:13 |
| barry | actually, i think it's better to be consistent because it's easier to debug | 15:13 |
| bigjools | how does it make it easier? | 15:13 |
| barry | bigjools: you have to think less when you see failing output | 15:13 |
| henninge | yes, it's for clarity. | 15:14 |
| intellectronica | if you want to make it really easy you can do `expected = expr \n observed = expr \n assertEqual(expected, observed)` | 15:14 |
| henninge | intellectronica: true | 15:15 |
| bigjools | yeah, I quite like that style | 15:15 |
| henninge | that is fine by me, too. | 15:15 |
| barry | intellectronica: it would be better to have that in the framework | 15:15 |
| intellectronica | but again, i don't think we should force this. just remember that it's a possibility | 15:15 |
| bigjools | I think encouraged but not enforced | 15:15 |
| barry | just sayin', all things being equal, we prefer (expected, observed) | 15:15 |
| bac` | bigjools: +1 | 15:15 |
| barry | bigjools: +1 | 15:16 |
| henninge | bigjools: +1 | 15:16 |
| * bigjools is not used to this many people agreeing with him | 15:16 | |
| barry | henninge: can you capture this in the wiki? | 15:16 |
| henninge | barry: will do | 15:16 |
| barry | [ACTION] henninge to capture decision on assert*(expected, observed) preference in wiki | 15:17 |
| MootBot | ACTION received: henninge to capture decision on assert*(expected, observed) preference in wiki | 15:17 |
| barry | henninge: thanks! | 15:17 |
| henninge | np | 15:17 |
| barry | [TOPIC] * Driving maintainable Javascript code (intellectronica) | 15:17 |
| MootBot | New Topic: * Driving maintainable Javascript code (intellectronica) | 15:17 |
| barry | * Modularization and unit testing are strongly encouraged | 15:17 |
| barry | * Refactoring code after a UI review is often a good idea | 15:17 |
| barry | * The upper limit for JS diffs is 1600 lines (because javascript is so verbose) | 15:17 |
| intellectronica | what a stupid title. i should be shot | 15:17 |
| barry | intellectronica: why? because of the oxymoron? :) | 15:17 |
| * bigjools chuckles | 15:18 | |
| barry | intellectronica: the floor is yours | 15:18 |
| intellectronica | in the last ajax swat team meeting, we rockstar and deryck led a discussion about how to produce better (more maintainable, easier to test) javascript code | 15:18 |
| intellectronica | we made several observations: | 15:18 |
| intellectronica | 1. code that is OO and modularized is much easier to work with than code that is very imperative and/or relies on closure too heavily | 15:19 |
| intellectronica | 2. unit tests (aka YUI tests) are a great way to test our code. in many cases much better than integration tests | 15:19 |
| intellectronica | 3. working on UI features it is often easier to first concentrate on completing a working UI than on code quality | 15:20 |
| intellectronica | that's fine, but it means that we should refactor the code immediately after it passes UI review | 15:20 |
| intellectronica | that can happen either before code review, or if not, the reviewer should encourage doing that (either as part of this branch or in a followup branch) | 15:20 |
| intellectronica | finally, since javascript code is so much more verbose, we propose a much higher limit, in order to encourage developers to not skip these important steps | 15:21 |
| flacoste | one of those being writing unit tests | 15:21 |
| intellectronica | we think 1600 lines (double the limit we have for python) is reasonable | 15:21 |
| barry | intellectronica: how can we get more assistance in making our js work correctly, and be more consistent? although everyone i've asked for help has been very helpful, i still often feel like i'm just hacking in the dark until it works | 15:22 |
| flacoste | just unit tests can talk 2/3 of your branch size | 15:22 |
| barry | intellectronica: when you say "javascript unit test" you're not talking about windmill, right? | 15:22 |
| barry | or are you? | 15:22 |
| intellectronica | barry: to some extent, we are all a bit in the dark, discovering how to best go about this. discussions in #rhinos and on the canonical-javascript mailing list are a good way to exchange ideas | 15:23 |
| mars | barry, yuitest, not windmill | 15:23 |
| intellectronica | barry: no. we're talking about in-page unit tests using the yuitest framework | 15:23 |
| barry | intellectronica: fair enough :) | 15:23 |
| intellectronica | you'll be glad to learn that they are much easier to write and execute | 15:23 |
| barry | mars: i don't know anything about yuitest. where can i learn and/or where are good examples in our code? | 15:23 |
| flacoste | lazr-js/src/*/tests | 15:24 |
| barry | intellectronica: that would make me very very happy :) | 15:24 |
| sinzui | where are these unit tests in our tree? | 15:24 |
| intellectronica | barry: see lib/canonical/launchpad/javascript/soyuz/tests for example | 15:24 |
| mars | barry, right now the best examples are in lazr-js itself, but others will be landing examples in launchpad soon | 15:24 |
| flacoste | <...>/javascript/*/tests | 15:24 |
| intellectronica | also all widgets in lazr-js have tests | 15:24 |
| flacoste | currently,only the soyuz module has some | 15:24 |
| flacoste | yep lazr-js/src/*/tests | 15:24 |
| barry | cool, thanks, i will be looking at those for the branch i'm currently working on | 15:24 |
| flacoste | unit tests are really "unit" tests | 15:25 |
| flacoste | no Launchpad | 15:25 |
| flacoste | only DOM and you code | 15:25 |
| flacoste | and it's an self-created DOM | 15:25 |
| mars | barry, btw, the test infrastructure is open for hacking and improvement. Please feel free to stop the pain :) | 15:25 |
| sinzui | So I believe lp_dynamic_dom_updater.js is the only Launchpad test in our tree | 15:25 |
| flacoste | in lauchpad, yes | 15:25 |
| flacoste | lazr-js has tons of them | 15:25 |
| intellectronica | so you still need to do some integration testing, but the advantage is that they encourage you to do a good job on modularizing your code | 15:25 |
| barry | mars: i will as soon as i can localize it. right now, it's mostly a full-body numbing throb. :) | 15:26 |
| barry | i think the other problem is that anything touching js just takes WAY more time to develop. i don't think it's entirely the fault of not being as familiar with js. it's a function of the ui 90/10 rule and the fact that yui documentation is lousy | 15:27 |
| * barry knows he's just ranting | 15:27 | |
| intellectronica | barry: that, and the fact that we're all still learning. i bet in a couple of years we'll all be js/yui wizards. it takes time to build competency | 15:28 |
| mars | barry, thankfully we have started to work on that. intellectronica's process improvements are an important step towards speeding things up | 15:28 |
| barry | intellectronica: true. though, we need to keep that in mind when estimating story points and such | 15:28 |
| sinzui | intellectronica: so your saying in a couple of year javascript will require less keystrokes to code? | 15:29 |
| barry | mars: yes, and they are greatly appreciated. our velocity will certainly improve over time | 15:29 |
| mars | sinzui, yes, actually | 15:29 |
| * beuno yells from the back "FASTER! FASTER!" | 15:29 | |
| intellectronica | sinzui: i'm sure in a couple of years you will have written enough gedit plugins to automate most of the crud :) | 15:29 |
| sinzui | I guess the soyuz team won't notice since their class names exceed the line limit | 15:29 |
| * barry mumbles "dabbrev" | 15:30 | |
| * sinzui pines for Javascript 1.7/ECMA ?? | 15:30 | |
| bigjools | at least we have tests! | 15:30 |
| mars | sinzui, you want ECMA 3.1 :) | 15:30 |
| intellectronica | i think we digress. maybe we should start a js coder support group for ranting... | 15:30 |
| intellectronica | is everyone cool with the increase in diff limit (and understands why it's necessary)? | 15:30 |
| barry | intellectronica: yes :) | 15:30 |
| sinzui | I think YUI looks to Java for inspirtation where are Javascript 1.7 looks to Python | 15:31 |
| mars | sinzui, not the cloaked OO pining of 4.X ;) | 15:31 |
| barry | intellectronica: it does make it more difficult to review, but it does make sense. | 15:31 |
| intellectronica | barry: well, you don't really need to review the block delimiters and the uber-verbose documentation | 15:31 |
| mars | intellectronica, +1 | 15:32 |
| barry | intellectronica: true | 15:32 |
| barry | intellectronica: i'm certainly up for an experiment here. if it's too painful we can address it again | 15:32 |
| intellectronica | i think i'm done, unless anyone has anything to add | 15:33 |
| intellectronica | and no, "javascript sucks" isn't a valid item. we already know that :-/ | 15:33 |
| barry | intellectronica: thanks. can you send a message to launchpad@ about the length limit? | 15:33 |
| mars | :P | 15:33 |
| intellectronica | barry: will do | 15:33 |
| barry | [ACTION] intellectronica to email launchpad@ about js branch length limit increase | 15:34 |
| MootBot | ACTION received: intellectronica to email launchpad@ about js branch length limit increase | 15:34 |
| sinzui | How are we increasing our JS reviewers? | 15:34 |
| intellectronica | sinzui: i think by now pretty much everyone on the team does js reviews | 15:34 |
| mars | sinzui, formally? | 15:34 |
| bigjools | which team? | 15:34 |
| intellectronica | bigjools: reviewers team (which is almost the same as the developers team) | 15:35 |
| bigjools | intellectronica: I don't review JS then | 15:35 |
| mars | sinzui, because js reviews are open to all, we leave it up to the reviewer's discretion | 15:35 |
| sinzui | mars: I know a lot about javascript, but I do not consider myself a review because I do not know much about YUI, YUI unit tests, and windmill | 15:35 |
| barry | right. we're asking all reviewers to do js reviews, but ask the swat team for help when needed | 15:35 |
| intellectronica | bigjools: well, time to start, then :) | 15:35 |
| bigjools | intellectronica: I need to write some js myself first :) | 15:35 |
| salgado | same with me | 15:35 |
| bac` | me2 | 15:36 |
| intellectronica | bigjools: yes, i guess that's a prerequisite | 15:36 |
| barry | one problem with this though is that there's little consistency in our js style | 15:36 |
| mars | sinzui, right. Depends on the review. If it is a one-line logic bug, then you don't need a JS mentor call | 15:36 |
| barry | for example, every branch i've written has had different recommendations during js review | 15:36 |
| intellectronica | barry: anything in particular you've noticed? | 15:36 |
| mars | sinzui, but if you desire a second opinion, then give someone on the AJAX team a shout | 15:37 |
| barry | intellectronica: little things mostly, like where to stash objects, anim-reversing | 15:37 |
| barry | intellectronica: i think of it more as refinement rather than conflicts | 15:37 |
| flacoste | yeah | 15:37 |
| flacoste | that pattern are not clear yet | 15:37 |
| barry | mars: can you remind us who is on the "ajax team"? | 15:38 |
| mars | anim-reversing is about learning, and weak docs (my fault) | 15:38 |
| flacoste | so i think it's normal to get divergent opinion on these aspects | 15:38 |
| barry | mars: no, i think flacoste has it right. we're learning as we go, so consistency suffers for now. we're just building up tech debt we know we'll have to pay off later | 15:38 |
| * barry sees no other way around that | 15:38 | |
| flacoste | barry: EdwinGrubbs, mars, intellectronica, jtv, flacoste, rockstar | 15:38 |
| flacoste | barry: and noodles | 15:39 |
| * mars can't type today | 15:39 | |
| flacoste | and danilos - by virtue of having attended the Berlin sprint | 15:39 |
| barry | flacoste: thanks. we should capture that on a wiki page, if it isn't already | 15:39 |
| danilos | barry: I think it is | 15:39 |
| mars | barry, it is | 15:39 |
| barry | cool | 15:39 |
| barry | thanks | 15:39 |
| intellectronica | barry: deryck too knows a lot about js and yui and can help, b.t.w | 15:39 |
| mars | barry, just check the 'skills' column on the current reviewers page | 15:40 |
| danilos | barry: https://dev.launchpad.net/ReviewerSchedule | 15:40 |
| mars | s/skills/specialities/ | 15:40 |
| barry | as i said, everytime i've asked someone for some js help, y'all have been very nice and very helpful. thanks! | 15:40 |
| barry | we have 5 minutes left. is there anything else to talk about today? | 15:41 |
| flacoste | yes | 15:41 |
| flacoste | i have | 15:41 |
| flacoste | i'd like to get an update on the JS testing experiment | 15:41 |
| flacoste | anyone tried it out in the last week? | 15:41 |
| barry | nope | 15:42 |
| mars | no, no JS landings :( | 15:42 |
| flacoste | really? | 15:42 |
| flacoste | ok | 15:42 |
| intellectronica | a better question is: anyone been through review with a js branch which hasn't gone through testing? | 15:43 |
| flacoste | yes, that's the proper way to phrase the question? | 15:43 |
| flacoste | ! | 15:43 |
| barry | no, but i have a js branch going into review hopefully today | 15:43 |
| flacoste | aha! | 15:43 |
| barry | i guess i can be a guinea pig :) | 15:43 |
| flacoste | what about the timeline branches that Edwin landed last week? | 15:44 |
| mars | flacoste, the easiest way to push back on this may be to have reviewer's ask "Has it been tested on all browsers?" | 15:45 |
| barry | guess not. we're outta time, so shall we call it a day? | 15:46 |
| flacoste | sure | 15:46 |
| barry | flacoste: let's ask again next week! | 15:46 |
| barry | #endmeeting | 15:46 |
| MootBot | Meeting finished at 09:46. | 15:46 |
| barry | thanks everyone | 15:46 |
| intellectronica | thanks barry | 15:46 |
| adeuring | thanks barry | 15:46 |
| gmb | Ta barry. | 15:46 |
| === salgado is now known as salgado-afk | ||
| === Edwin is now known as Guest37223 | ||
| jml | lalalala | 23:29 |
| mwhudson | hi | 23:29 |
| thumper | hi ho | 23:30 |
| barry | #startmeeting | 23:30 |
| MootBot | Meeting started at 17:30. The chair is barry. | 23:30 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 23:30 |
| barry | jml, mwhudson, thumper hi | 23:30 |
| jml | hi | 23:30 |
| thumper | hi | 23:31 |
| mwhudson | hello | 23:31 |
| barry | so, do you guys have anything or would you like me to start by reviewing the summary from ameu? | 23:31 |
| thumper | summary is good | 23:31 |
| mwhudson | summarizing is good | 23:31 |
| barry | [TOPIC] summary from ameu | 23:32 |
| MootBot | New Topic: summary from ameu | 23:32 |
| barry | henninge brought up a question about the order of parameters in unittest assert*() methods | 23:32 |
| barry | we agreed that we "prefer" but won't "enforce" the order: (expected, observed) | 23:32 |
| jml | +1 | 23:32 |
| thumper | +1 | 23:32 |
| barry | cool | 23:33 |
| jml | that's what bzrlib does, and I think it's drifted into a lot of lp.code(hosting)? | 23:33 |
| mwhudson | +1 | 23:33 |
| barry | yeah, consensus seemed to be behind this. where there was some disagreement was on forcing people to do that order, so we compromised :) | 23:33 |
| thumper | I'd probably enforce it | 23:34 |
| barry | next, intellectronica outlined some of the things that the ajax swat team's been discussing about js branches | 23:34 |
| barry | thumper: i would too, but there was no consensus, so "strongly prefer" seemed good enough | 23:34 |
| thumper | barry: strongly prefer but individual reviewers may enforce L) | 23:35 |
| barry | :) | 23:35 |
| barry | more on this, or move on? | 23:35 |
| thumper | move on | 23:35 |
| jml | wait | 23:35 |
| jml | are there any actual _points_ from the js branches? | 23:35 |
| jml | or was it just a discussion? | 23:36 |
| barry | jml: yes. if we're moving on, i'll cut&paste intellectronica's points :) | 23:36 |
| mwhudson | go go | 23:36 |
| barry | code that is OO and modularized is much easier to work with than code that is very imperative and/or relies on closure too heavily | 23:36 |
| barry | unit tests (aka YUI tests) are a great way to test our code. in many cases much better than integration tests | 23:37 |
| barry | working on UI features it is often easier to first concentrate on completing a working UI than on code quality. that's fine, but it means that we should refactor the code immediately after it passes UI review. that can happen either before code review, or if not, the reviewer should encourage doing that (either as part of this branch or in a followup branch). | 23:37 |
| barry | finally, since javascript code is so much more verbose, we propose a much higher limit, in order to encourage developers to not skip these important steps. 1600 lines | 23:37 |
| barry | look in .../javascript/*/tests for unittest examples; only soyuz is in our tree atm. or look in lazr-js. | 23:37 |
| barry | EOT | 23:37 |
| jml | I would add "largely functional" to "OO and modularized" | 23:38 |
| thumper | question | 23:38 |
| jml | but that's just me. | 23:38 |
| thumper | where is lp.code javascript supposed to go? | 23:38 |
| barry | thumper: i don't know. this morning was the first i heard of that stuff | 23:38 |
| barry | the existing stuff is in l/c/l/javascript/* | 23:39 |
| barry | so... old tree | 23:39 |
| thumper | hmm.. | 23:39 |
| thumper | who is going to move this? | 23:39 |
| barry | but i know very little about it (first looked at it about 10 minutes ago) | 23:39 |
| barry | thumper: another good question. i don't even know how to /run/ it | 23:39 |
| mwhudson | it seems we have a meeting of the js-resistant! | 23:40 |
| thumper | true | 23:40 |
| barry | maybe when i send the minutes of the meetings, we can start a discussion of these on the ml | 23:41 |
| barry | i really can't give you much more than what i just pasted ;) | 23:41 |
| jml | :) | 23:41 |
| barry | thumper has a topic when we're ready to move on | 23:41 |
| thumper | It'd be nice if we could have the javascript for the apps in the right part of the tree | 23:41 |
| jml | I'm ready to move on :) | 23:41 |
| mwhudson | move on | 23:42 |
| thumper | my topic | 23:42 |
| barry | thumper: it's all yours | 23:42 |
| thumper | this week the code team removed all lp.code imports from canonical.launchpad.database.__init__.py and canonical.launchpad.interfaces.__init__.py | 23:42 |
| thumper | the team leads agreed to get this done for their projects | 23:42 |
| thumper | we should make sure there are no imports from these modules in reviews | 23:43 |
| thumper | to make their job easier | 23:43 |
| thumper | I personally changed many IPerson and IProduct imports to lp.registry | 23:43 |
| barry | thumper: awesome. new is better :) | 23:44 |
| jml | me too, actually. | 23:44 |
| thumper | that's it | 23:44 |
| mwhudson | +1 | 23:44 |
| jml | +1 | 23:44 |
| barry | +1 | 23:44 |
| barry | thanks thumper | 23:44 |
| thumper | sold! | 23:44 |
| barry | anything else guys? | 23:44 |
| jml | barry, one more thing | 23:44 |
| barry | jml: you're up | 23:45 |
| jml | barry, I'd be kind of interested in knowing how many reviews people do per day. | 23:45 |
| thumper | jml: we have real metrics | 23:45 |
| jml | barry, because I'm thinking that the small size of asiapac lends itself (perversely) to everyone doing more reviews. | 23:45 |
| thumper | jml: in LP | 23:45 |
| jml | thumper, extract them for me :) | 23:46 |
| barry | yes, that would be cool to know! thumper can you get a losa to run a report? | 23:46 |
| thumper | jml: some LP lib magic should be able to do this | 23:46 |
| thumper | barry: I don't need no stinking losas :) | 23:46 |
| jml | barry, very low priority, I guess. I've just been noticing how often I get interrupted, and wonder if Almighty Process can make that happen less :) | 23:46 |
| barry | or that :) | 23:46 |
| * mthaddon stares at thumper | 23:46 | |
| thumper | mthaddon: ... to run a script for me :) | 23:47 |
| jml | that's it. | 23:47 |
| * thumper can do it himself :) | 23:47 | |
| barry | jml: how does ocr work for you guys? do you do it, or do you work on demand? | 23:47 |
| * mthaddon is actually happy (apart from the stinking part) | 23:47 | |
| jml | barry, we do work on demand | 23:47 |
| jml | AND | 23:47 |
| jml | when we are ocrs, we do a lot of reviews | 23:47 |
| thumper | barry: I don't do OCR, but do quite a few on demand | 23:47 |
| jml | often more from the americas on OCR days. | 23:48 |
| barry | jml: when you ocr do you just pop branches off activereviews or wait for devs to come to you. and if the latter, do you get many non-asiapac branches? | 23:48 |
| mwhudson | i don't really do ocr, to be honest | 23:48 |
| jml | barry, I pop off to a limit of 3. :) | 23:48 |
| jml | barry, or if they are small. | 23:48 |
| barry | mwhudson, thumper gotcha | 23:48 |
| mwhudson | generally whenever anyone says "can you do a review" i do it | 23:49 |
| jml | barry, I do get people who come to me, but it varies from week to week. | 23:49 |
| mwhudson | (ocr day or not) | 23:49 |
| barry | jml: makes sense. actually, interestingly enough, your BOD overlaps with our EOD, so you could do some on demand america reviews occasionally | 23:49 |
| jml | barry, I sometimes do. | 23:49 |
| barry | that's great, actually | 23:49 |
| jml | (also, it's different in summer) | 23:50 |
| barry | well, thumper if you run that script, do let us know. it would be interesting | 23:50 |
| barry | jml: who's summer? <wink> | 23:50 |
| thumper | kk | 23:50 |
| barry | anything else guys? | 23:50 |
| jml | that's it from me. | 23:51 |
| * thumper is done | 23:51 | |
| mwhudson | all from me | 23:51 |
| mwhudson | thanks barry | 23:51 |
| barry | thanks guys! | 23:51 |
| barry | #endmeeting | 23:51 |
| MootBot | Meeting finished at 17:51. | 23:51 |
| * barry -> dinner | 23:51 | |
| thumper | thanks barry | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!