| === salgado is now known as salgado-afk | ||
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| barry | #startmeeting | 14:00 |
|---|---|---|
| MootBot | Meeting started at 09:00. The chair is barry. | 14:00 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 14:00 |
| barry | hello everyone and welcome to this week's ameu reviewer's meeting. who's here today? | 14:00 |
| gmb | me | 14:00 |
| gary_poster | me | 14:00 |
| sinzui | ma | 14:00 |
| sinzui | ma | 14:00 |
| mars | me | 14:00 |
| gary_poster | :-) | 14:00 |
| sinzui | where is my e | 14:00 |
| sinzui | me | 14:00 |
| noodles775 | moi | 14:00 |
| allenap | me | 14:00 |
| mars | noodles775, you need to step one country to the right | 14:01 |
| noodles775 | mars: ah, wrong one... :/ | 14:01 |
| barry | bac: ping | 14:01 |
| bac | argh | 14:01 |
| bac | me | 14:01 |
| barry | bigjools, cprov, danilo_ ping | 14:01 |
| barry | intellectronica: ping | 14:02 |
| intellectronica | me | 14:02 |
| barry | rockstar: ping | 14:02 |
| barry | salgado: ping | 14:02 |
| salgado | me! | 14:02 |
| barry | today's a light day, so let's start off with the fun stuff | 14:02 |
| cprov | me | 14:02 |
| flacoste | me | 14:02 |
| barry | [TOPIC] agenda | 14:03 |
| MootBot | New Topic: agenda | 14:03 |
| barry | * Roll call | 14:03 |
| barry | * Peanut gallery (anything not on the agenda) | 14:03 |
| barry | * Mentoring update | 14:03 |
| barry | * Action items | 14:03 |
| barry | [TOPIC] * Peanut gallery (anything not on the agenda) | 14:03 |
| MootBot | New Topic: * Peanut gallery (anything not on the agenda) | 14:03 |
| danilo_ | me | 14:03 |
| === danilo_ is now known as danilos | ||
| barry | does anybody have any reviewy type stuff they want to bring up that's not on the agenda? | 14:03 |
| sinzui | me | 14:03 |
| barry | sinzui: the floor is yours | 14:04 |
| sinzui | bac discovered that there were a few places in our templates where we were making insane links. | 14:04 |
| sinzui | Bad | 14:04 |
| sinzui | <a tal:content="structure person/fmt:link" /> | 14:04 |
| sinzui | becomes | 14:04 |
| sinzui | <a><a href="...">text</a></a> | 14:04 |
| sinzui | Good | 14:04 |
| sinzui | <a tal:replace="structure person/fmt:link" /> | 14:04 |
| sinzui | becomes | 14:04 |
| sinzui | <a href="...">text</a> | 14:04 |
| sinzui | When reviewing tal, please verify anything that uses `structure` works in the containing elements. | 14:04 |
| barry | that's wacky | 14:05 |
| mars | sinzui, would html-tidy catch that? | 14:05 |
| sinzui | mars yes | 14:05 |
| gary_poster | after rendering, yes, but not before rendering (in our templates) | 14:06 |
| mars | yep, of course | 14:06 |
| sinzui | mars: any HTML validator can see that is not permitted | 14:06 |
| mars | not that we have any good or automated way to run said validator... | 14:06 |
| bac | i have a branch that attempt to ferret them all out. even our 'featured projects' listing on the front page had the problem. | 14:06 |
| flacoste | good catch sinzui and bac | 14:07 |
| barry | bac: by visual inspection or through some tool? | 14:08 |
| bac | well, when sinzui says "bac discovered" he means "bac repeated the problem flagrantly" such that sinzui discovered it. | 14:08 |
| mars | what if we made the doctest runner do HTML validation on page open? | 14:08 |
| gary_poster | :-) | 14:08 |
| bac | barry: just grep and examing them all | 14:08 |
| sinzui | barry 'content="structure .*link' catches most of them | 14:09 |
| barry | mars: interesting idea, but i'm affraid it would slow things down alot | 14:09 |
| sinzui | of course we can write tal on multiple lines | 14:09 |
| gary_poster | [blue sky] we could have a nightly buildbot for what mars suggests | 14:10 |
| mars | barry, we could bind it to 'make check' | 14:10 |
| sinzui | mars: too slow, as is updating find_main_content | 14:10 |
| mars | barry, since we'll have to do so for windmill tests anyway | 14:10 |
| mars | which are even slower | 14:10 |
| sinzui | Our link checker could take on the extra work. or... | 14:11 |
| barry | mars: yeah | 14:11 |
| mars | sinzui, yes, that's another good hook point | 14:11 |
| sinzui | >>> view = create_initialized_view(person, '+index', principle=person) | 14:11 |
| sinzui | >>> is_valid_html(view.render()) | 14:11 |
| sinzui | True | 14:11 |
| mars | sinzui, but the link-checker isn't under developer control | 14:11 |
| mars | is it? | 14:11 |
| bac | gary_poster: +1 -- a periodic scan should be enough to trap infrequent offenders | 14:12 |
| mars | at least I could do ./test.py --validate-markup or something | 14:12 |
| barry | sinzui: i think i like that approach best. cons: it's up to the dev to add the check, pros: you can decide to check only when you think it's necessary | 14:13 |
| barry | does someone want to take this on as an action item? | 14:14 |
| flacoste | i think the buldbot story is better | 14:14 |
| flacoste | here | 14:14 |
| bac | cons: it slows down our tests | 14:14 |
| flacoste | doesn't slow down the test suite | 14:14 |
| flacoste | it's not a big problem | 14:14 |
| flacoste | i mean this has been broken for long and didn't cause any problems | 14:15 |
| flacoste | invalid markup is ugly, but not a show-stoppers | 14:15 |
| flacoste | thanks to the way browsers are implemented | 14:15 |
| barry | we don't need to solve it here, but i'd like someone to own it and offer some options | 14:15 |
| mars | flacoste, does our build process have provisions or the concept of warnings? | 14:15 |
| flacoste | it sounds like a foundations issue | 14:15 |
| flacoste | but it would be a very low priority to me | 14:15 |
| flacoste | so no point putting it down as an actino | 14:16 |
| barry | flacoste: okay | 14:16 |
| barry | thanks. any other topics not on the agenda? | 14:16 |
| barry | [TOPIC] mentoring update | 14:18 |
| MootBot | New Topic: mentoring update | 14:18 |
| barry | any mentor or mentat updates today? | 14:18 |
| rockstar | me | 14:18 |
| === ursula_ is now known as ghost | ||
| === ghost is now known as Ursinha | ||
| barry | rockstar: you don't have a mentoring update, right? | 14:19 |
| rockstar | No, I'm just screwed by DST again. | 14:19 |
| barry | [TOPIC] action items | 14:19 |
| MootBot | New Topic: action items | 14:19 |
| barry | * gary to add `getStore()` as an alias for `_get_store()` | 14:20 |
| barry | gary_poster: ^^ | 14:20 |
| flacoste | barry: i still suck at mine, but do keep it open, i plan to suck less | 14:21 |
| flacoste | see, i'm pro-active :-) | 14:21 |
| barry | flacoste: that's a start! :) | 14:21 |
| barry | * gary will check to see if there's a bug open for adding a hook to `bzr send`, and submit one if there isn't | 14:21 |
| barry | gary_poster: ^^ | 14:21 |
| barry | * bigjools to take crack at helper functions for backpatching schemas to avoid circular imports | 14:22 |
| barry | * barry to add `field_id` to coding guideline | 14:22 |
| barry | * barry to update guidelines to never call `_foo()` methods from outside a class | 14:22 |
| barry | * barry to add `pretty()` functions to reviewers docs | 14:22 |
| barry | i actually do NOT suck today! i did all three of these :) | 14:22 |
| bigjools | goddamn it and the time changes | 14:23 |
| * bigjools sucks at helper functions AND timekeeping | 14:23 | |
| barry | no worries | 14:24 |
| barry | anyway, that's all i have today. anything else going on? | 14:24 |
| barry | 5 | 14:24 |
| rockstar | I have something | 14:25 |
| barry | rockstar: go ahead | 14:25 |
| rockstar | It looks like sinzui already quoted to code above... | 14:25 |
| rockstar | I was reviewing a branch of sinzui's where he was using a doctest to test a view's API. | 14:25 |
| rockstar | Now, I understand that our team has an unusual fetish for doctests, but I think that if we're doing something where we can use unittests, we should use them. | 14:26 |
| flacoste | hmm | 14:27 |
| * mars sees the testing debate from the ML creeping in... | 14:27 | |
| flacoste | that's a controversial topic | 14:27 |
| flacoste | rockstar: what are the arguments? | 14:27 |
| barry | i might make the counter argument :) | 14:27 |
| flacoste | yeah | 14:28 |
| sinzui | Shall we wall read the 2008 June, July debate. | 14:28 |
| rockstar | doctests are good for telling a user story, but if we're just testing the methods of a view, why not use what unittests for what they were made for? | 14:28 |
| sinzui | I believe thumper wanted a paintball battle to decide the matter | 14:28 |
| flacoste | lol | 14:28 |
| barry | sinzui: M-x paintball | 14:28 |
| flacoste | rockstar: we have usually refrained from enforcing a policy there | 14:28 |
| flacoste | let developers choose which technology they prefer here | 14:28 |
| barry | flacoste: right. i think that still works as a policy | 14:29 |
| rockstar | flacoste, and I think that leads to a mess. | 14:29 |
| intellectronica | i think that unless we lose coverage because of that, we should allow teams to choose what format they prefer | 14:29 |
| intellectronica | for individuals to choose is already a bit extreme | 14:29 |
| rockstar | If I change a view, I can't easily discern where the hell the test is that I need to edit. | 14:29 |
| rockstar | Is it it doc? Is it in browser/tests? | 14:30 |
| sinzui | I'm agnostic on the issue. Since all the registry view tests are in doctest, I wan to add to them instead of storing two kinds of tests in two areas | 14:30 |
| barry | rockstar: conversely without a doctest if i'm trying to learn how a view works, it's much more difficult to discern that from its docstrings and unittest | 14:30 |
| rockstar | barry, why can't you look at the unittest? You'll be doing essentially the same thing. | 14:30 |
| sinzui | rockstar: doctests do not normally explain WHY the view does soemthing | 14:31 |
| barry | rockstar: unittests lack the narrative that sets the context of the api | 14:31 |
| mars | right | 14:31 |
| flacoste | rockstar finding the tests is different than the format | 14:31 |
| bigjools | unittests are superior ways of testing, I'm pretty tired of having a doctest halt when one of its tests fails | 14:31 |
| barry | the "ties it all together" bits | 14:31 |
| flacoste | it should be browser/tests | 14:31 |
| flacoste | whatever the format | 14:31 |
| flacoste | unless it's an API description | 14:32 |
| flacoste | and even then | 14:32 |
| flacoste | i'm starting the Launchpad-tree-apocalypse today | 14:32 |
| bigjools | /o\ | 14:32 |
| * sinzui hand flacoste the fuel and a torch | 14:32 | |
| rockstar | I think mixing and matching tests is going to bite us one of these days. | 14:32 |
| flacoste | that will makes things clearer for finding stuff and tests | 14:32 |
| flacoste | for answers | 14:32 |
| flacoste | and registry will they their apocalyspe next week | 14:32 |
| flacoste | gary_poster, zope has a lot of experience in that area | 14:33 |
| * sinzui is bringing marshmallows. | 14:33 | |
| flacoste | anything to share here? | 14:33 |
| rockstar | Anytime you say "In this folder, you might find unittests or doctests" it makes me think that one or the other is being misused. | 14:33 |
| gary_poster_ | flacoste: sorry, having connectivity issues and buildbot issues simultaneously | 14:34 |
| barry | rockstar: personally, i'd like to see doctests in a 'docs' directory | 14:34 |
| barry | sanitizing our testing infrastructure is definitely on the list of monsters to pitchfork | 14:34 |
| rockstar | barry, personally, I'd like to see the doctests use testbrowser to tell a user story, or unittests to test a unit. | 14:35 |
| flacoste | barry: well, if it's docs, it belongs in a docs directory | 14:35 |
| flacoste | but many doctest are not docs | 14:36 |
| barry | rockstar: what about documentation for internal components and subsystems? | 14:36 |
| intellectronica | rockstar: do you never use the doctests to learn about functionality? i often do, and i think that if we don't have doctests, we won't have documentation at all | 14:36 |
| barry | flacoste: yes, that's a problem :) | 14:36 |
| flacoste | docs is about API description | 14:36 |
| flacoste | well, it's not | 14:36 |
| rockstar | flacoste, isn't that the benefit of doctests? They are docs AND they are tests? | 14:36 |
| sinzui | rockstar: model/components need to be doctests because their are the develop documentation. | 14:36 |
| flacoste | well | 14:36 |
| flacoste | i don't think a view is an API | 14:36 |
| flacoste | interesting to document | 14:36 |
| flacoste | most of them aren't | 14:36 |
| flacoste | a few might be | 14:36 |
| flacoste | but they are the exception | 14:36 |
| rockstar | flacoste, a view has an API. | 14:37 |
| flacoste | well, not really | 14:37 |
| flacoste | the only API is __call__ | 14:37 |
| flacoste | which renders the view | 14:37 |
| flacoste | that's it | 14:37 |
| mars | flacoste, and the properties | 14:37 |
| flacoste | no | 14:37 |
| rockstar | intellectronica, I look at unittests all the time to learn about functionality. | 14:37 |
| flacoste | well, maybe | 14:37 |
| barry | rockstar: i'm thinking about the multistep view i just refactored. i think documentation for it is essential so that others can understand how to reuse it. | 14:37 |
| flacoste | i would argue that the properties are internal implementation details | 14:38 |
| gary_poster_ | My thoughts on this: (1) doctest for unittest purpose is emacs vs. vi IMO/IME. I think that using doctest for unittest purposes works well. Other people disagree. I tend to find that people think about these things differently. I can acknowledge the points people make (like bigjools, IRT doctests failing at the beginning) but I prefer doctests. | 14:38 |
| gary_poster_ | (2) I would much prefer it if our tests were closer to the pertinent code | 14:38 |
| flacoste | i agree with both points | 14:38 |
| gary_poster_ | that appears to be (part of) the topic I lost while I was dealing with various issues | 14:38 |
| rockstar | gary_poster, +1 on (2) | 14:38 |
| flacoste | and my apocalyspe branch will improve 2 | 14:38 |
| mars | flacoste, rockstar, maybe reorganize the tree, and wait and see? | 14:39 |
| * flacoste can't spell apocalypse | 14:39 | |
| mars | you can run more experiments, say with the view tests, after | 14:39 |
| barry | flacoste: maybe that should be apocalisp? | 14:39 |
| flacoste | lol | 14:39 |
| gary_poster_ | :-) | 14:39 |
| mars | a smaller sandbox will make experimenting on a per-team basis easier | 14:39 |
| rockstar | mars, I don't think that's the answer. | 14:39 |
| sinzui | mars: I think teams have already made their decision | 14:39 |
| bigjools | I see doctests primarily as documentation that carry examples, it's easy to abuse them to be full-blown tests | 14:40 |
| barry | mars: yes, and it will make things much more discoverable and comprehensible | 14:40 |
| rockstar | The per-team thing just makes things messier. That's why it's good to have cross-team-reviews | 14:40 |
| sinzui | I think that teams that will not release their code are using unittests. | 14:40 |
| rockstar | sinzui, :( | 14:40 |
| === gary_poster_ is now known as gary_poster | ||
| intellectronica | rockstar: well, not really per-team. what i meant, at least, is that the division should be thematic, not personal | 14:41 |
| barry | i think it's just too controversial to mandate at this point. i agree with gary that it feels like mandating vi or emacs | 14:41 |
| rockstar | intellectronica, depending on the "theme" I agree with you. | 14:41 |
| bac | perhaps emacs users could use doctests... | 14:41 |
| gary_poster | :-) | 14:41 |
| barry | i personally think that both doctests and unittests have their place, both have positives... and negatives | 14:42 |
| rockstar | barry, I don't see why. I think they serve two different purposes. It's like mandating motor oil v. beer. | 14:42 |
| mars | rockstar, yuck | 14:42 |
| gary_poster | rockstar: right, but...other people disagree with you :-) | 14:42 |
| gary_poster | that's the point | 14:42 |
| barry | rockstar: is that: unittests are greasy and icky but good for your motor, while doctests are fun, festive and easy to consume? | 14:42 |
| sinzui | I think the crucial point that rockstar is making is that to test a class of problems, we should use one kind of test so that we know where and how to test it. | 14:42 |
| cprov | barry: lol | 14:43 |
| rockstar | sinzui, yes! Thank you! | 14:43 |
| sinzui | My concern is that if I switch to unittest, I then have lots of tests in doctest | 14:43 |
| sinzui | insert old in the above sentece somewhere | 14:43 |
| bigjools | do we agree that doctests are not tests, they're documentation? | 14:43 |
| gary_poster | no | 14:44 |
| rockstar | bigjools, no | 14:44 |
| gmb | not as we use them atm. | 14:44 |
| barry | no | 14:44 |
| cprov | no | 14:44 |
| flacoste | doctests are tests | 14:44 |
| bigjools | because I remember a mail thread from 2 years ago | 14:44 |
| barry | it's not either or. doctests are documentation /first/ but they are tests too | 14:44 |
| rockstar | I think doctests are great at telling a story about a user experience, and asserting that the story actually works with code. | 14:44 |
| bigjools | that said they are not tests | 14:44 |
| flacoste | barry: i would even argue that some doctests are not even doc first and that's fine too | 14:44 |
| bigjools | and that writing words like "should" are not acceptable | 14:44 |
| barry | s/user experience/developer experience/ | 14:44 |
| intellectronica | doctests CAN be tests. unit tests CAN'T be documentation | 14:45 |
| * noodles775 suddenly realizes why the email discussion the other day stopped so quickly... | 14:45 | |
| bigjools | barry: right, testable documentation | 14:45 |
| barry | intellectronica: i agree with that statement (flacoste's too) | 14:45 |
| rockstar | barry, why would there need to be a story about developer experience. "The developer can instantiate this class, and then you have these functions..." | 14:45 |
| gmb | The problem comes with - to pick an example at random - things like doc/externalbugtracker-comment-pushing.txt | 14:45 |
| gmb | In which we create a load of mock objects in the doctest in order to be able to run the tests. | 14:46 |
| gmb | That seems unit-testy. | 14:46 |
| sinzui | bigjools: s/should/can|expected|required/ | 14:46 |
| barry | rockstar: ever tried to understand how a class is supposed to be used by pydoctor api reference? it sucks. unittests are the same | 14:46 |
| bigjools | sinzui: "will" | 14:46 |
| intellectronica | gmb: actually, i think that's a good example to the contrary. as someone who doesn't know that system as good as you, i really benefit from having documentation whenever i need to work on it | 14:46 |
| barry | rockstar: otoh, once you understand how a class is to be used, api reference is great | 14:46 |
| sinzui | bigjools: +1 | 14:47 |
| bigjools | doctests are statements of intent | 14:47 |
| rockstar | I would like to withdraw my request to use unittest to test units. It seems that it's not getting anywhere. | 14:47 |
| sinzui | The meeting is getting close the the end. I just read unit-testies | 14:47 |
| gmb | intellectronica: Hmm, okay. Then I'd argue that the mock objects should at least be factored out into ftests/somethingorother for cleanliness. | 14:47 |
| bigjools | sinzui: lol | 14:47 |
| barry | sinzui: on that note... | 14:47 |
| gary_poster | fwiw, footnotes can help with this | 14:47 |
| intellectronica | rockstar: gracious of you. as a reviewer, you still have the option of asking that something be unit tested if you think it makes more sense | 14:48 |
| barry | i propose we close the meeting for today and schedule a mud wrasslin' contest to settle this once and for all | 14:48 |
| barry | at all hands | 14:48 |
| gary_poster | and fwiw, this example has been pointed to in the past by others as a reasonable unit test/doc test combo: http://svn.zope.org/zc.queue/trunk/src/zc/queue/queue.txt?view=auto | 14:48 |
| rockstar | intellectronica, as a reviewer, I don't think that makes a lot of sense if there isn't really a standard. :/ | 14:48 |
| gary_poster | (I wrote it, so this the importance of "by others") | 14:48 |
| gary_poster | I will propose footnotes at another mtg :-) | 14:49 |
| barry | okay, thanks everyone for a spirited debate! | 14:49 |
| barry | apologies for going over. i'm sure we'll continue this at another time | 14:50 |
| barry | #endmeeting | 14:50 |
| MootBot | Meeting finished at 09:50. | 14:50 |
| intellectronica | thanks barry | 14:50 |
| bigjools | barry: https://launchpad.canonical.com/TestsStyleGuide#Style%20to%20Avoid | 14:50 |
| * mars packs the pitchfork away for another day | 14:50 | |
| bigjools | "A very important consideration is that documentation tests are really documentation that happens to be testable." | 14:50 |
| barry | bigjools: couldn't agree more! | 14:50 |
| bigjools | so why did everyone disagree with me? :) | 14:51 |
| * barry -> #launchpad-code | 14:51 | |
| gmb | bigjools: Because you're you :) | 14:51 |
| bigjools | figures | 14:51 |
| === salgado is now known as salgado-lunch | ||
| === salgado-lunch is now known as salgado | ||
| === salgado is now known as salgado-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!