[14:59] <gmb> Wheeeeee....
[14:59]  * bigjools stretches and yawns
[15:00]  * intellectronica sneezes
[15:00] <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 reviewers meeting
[15:00] <barry> who's here today?
[15:00] <sinzui> me
[15:00] <intellectronica> me
[15:00] <gary_poster> me
[15:00] <bigjools> me
[15:00] <salgado> me
[15:00] <mars> me
[15:01] <gmb> me
[15:01]  * barry knows that bac sends his apologies
[15:01] <abentley> me
[15:01] <BjornT> me
[15:01] <barry> gary_poster: welcome!  we're going to make you a reviewer one of these days :)
[15:02] <gary_poster> barry: heh, hi :-)
[15:02] <flacoste> me
[15:02] <EdwinGrubbs> me
[15:02] <barry> cprov: ping
[15:02] <cprov> cprov
[15:02] <barry> danilo[home]__: ping
[15:02] <cprov> err, *me*
[15:03] <barry> rockstar: ping
[15:03] <barry> [TOPIC] agenda
[15:03] <MootBot> New Topic:  agenda
[15:03] <barry>  * Roll call
[15:03] <barry>  * mentor needed for mars -- barry
[15:03] <barry>  * Using ReST instead Moin for documentation -- flacoste  [<<Date(2008-09-22T10:17:00-0500)>>]
[15:03] <barry>  * Require testing of JavaScript (indeed, all UI) changes on multiple platforms (gmb).
[15:03] <barry>  * 78 column limit okay in doctest narrative? -- barry
[15:03] <barry>  * If there's time, the old boring script
[15:03] <barry>    * Next meeting
[15:03] <barry>    * Action items
[15:03] <barry>    * Queue status
[15:03] <barry>    * Mentoring update
[15:03] <barry> [TOPIC] mentor needed for mars -- barry
[15:03] <MootBot> New Topic:  mentor needed for mars -- barry
[15:04] <gmb> barry: I'll do that.
[15:04] <barry> gmb: fantastic, thanks
[15:04] <barry> mars: please coordinate with gmb and join him on his on call day
[15:04] <flacoste> gmb: when is your on-call day?
[15:04] <mars> gmb, thanks, I look forward to working with you
[15:04] <gmb> mars: Likewise.
[15:04] <gmb> I'm on call on Thursday, but I can change that if necessary.
[15:04] <gmb> Actually
[15:05] <gmb> We have a glut of reviewers on Thursday
[15:05] <gmb> Me, salgado, EdwinGrubbs...
[15:05] <gmb> So maybe we should pick a different day.
[15:05] <salgado> gmb, I've moved to Friday
[15:05] <gmb> Ah.
[15:05] <gmb> That shows how much attention I was paying
[15:05] <bigjools> salgado is the new sinzui
[15:05] <flacoste> mars: you might want to skip or only do a light day this week
[15:05] <mars> gmb, ok, I'll look at the schedule
[15:05] <barry> bigjools: :)
[15:06] <intellectronica> gmb: i think bac mentioned that he wanted to take a break. maybe you can reaplce him when that happens?
[15:06] <barry> bac_afk: is mentoring rockstar
[15:06] <sinzui> bigjools: less stupid question of Fridays now
[15:06]  * gmb looks at OCR...
[15:06] <gmb> So, maybe Wednesday
[15:07] <barry> monday euro is also open
[15:07] <gmb> Especially with allenap being fatherly at the moment and all.
[15:07] <gmb> Hmm...
[15:07] <gmb> barry: Whatever your preference then. Monday works for me.
[15:08] <barry> it would mean EdwinGrubbs would be the only eu/am reviewer on thursdays
[15:08] <barry> mondays are fairly light usually, so gmb, mars let's keep you on euro thursdays for now
[15:08] <gmb> So really, it makes no difference which day we're on.
[15:08] <gmb> barry: Right, works for me.
[15:08] <mars> ok
[15:09] <barry> thanks! i'll update the relevant pages
[15:09] <gmb> Ok.
[15:09] <barry> [TOPIC]  * Using ReST instead Moin for documentation -- flacoste  [<<Date(2008-09-22T10:17:00-0500)>>]
[15:09] <MootBot> New Topic:   * Using ReST instead Moin for documentation -- flacoste  [<<Date(2008-09-22T10:17:00-0500)>>]
[15:09] <barry> flacoste: the floor is yours
[15:09] <flacoste> ok, so I'd like to suggest we move back to using ReST as our standard doc format
[15:10] <flacoste> especially in regards to doctests
[15:10] <flacoste> the only thing we are using from Moin is the header style
[15:10] <flacoste> and it doesn't give us anything
[15:10] <flacoste> we can't process those files
[15:10] <flacoste> moving to ReST will allow us to use the numerous tools that can process those
[15:10] <sinzui> +1
[15:10] <flacoste> we talked about separating documentation across the tree and linking it into a doc directory
[15:11] <barry> +1
[15:11] <gmb> +1
[15:11] <flacoste> we could process those using Sphinx which is becoming a standard in the python world
[15:11] <mars> +1, I want my syntax highlighting back :)
[15:11] <abentley> +1.
[15:11] <flacoste> any objections?
[15:11] <BjornT> will we switch to ReST in the wiki as well?
[15:11] <flacoste> should we?
[15:11] <barry> can we?
[15:11] <intellectronica> there's an advantage to using the same format for the many different text collections we've got
[15:11] <flacoste> and does Moin supports it?
[15:12] <BjornT> well, i'd hate having to know to different formats for docs
[15:12] <abentley> flacoste: Moin supports it.
[15:12] <barry> +1 then
[15:12] <intellectronica> further more, it might make sense to coordinate this with other canonical projects, like landscape and bazaar
[15:12] <abentley> flacoste: Perhaps not as well as Moin markup, but...
[15:12] <BjornT> what kind of processing do we want, btw? i think that's important to think about, before we decide to switch
[15:12] <BjornT> switching is expensive
[15:12] <flacoste> hmm, it's not
[15:12] <flacoste> JFDI
[15:12] <flacoste> we don't need to convert anything
[15:12] <sinzui> I think formatdoctest.py can switch the headers after a small change to the header rule.
[15:13] <flacoste> we didn't when we settled on Moin heading style
[15:13] <flacoste> and we don't really use Moin
[15:13] <flacoste> only it's heading style
[15:13] <abentley> intellectronica: Bazaar uses ReST everywhere except in the Wiki.  (Where it *sometimes* uses ReST.)
[15:13] <barry> rs=barry for any formatdoctest.py generated pure cleanup branches
[15:14] <sinzui> We can switch during the Epic
[15:14] <intellectronica> abentley: thanks. i guess that supports the idea of moving to rst
[15:14] <flacoste> we have some packages that we intend to distribute on the cheeseshop
[15:14] <flacoste> waddlib, launchpadlib
[15:14] <flacoste> having the doc in ReST will allow the documentation to integrate nicely with the Cheeseshop
[15:15] <flacoste> gary_poster: am I making this up, or did I understand that correclty?
[15:15] <barry> flacoste: can you update https://launchpad.canonical.com/TestsStyleGuide and email the ml?
[15:15] <flacoste> barry: i will
[15:15] <gary_poster> flacoste: :-) yes, the main page for a project is in ReST
[15:15] <mars> flacoste, PyPi likes ReST
[15:15]  * abentley wonders if it would be a good idea to make ReST the default on the new launchpad wiki.
[15:15] <barry> [ACTION] flacoste will update https://launchpad.canonical.com/TestsStyleGuide and email the ml, re: use reST in doctests
[15:15] <MootBot> ACTION received:  flacoste will update https://launchpad.canonical.com/TestsStyleGuide and email the ml, re: use reST in doctests
[15:15] <flacoste> barry: am I doing a wiki policy also
[15:16] <flacoste> i think we can postpone that one
[15:16] <flacoste> just doctests
[15:16] <barry> flacoste: great, thanks
[15:16] <flacoste> another issue is docstrings,
[15:16] <flacoste> we currently use epydoc markup on those
[15:16] <mars> flacoste, isn't epydoc based on ReST?
[15:17] <flacoste> i think it is, but it uses different fields syntax
[15:17] <BjornT> flacoste: are you going to mail the list for discussing this, or to inform about a decision?
[15:17] <mars> that's optional, IIRC.  @foo: is the same as :foo:
[15:17] <barry> mars: correct
[15:17] <abentley> err, I've been using ReST in my docstrings.
[15:17] <flacoste> for doctest, it seems that we nearly have consensus
[15:17] <flacoste> BjornT: ^^^
[15:17] <barry> btw, asiapac is cool with this
[15:18] <flacoste> BjornT: i would ask for discussion regarding the wiki
[15:18] <abentley> ":param foo: frob the thurbleforp", etc.
[15:18] <flacoste> barry: did I understand correctly that action?
[15:18] <BjornT> flacoste: well, i still would like to see a list of use cases. many voted +1 just because we could use tools to process the files. i would like to know a bit more what we want to gain from switching.
[15:18] <barry> flacoste: i'm not sure, what do you think the action says? :)
[15:19] <flacoste> BjornT: build an HTML documentation
[15:19] <BjornT> i don't think this is something that should be decided in a meeting, without having a proper discussion
[15:19] <flacoste> also
[15:19] <flacoste> remember that our Moin use doesn't give us anything
[15:19] <BjornT> flacoste: and you're confident that's impossible using moin?
[15:19] <flacoste> yes, because we aren't using proper moin
[15:19] <flacoste> processing the python example looks like crap
[15:20] <flacoste> gary tried it
[15:20] <BjornT> flacoste: what would it look like? can we maybe make a small change to make it interpret >>> specially?
[15:20] <flacoste> i don't want to hack moin
[15:20] <flacoste> the main argument is that there are standard tools in the python world
[15:20] <flacoste> to do this
[15:21] <flacoste> and now we aren't compatible with anything
[15:21] <BjornT> i'd still like to see some examples of what we want to do (like links to existing documentation, and so on)
[15:21] <flacoste> neither Moin, nor ReST
[15:21] <gary_poster> BjornT: OK one sec
[15:22] <gary_poster> simple ReST page on PyPI
[15:22] <gary_poster> http://pypi.python.org/pypi/zc.async
[15:22] <MootBot> LINK received:  http://pypi.python.org/pypi/zc.async
[15:22] <rockstar> me
[15:22] <gary_poster> ReST docs to html generated by Sphinx
[15:22] <gary_poster> http://packages.python.org/zc.async/1.5.0/
[15:22] <MootBot> LINK received:  http://packages.python.org/zc.async/1.5.0/
[15:22] <BjornT> and i'd like to postpone the decision, since i think a bit more than a few minutes is needed to evaluate this
[15:23] <barry> BjornT: okay.  flacoste please just email the list, we'll postpone final decision until after that discussion happens
[15:23] <sinzui> Well we are using mwhudson's generated documentation right now
[15:23] <gary_poster> BjornT: one more, trying to be helpful: http://sphinx.pocoo.org/
[15:23] <BjornT> gary_poster: could you also convert one of our doctests, and generate something for it?
[15:23] <flacoste> sinzui: that's generated using docstrings, we are talking about processing the doctest files here
[15:23] <sinzui> sorry
[15:24] <flacoste> gary_poster: converting launchpadlib would be good
[15:24] <gary_poster> BjornT: um, let me talk that over with flacoste and you out-of-meeting so I know what you mean.  oh, ok.
[15:24] <flacoste> barry: ok, we will cook an example and discuss it with the list
[15:25] <barry> flacoste: thanks!  anything else on this topic?
[15:25] <barry> [TOPIC]  * Require testing of JavaScript (indeed, all UI) changes on multiple platforms (gmb).
[15:25] <MootBot> New Topic:   * Require testing of JavaScript (indeed, all UI) changes on multiple platforms (gmb).
[15:26] <barry> gmb: the floor is yours
[15:26] <gmb> So.
[15:26] <gmb> Bug 273401 is a wonderful thing
[15:26] <gmb> And was caused by an errant comma in some Javascript.
[15:26] <gmb> However, it didn't occur on Firefox
[15:26] <sinzui> I think jslint may have caught that problem
[15:26] <gmb> Because Firefox's JS engine is quite permissive.
[15:27] <mars> gmb, we discussed that today.  Foundations has a solution - JavaScript lint should catch it.
[15:27] <gmb> mars: Brilliant.
[15:27] <mars> and we will be adding Lint this cycle
[15:27] <gmb> Even so, I wonder if we shouldn't make a point of testing JS changes more thoroughly in > 1 browser.
[15:27] <mars> err, we will be add DE-lint tools this cycle :)
[15:27] <flacoste> mars: well, as a stretch goal
[15:27] <gmb> (And by that I mean significantly different browsers, so Geko, something WebKitty, IE, etc)
[15:27] <abentley> That said, I think it would be a really good idea to have unittests of our JS functionality.
[15:27] <intellectronica> lint would be awesome. still, it doesn't mean that we shouldn't require testing on important platforms
[15:28] <gmb> abentley: Well that would be the ideal, yes.
[15:28] <flacoste> abentley: we are also working on that this cycle
[15:28] <gmb> Btw, according to jslint, launchpad.js is very, er, linty.
[15:28] <flacoste> lint integration is part of that objective
[15:28] <intellectronica> gmb, abentley: is this something we could have unit tested?
[15:28] <sinzui> gmb: it is not lying
[15:28] <intellectronica> i think that for JS pagetesting is much more important than unit testing
[15:29] <gmb> intellectronica: Well, it's something that would have made any unit test break, assuming that the testing engine was strict about syntax.
[15:29] <flacoste> intellectronica: most unit testing allows you to do "pagetesting"
[15:29] <intellectronica> well, if it's a syntax thing then lint should be enough
[15:29] <flacoste> simulate DOM events
[15:29] <abentley> intellectronica: Yes, I believe so.
[15:30] <intellectronica> flacoste: is it so? i thought meaningful pagetesting for dynamic html / js / ajax really requires actually having a browser working
[15:30] <intellectronica> (so something like selenium)
[15:30] <abentley> intellectronica: Yes, something like selenium is what I meant.
[15:30] <flacoste> intellectronica: it only needs a JS interpreter supporting DOME
[15:30] <flacoste> which you get in a browser
[15:31] <rockstar> flacoste, intellectronica, yui has a pretty good testing framework.
[15:31] <flacoste> but there are various ways to do it
[15:31] <mars> rockstar, yes, and we will also be looking at Doh
[15:31] <intellectronica> rockstar: yeah, that would definitely be a good start
[15:31] <flacoste> depending on the unit testing framework we use
[15:31] <mars> there are a number of things to consider, like CLI usage, and PQM integration
[15:31] <mars> that's all part of the Foundations js testing story for this cycle
[15:32] <flacoste> anyway, we don't need to discuss that here
[15:33] <barry> cool, thanks.  so we'll wait for foundations work this cycle?
[15:33] <intellectronica> so, what i think we do need to discuss is how we can make reviews catch more problems with JS and DHTML
[15:34] <intellectronica> i think gmb's idea of requiring testing on many platforms is good
[15:34] <flacoste> JS training for reviewers... oh wait...
[15:34] <barry> intellectronica: yes, guidelines for reviewing js would be most appreciated
[15:34] <barry> intellectronica: it would help if we had access to a few vm's with such browsers on them
[15:35] <barry> intellectronica: but also, there's a page with the os's that people have
[15:35] <intellectronica> barry: well, i haven't looked at this particular problem, but if it's a syntax error than obviously we can't make a guidance to check every syntactical construct separatetly...
[15:35] <mars> intellectronica, to be honest, I think the lint tools will do most of the heavy lifting for now.  Reviewers will need more in-depth JS knowledge to spot things like scoping issues.
[15:36] <mars> intellectronica, however, reviewing JavaScript best practices would help
[15:36] <intellectronica> mars: yes, i agree. i think that we should encourage reviewers to involve someone who feels more comfortable with js if they are concerned that they may have not covered everything
[15:36] <salgado> barry, matsubara can do that for us using browsershots
[15:36] <mars> this issue wouldn't have happened if the link had been coded soundly to start with
[15:37] <barry> mars: most bugs are like that <wink>
[15:37] <intellectronica> slowly we'll build JS proficiency anyway, especially after the epic
[15:37] <barry> salgado: should that be a requirement for ui involving js?
[15:38] <salgado> maybe for all UI changes?
[15:38] <intellectronica> salgado: ideally, but that could slow us down considerably, which would be a shame
[15:38] <intellectronica> lot's of branches touch on some UI
[15:38] <barry> maybe.  if so, it has to be done by the dev as part of their branch submission
[15:39] <barry> intellectronica: right
[15:39] <salgado> or as part of QA on edge?
[15:39] <salgado> s/edge/staging
[15:39] <barry> salgado: hmm, interesting
[15:40]  * barry feels like the discussion has run out of steam
[15:40] <barry> seems like we have no actions out of this, except wait for foundations and epic
[15:41] <barry> so...
[15:41] <mars> barry, I can add some links to the JavaScript review page
[15:41] <barry> mars: thanks,that would be helpful
[15:41] <mars> (we do have a JS review page, right?)
[15:41] <barry> well, we have a JS style guide page
[15:41] <intellectronica> mars: we have a style guide. i think that's about it
[15:41] <mars> ok, that works
[15:42] <mars> no '#' links!
[15:42] <barry> [ACTION] mars to add some links to the js style guide page to help reviewers
[15:42] <MootBot> ACTION received:  mars to add some links to the js style guide page to help reviewers
[15:42] <barry> 3 minutes left... one more (hopefully) quick topic
[15:42] <barry> [TOPIC]  * 78 column limit okay in doctest narrative? -- barry
[15:42] <MootBot> New Topic:   * 78 column limit okay in doctest narrative? -- barry
[15:42] <sinzui> What was the 78 column ruling?
[15:42] <barry> this was actually brought up by jml in asiapac
[15:43] <barry> but i also would like to relax the 72 column limit and just allow 78 columns everywhere in a doctest
[15:43] <barry> what say ye?
[15:43] <bigjools> +1
[15:43] <sinzui> +1
[15:43] <flacoste> -1
[15:43] <abentley> +1
[15:43] <flacoste> mainly for esthetic reason
[15:43] <rockstar> +1
[15:43] <flacoste> and quoting is easier
[15:43] <abentley> I say 79, dammit!
[15:43] <flacoste> nah!
[15:44] <bigjools> it's a PITA to
[15:44] <bigjools> oo0ps
[15:44] <flacoste> 79 is very bad
[15:44] <barry> abentley: well i like 79 too :)
[15:44] <flacoste> because it wraps very badly when reviewing
[15:44] <bigjools> it's a PITA to wrap differently for text vs code
[15:44] <intellectronica> i don't care that much, but, what's the motivation for this?
[15:44] <barry> flacoste: jml's point, which i agree with, is that it's just more work to deal with and think about and doesn't really buy us that much
[15:44] <salgado> why did we change to 72 in the first place?  I can't remember
[15:45] <BjornT> -1. it's easier to read 72 characters
[15:45] <flacoste> because we use that for code comments
[15:45] <flacoste> and makes wrapping easier
[15:45] <sinzui> intellectronica: The original argument for 72 is that it is easier to read. Bogus! English is 45-60 character line length
[15:45] <barry> flacoste: how does it make wrapping easier?
[15:45] <flacoste> hmm, quoting!
[15:45] <sinzui> intellectronica: so 78 is not really work than 72.
[15:45] <salgado> flacoste, we don't use that for code comments.  at least not as a policy
[15:45] <bigjools> very subjective arguments so far
[15:45] <abentley> flacoste: A width of < 80 is already pretty constraining.
[15:45] <intellectronica> sinzui: i mean the argument for extending to 78
[15:46] <flacoste> bigjools: the PITA is also subjective :-)
[15:46] <sinzui> intellectronica: I think no one likes my reviews
[15:46]  * bigjools is amazed at how heated opinions can get for trivial things
[15:46] <barry> btw, the point is to have one and only one column width for our files
[15:46] <intellectronica> +-0 who cares
[15:46] <flacoste> bigjools: bikeshedding :-)
[15:46] <bigjools> flacoste: that's not subjective, it IS a PITA for me :)
[15:46] <flacoste> lol
[15:47] <sinzui> bigjools: I agree. That I why a wrote a tool to do all trivial formatting of doctests
[15:47] <flacoste> we have 4 +1, 2 -1 and 1 +0
[15:47] <sinzui> bigjools: A tool that reports a problem about a trivial aspect of code is pointless unless it also offers to fix it
[15:47] <bigjools> ideally, bazaar would reformat submissions so I don't have to even think about it
[15:47] <barry> and three +1's from asiapac iirc
[15:48]  * barry just wants one fill column dammit!
[15:49] <bigjools> time is ovah
[15:49] <flacoste> barry: time to use your presidential power here :-)
[15:49] <bigjools> chuckle
[15:49] <barry> mwah ha ha!
[15:49] <sinzui> Anyone who wants to wrap at 72 may, he just does not have the right to complain about narrative that wraps at 78
[15:49] <flacoste> you two objectives from Launchpad veterans, just dimiss the old people and go with the younger generation
[15:50] <barry> ok, i think 78 is OK but not required.  ifyou want to wrap to 72, np, but 78 for code + docs is fine too
[15:50] <flacoste> s/you/& have/
[15:50] <barry> sinzui: exactly
[15:50] <barry> :)
[15:50] <flacoste> barry: that's too complex a rule
[15:50] <flacoste> barry: wrap at 78
[15:50] <flacoste> that's easy
[15:50] <sinzui> flacoste: this is the purging of SteveA style I think
[15:50] <barry> works for me.  wrap at 78
[15:50] <bigjools> what?!  SteveA has style?
[15:51] <barry> time's up.  sorry for going over folks
[15:51] <barry> #endmeeting
[15:51] <MootBot> Meeting finished at 09:51.
[15:51] <barry> thanks everybody, have a great day
[15:51] <intellectronica> thanks barry
[15:51] <bigjools> thanks!
[15:51] <mars> interesting lesson in group dynamics...
[15:51] <sinzui> bigjools: wrap narrative at 72 characters, use moin headers instead of RST.
[15:51] <barry> lol
[15:51] <sinzui> it's true
[15:51] <barry> everybody pile on bigjools for breaking the rules
[15:52]  * bigjools raises shields