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