[14:00] <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:01] <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:02] <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:03] <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] <barry> does anybody have any reviewy type stuff they want to bring up that's not on the agenda?
[14:03] <sinzui> me
[14:04] <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:05] <barry> that's wacky
[14:05] <mars> sinzui, would html-tidy catch that?
[14:05] <sinzui> mars yes
[14:06] <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:07] <flacoste> good catch sinzui and bac
[14:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:18] <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:19] <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:20] <barry>  * gary to add `getStore()` as an alias for `_get_store()`
[14:20] <barry> gary_poster: ^^
[14:21] <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:22] <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:23] <bigjools> goddamn it and the time changes
[14:23]  * bigjools sucks at helper functions AND timekeeping
[14:24] <barry> no worries
[14:24] <barry> anyway, that's all i have today.  anything else going on?
[14:24] <barry> 5
[14:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <gary_poster> I will propose footnotes at another mtg :-)
[14:49] <barry> okay, thanks everyone for a spirited debate!
[14:50] <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:51] <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