ReviewerMeeting20090225

Not logged in - Log In / Register

Revision 1 as of 2009-03-04 13:34:23

Clear message

ReviewerMeeting20090225

summary

logs

Feb 25 10:00:38 <barry> #startmeeting
Feb 25 10:00:39 <MootBot>       Meeting started at 09:00. The chair is barry.
Feb 25 10:00:39 <MootBot>       Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
Feb 25 10:00:41 *       flacoste (n=francis@canonical/launchpad/flacoste) has joined #launchpad-meeting
Feb 25 10:00:52 <barry> hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
Feb 25 10:00:54 <gmb>   me
Feb 25 10:01:09 <gmb>   ... and apparently no-one else...
Feb 25 10:01:10 <bac>   me
Feb 25 10:01:13 <mars>  me
Feb 25 10:01:31 <gary_poster>   me
Feb 25 10:01:37 <danilos>       me
Feb 25 10:01:44 <flacoste>      me
Feb 25 10:01:47 <rockstar>      me
Feb 25 10:01:47 <salgado>       me
Feb 25 10:01:58 <adeuring>      me
Feb 25 10:02:28 <sinzui>        me
Feb 25 10:02:51 <barry> [TOPIC] agenda
Feb 25 10:02:51 <MootBot>       New Topic:  agenda
Feb 25 10:02:59 <barry> * Roll call
Feb 25 10:02:59 <barry>  * Reviewers to enforce bug<->branch linking for all non-trivial branches (intellectronica)
Feb 25 10:02:59 <barry>  * Determine official preference, if any, of Storm usage: And(expr, expr) vs. expr & expr, Gary
Feb 25 10:02:59 <barry>  * Determine why _get_store uses protected spelling, and if we think it should, Gary
Feb 25 10:02:59 <barry>  * Merge proposals and cover letters (barry)
Feb 25 10:02:59 <barry>  * Using OCR for JavaScript reviews (mars)
Feb 25 10:02:59 <barry>  * Peanut gallery (anything not on the agenda)
Feb 25 10:02:59 <barry>  * Mentoring update
Feb 25 10:02:59 <barry>  * Action items
Feb 25 10:03:15 <BjornT>        me
Feb 25 10:03:21 <bigjools>      me
Feb 25 10:03:21 <barry> intellectronica: ping
Feb 25 10:03:57 <barry> i guess we'll skip his topic for now
Feb 25 10:04:09 <barry> [TOPIC]  * Determine official preference, if any, of Storm usage: And(expr, expr) vs. expr & expr, Gary
Feb 25 10:04:09 <MootBot>       New Topic:   * Determine official preference, if any, of Storm usage: And(expr, expr) vs. expr & expr, Gary
Feb 25 10:04:16 <barry> gary_poster: you're up
Feb 25 10:04:18 <gary_poster>   Storm supports both imported And/Or (e.g., ``And(expr, expr[, expr]*)``) and overloaded binary operators (e.g., ``(expr) & (expr) [& (expr)]*``).
Feb 25 10:04:18 <gary_poster>   See https://storm.canonical.com/Manual#AND .
Feb 25 10:04:18 <gary_poster>   In our codebase I see And/Or, not binary operators.
Feb 25 10:04:19 <gary_poster>   I have a branch going through review that uses the binary operators.
Feb 25 10:04:19 <gary_poster>   My opinions...
Feb 25 10:04:20 <gary_poster>   Positives for binary operators:
Feb 25 10:04:22 *       al-maisan (n=al-maisa@p5087D46F.dip.t-dialin.net) has joined #launchpad-meeting
Feb 25 10:04:22 <gary_poster>   - no imports
Feb 25 10:04:24 <gary_poster>   - readable
Feb 25 10:04:26 <gary_poster>   Negatives for binary operators:
Feb 25 10:04:28 <gary_poster>   - a hack (they should be able to overload boolean operators but Python does not support)
Feb 25 10:04:30 <gary_poster>   - because of hack, precedence is wrong (e.g., ``Class.foo==42 & Class.bar=='kumquat'`` does not work; you need ``(Class.foo==42) & (Class.bar=='kumquat')``).
Feb 25 10:04:33 <gary_poster>   Maybe some will not find it as readable and stick "less readable" in the negatives.
Feb 25 10:04:35 <gary_poster>   So, what is status of using overloaded binary operators for combining Storm expressions?  Preferred, rejected, allowed, or allowed-while-we-evaluate?
Feb 25 10:05:18 <gary_poster>   (done, in case it wasn't clear :-) )
Feb 25 10:05:56 <barry> gary_poster: sorry i think they're less readable :)
Feb 25 10:06:02 <danilos>       agreed
Feb 25 10:06:04 <gmb>   Ditto.
Feb 25 10:06:06 <barry> gary_poster: and the precedence problem worries me
Feb 25 10:06:08 <BjornT>        -1 on using binary operators
Feb 25 10:06:26 <gary_poster>   gary_poster: cool.
Feb 25 10:06:28 <bigjools>      precendece is my main issue
Feb 25 10:06:39 <adeuring>      -1 -- the precende problem can cause nightmares...
Feb 25 10:07:06 <gary_poster>   (nightmares--well, not really, at least IME--you just get a clear failure)
Feb 25 10:07:28 <gary_poster>   ok, so done?
Feb 25 10:07:36 <barry> gary_poster: i think so, sorry ;)
Feb 25 10:07:40 <gary_poster>   np
Feb 25 10:07:41 <intellectronica>       me (sorry for lateness - new wireless router)
Feb 25 10:07:45 <allenap>       me
Feb 25 10:07:51 <barry> intellectronica: we'll come back to your topic
Feb 25 10:08:01 <barry> [TOPIC]  * Determine why _get_store uses protected spelling, and if we think it should, Gary
Feb 25 10:08:01 <MootBot>       New Topic:   * Determine why _get_store uses protected spelling, and if we think it should, Gary
Feb 25 10:08:04 <danilos>       intellectronica: it has some serious latency, you might want to consider going back to the old one
Feb 25 10:08:12 <gary_poster>   Last week we stated that we should not have public methods spelled as protected methods (_*).
Feb 25 10:08:13 <gary_poster>   I noticed that our SQLBase bits seem to rely on ``_get_store``.
Feb 25 10:08:13 <gary_poster>   This method can be convenient even when using Storm spelling.  It is shorter to use than the full utility call, and it specifies which store and flavor to use.
Feb 25 10:08:13 <gary_poster>   I'm guessing that changing this means changing our SQLBase code?
Feb 25 10:08:13 <gary_poster>   I'm inclined to put changing this as a bug report in LP.
Feb 25 10:08:14 <gary_poster>   Agree/appropriate/possible?
Feb 25 10:08:32 <gary_poster>   (Or maybe I misunderstand about this being needed by our SQLBase stuff?)
Feb 25 10:08:38 <gary_poster>   (done)
Feb 25 10:10:36 <barry> gary_poster: have you seen abentley's branch?
Feb 25 10:10:37 <danilos>       is this not about storm code?
Feb 25 10:10:46 <gary_poster>   barry: no
Feb 25 10:10:51 <flacoste>      so i asked jamesh
Feb 25 10:11:01 <flacoste>      and he said that the only reason for having an underscore there
Feb 25 10:11:07 <flacoste>      is that it's not part of the SQLObject API
Feb 25 10:11:14 <flacoste>      but I don't think we care now
Feb 25 10:11:46 <barry> abentley has a new storm base class for convenience.  i think jml was reviewing that but i don't know the status of it
Feb 25 10:11:54 <barry> it provides a convenient way to get the store
Feb 25 10:12:31 <barry> flacoste: i think you're right.  plus we want to get rid of the sqlobject api anyway don't we? :)
Feb 25 10:12:37 <flacoste>      well
Feb 25 10:12:44 <flacoste>      sometime in the future
Feb 25 10:12:51 *       abentley (n=abentley@bas1-toronto09-1279621843.dsl.bell.ca) has joined #launchpad-meeting
Feb 25 10:13:02 <flacoste>      but it's a lot of work
Feb 25 10:13:06 <flacoste>      and not that practical either
Feb 25 10:13:19 <flacoste>      and the bare storm API is a pain
Feb 25 10:13:24 <gary_poster>   heh
Feb 25 10:13:25 <barry> we can do it piecemeal too right?
Feb 25 10:13:25 <flacoste>      so SugarStorm is nice
Feb 25 10:13:30 <flacoste>      more or less
Feb 25 10:13:39 <barry> right, that's what i'm thinking
Feb 25 10:13:50 <flacoste>      because of the incompatibility between the resultset interface
Feb 25 10:13:54 <rockstar>      flacoste, bare Storm needs improvements, but if we avoid those improvements, that's a tragedy.
Feb 25 10:13:56 <flacoste>      and we use these for unions
Feb 25 10:14:13 <flacoste>      i have great hope for abentley's SugarStorm
Feb 25 10:14:22 <flacoste>      or watherver it's called
Feb 25 10:14:33 <gary_poster>   agree with rockstar.  If this is a Storm thing, then let's change this in Storm.  This seems like it should go lower than SugarStorm
Feb 25 10:14:42 <flacoste>      we should probably make it easy to combine SQLObject and Storm ResultSet
Feb 25 10:14:51 <flacoste>      so that we aren't block by the incompatibility
Feb 25 10:14:59 <flacoste>      because when you start converting one object
Feb 25 10:15:02 <barry> flacoste: +1 if possible
Feb 25 10:15:05 <flacoste>      which uses UNION
Feb 25 10:15:12 <flacoste>      it becomes an never-ending tasks
Feb 25 10:15:34 <flacoste>      I once tried converting Person to use only the Store API
Feb 25 10:15:45 <flacoste>      and gave up because the branch was inflating faster than Argentina's inflation
Feb 25 10:15:54 <gary_poster>   heh
Feb 25 10:15:59 <rockstar>      :)
Feb 25 10:16:08 <barry> flacoste: 70 hits for 'union|UNION' in lib/c/l/database
Feb 25 10:16:14 <bigjools>      I got caught by the union thing
Feb 25 10:16:26 <bigjools>      would be great to fix that
Feb 25 10:16:27 <barry> flacoste: well, person might not be the best first choice :)
Feb 25 10:16:38 <flacoste>      well, i was there
Feb 25 10:16:41 <flacoste>      and it started fine :-)
Feb 25 10:16:45 <barry> :-D
Feb 25 10:16:49 <flacoste>      and needed to use storm for some thing
Feb 25 10:16:50 <flacoste>      anyway
Feb 25 10:17:15 <gary_poster>   ( well, the Person anecdote was intended as an example of Storm API not being as convenient, right?)
Feb 25 10:17:17 <barry> so, back to gary's specific question: what to do about _get_store()?
Feb 25 10:17:22 <salgado>       gary_poster, flacoste, will we still want obj.get_store() after stub's landed his sso branch?  it includes some IStore adapters for our classes
Feb 25 10:18:46 <gary_poster>   salgado: if we *have* to have these helper static methods anyway, and they are so easy to use, shouldn't we just use them?
Feb 25 10:18:53 <gmb>   herb: Okay, can you apply https://pastebin.canonical.com/14232/ and then apply https://pastebin.canonical.com/14233/ please?
Feb 25 10:19:01 <gmb>   Heh.
Feb 25 10:19:02 <gary_poster>   gmb: hee hee
Feb 25 10:19:03 <gmb>   Wrong channel.
Feb 25 10:19:12 <abentley>      salgado: I certainly prefer class methods over zope stuff where either solution works.
Feb 25 10:19:26 <gary_poster>   agree
Feb 25 10:19:38 <salgado>       fair enough.  I prefer that too
Feb 25 10:20:21 <gary_poster>   so to change this is this in our code base or in Storm?  flacoste ?
Feb 25 10:20:59 <gary_poster>   'cause if it is in Storm, may or may not happen ...
Feb 25 10:21:00 <abentley>      gary_poster: niemeyer was not receptive to my suggestions.
Feb 25 10:21:16 <gary_poster>   abentley: yes, definitely observed
Feb 25 10:21:26 *       Ursinha is now known as aham
Feb 25 10:21:31 *       aham is now known as Ursinha
Feb 25 10:22:14 <barry> abentley: did jml finish the review of your branch?
Feb 25 10:22:36 <abentley>      barry: No.  He asked for changes, I submitted a revised version, then nothing.
Feb 25 10:22:47 <barry> abentley: i'll ping him tonight about it
Feb 25 10:22:53 <barry> abentley: but you should too :)
Feb 25 10:23:16 <abentley>      barry: I've got plenty of other stuff to work on, so I'm not fussed.
Feb 25 10:23:27 <barry> gary_poster: have we resolved your topic? ;)
Feb 25 10:24:11 <gary_poster>   barry: not really, unless we say that, because there wasn't much clamoring of agreement with me that this ought to be changed, we should just ignore it.
Feb 25 10:24:50 <gary_poster>   but then, can I use _get_store?
Feb 25 10:25:04 <barry> gary_poster: you can always add an alias for get_store() and use that
Feb 25 10:25:08 <gary_poster>   My branch does.  flacoste thouht it was reasonable at the time.
Feb 25 10:25:14 <barry> e.g.:  get_store = _get_store
Feb 25 10:25:26 <barry> sounds good to me
Feb 25 10:25:34 <salgado>       should it not be getStore(), though?
Feb 25 10:25:37 <gary_poster>   and we tack that on to all our classes?
Feb 25 10:25:42 <barry> salgado: dang, yeah :/
Feb 25 10:26:24 <barry> gary_poster: you had another topic?
Feb 25 10:26:40 <gary_poster>   heh, yeah.  one sec, lemme get the paste
Feb 25 10:26:49 <gary_poster>   I miss the old bzr review plugin a bit because it enforced our policies.
Feb 25 10:26:49 <gary_poster>   In particular, the lint is not being used regularly, and the information about pre-impl call is often missing in reviews I've done.
Feb 25 10:26:49 <gary_poster>   I have a quick example about the ``make lint`` issue.
Feb 25 10:26:50 <gary_poster>   I noticed when I had to manually switch my most recent branch over from devel to db-devel, and merge, that ``make lint`` had apparently not been run for many of the branches.
Feb 25 10:26:50 <gary_poster>   I had to do a lot of cleaning up on the merged code to make ``make lint`` happy.  The majority of the complaints were real.
Feb 25 10:26:53 <gary_poster>   We're building generic bzr tools AIUI (bzr send), but our policies are not generic, and enforcing them is valuable.
Feb 25 10:26:56 <gary_poster>   I'm inclined to want a lp-specific bzr plugin that defers the heavy lifting to the bzr send plugin code, but is more specific to what we want.
Feb 25 10:26:59 <gary_poster>   I also wonder if ec2test could help with the linting, but that's not as clear to me.
Feb 25 10:27:01 <gary_poster>   The general idea would be that, if you use -s to submit to PQM, it would make sure that ``make lint`` was happy.
Feb 25 10:27:04 <gary_poster>   However, with the old review plugin, there was a way to say "yeah, yeah, make lint is on crack for that complaint."  We would need that here too.
Feb 25 10:27:07 <gary_poster>   We could put it in command line options but would prefer to have it in a file.  Not sure where the file would go.  But that's an implementation detail.
Feb 25 10:27:10 <gary_poster>   So: IRT my general observation of having regressed a bit in our process because of missing automation for linting and message regexes: agree/disagree?
Feb 25 10:27:13 <gary_poster>   And then furthermore, if you agree that we have regressed, what should we do to improve?
Feb 25 10:27:43 <gary_poster>   (done)
Feb 25 10:28:25 <bigjools>      can we fix lpreview to just use lpsend?
Feb 25 10:28:27 <gmb>   There's no reason we can't hack the existing review plugin to do lint + cover letter and then hand off to bzr send.
Feb 25 10:28:42 <gmb>   Well, I don't *think* there's any reason, anyway.
Feb 25 10:28:43 <barry> gary_poster: that dovetails with my topic.  if we used the standard cover letter template for mps at least people would have to willfully ignore linting and pre-imps
Feb 25 10:28:47 <gary_poster>   gmb: that's the kind of thing I'm talking about, yeah
Feb 25 10:28:49 <bigjools>      gmb: great minds think alike
Feb 25 10:28:49 <gmb>   abentley would know better than I.
Feb 25 10:28:52 <abentley>      gmb: Yes there is.  There's no way to specify a message body
Feb 25 10:29:03 <gmb>   abentley: That's what I was afraid you were going to say.
Feb 25 10:29:38 <abentley>      gmb: It's not that 'bzr send' couldn't, it's that it's not implemented yet.
Feb 25 10:29:45 <barry> abentley: i wonder if there was some $EDITOR hack we could use for that
Feb 25 10:30:07 <gmb>   barry: send just passes over to the MUA, so I'm not sure that would work.
Feb 25 10:30:11 <abentley>      barry: If we want to force everyone to use mail_client=editor, perhaps.
Feb 25 10:30:36 <barry> abentley: yeah, that's what i meant.  and it would just be for lp branches, so location.conf could override
Feb 25 10:30:52 <intellectronica>       abentley: i use gmail, and so i benefit from jamesh's plugin. having to use EDITOR will make like hard for me
Feb 25 10:30:58 <barry> abentley: not that i have any concrete ideas.  just wonderin'
Feb 25 10:31:00 <sinzui>        I would disable such a feature because I start my cover letter when I create my branch
Feb 25 10:31:03 <gary_poster>   barry: yeah, some kind of automated/enforced-ish standard template would be fine with me too.  It's not as tight as the lpreview approach, but something is better than nothing, and might be sufficient
Feb 25 10:31:05 <danilos>       it'd be nice for lpsend to actually work with my name first, I have to manually paste the cover letter anyway
Feb 25 10:31:24 <barry> sinzui: so do i
Feb 25 10:31:27 <abentley>      danilos: Work with your name?
Feb 25 10:31:38 <BjornT>        danilos: +1 :)
Feb 25 10:31:41 <gary_poster>   so the temolate thing seems like an insufficient idea
Feb 25 10:32:09 <mars>  danilos, +1 as well :)
Feb 25 10:32:17 <BjornT>        abentley: some of us get a unicode error when using lpsend
Feb 25 10:32:32 <abentley>      BjornT: Not from send, from Launchpad, right?
Feb 25 10:32:39 <danilos>       abentley: right
Feb 25 10:32:41 <BjornT>        abentley: right
Feb 25 10:33:09 <abentley>      So that's not a send bug, and AIUI, work has been done to fix it this cycle.
Feb 25 10:33:49 <abentley>      I've said before, but I guess I have to say again, I think bzr send should support a hook that we can use to plug in the process stuff from lpreview.
Feb 25 10:34:27 <barry> abentley: what are you waiting for? :)
Feb 25 10:35:02 <gary_poster>   abentley: (I don't remember hearing that before) +1
Feb 25 10:35:03 <abentley>      barry: a free moment.
Feb 25 10:35:11 <barry> abentley: those are so overrated
Feb 25 10:35:46 <gary_poster>   ok, so maybe this is another one of those "...and we descend into silence" moments, this time because we agree that something needs to be done but don't have the time.
Feb 25 10:35:46 <gmb>   abentley: Is there a bug for updating send to add that hook?
Feb 25 10:36:16 <barry> gary_poster: yep. seems like time is better spend on send rather than lpreview though, so that's something
Feb 25 10:36:16 <abentley>      gmb: I don't know.
Feb 25 10:36:19 <mars>  gary_poster, a very astute observation :)
Feb 25 10:36:29 <gary_poster>   :-)
Feb 25 10:36:43 <barry> gary_poster: will you check to see if there's a bug open on adding a hook for bzr send?
Feb 25 10:36:55 <gary_poster>   barry: ok
Feb 25 10:37:17 <barry> [ACTION] gary_poster will check to see if there's a bug open for adding a hook to 'bzr send' and submit one if there isn't
Feb 25 10:37:18 <MootBot>       ACTION received:  gary_poster will check to see if there's a bug open for adding a hook to 'bzr send' and submit one if there isn't
Feb 25 10:37:39 <gary_poster>   barry: IRT my previous topic: sorry, but I was not clear.  so can I just use _get_store for now, and move on?
Feb 25 10:37:55 <barry> gary_poster: add a getStore() alias if possible and use that
Feb 25 10:38:00 <gary_poster>   ...ok
Feb 25 10:38:02 <barry> thanks
Feb 25 10:38:09 <gary_poster>   sure, thanks everybody
Feb 25 10:38:21 <barry> [TOPIC]  * Merge proposals and cover letters (barry)
Feb 25 10:38:21 <MootBot>       New Topic:   * Merge proposals and cover letters (barry)
Feb 25 10:38:32 <barry> so along the lines of gary_poster 's last topic...
Feb 25 10:38:54 <barry> i notice that not everyone is using the standard cover letter template.  some people don't use any template
Feb 25 10:39:07 <barry> should we enforce that?  (updating the template if necessary)
Feb 25 10:39:07 *       mars hides
Feb 25 10:39:14 *       gary_poster hides
Feb 25 10:39:24 <barry> not blaming anyway, just wondering!
Feb 25 10:39:27 *       danilos hides behind gary
Feb 25 10:39:27 <gary_poster>   :-)
Feb 25 10:39:30 <gary_poster>   lol
Feb 25 10:39:34 *       BjornT doesn't know where the standard template is located
Feb 25 10:39:37 <barry> if the template isn't useful or overkill, let's say so
Feb 25 10:39:44 <danilos>       I don't know where it is either, though
Feb 25 10:39:45 <abentley>      I don't think we should enforce a template.  There are lots of times it doesn't make sense.
Feb 25 10:40:18 <barry> https://dev.launchpad.net/QuickCoverLetterTemplate
Feb 25 10:40:25 <BjornT>        i think we should get bzr send to use the template. then people will automatically use it, unless they explicitly choose not to
Feb 25 10:40:32 <barry> well, the diff output could be removed now
Feb 25 10:40:33 <mars>  BjornT, +1
Feb 25 10:40:52 <barry> abentley: i think the template usually makes sense though
Feb 25 10:40:58 <mars>  a new plugin for bzr send that adds a --template option?
Feb 25 10:41:00 <gary_poster>   I must admit, I kind of like using lp TTW to request reviews
Feb 25 10:41:23 <gary_poster>   but you know, if "we don't do that" that's ok
Feb 25 10:41:31 <barry> gary_poster: you could still use the template :)
Feb 25 10:41:40 <gary_poster>   but seems a bit of a shame, since we have a TTW interface
Feb 25 10:41:43 <mars>  gary_poster, that's a different problem - communicating a project's review preferences through the web API
Feb 25 10:41:51 <abentley>      barry: I don't.  I find I'm usually writing the same thing under several headings.
Feb 25 10:42:11 <mars>  oops, nix the 'API' from that last statement
Feb 25 10:42:13 <gary_poster>   barry: sure...which is where?  and how is policy for *that* plugged in?
Feb 25 10:42:25 <gary_poster>   (I mean, in the TTW interface)
Feb 25 10:42:38 <gary_poster>   oh sorry
Feb 25 10:42:38 <barry> abentley: really?  maybe there's some confusion about what's intended for each section?
Feb 25 10:43:07 <flacoste>      i preferred the old template
Feb 25 10:43:11 <flacoste>      and i still use it
Feb 25 10:43:16 <barry> gary_poster: well, i just mean that you could paste the cover letter into the text area
Feb 25 10:43:17 <flacoste>      i run bzr write-cover-letter
Feb 25 10:43:18 <abentley>      Well, a bit, but it generally just gets in the way of a natural description of the change.
Feb 25 10:43:22 <flacoste>      and then :r cover.txt
Feb 25 10:43:29 <gmb>   flacoste: Me too.
Feb 25 10:43:38 <gmb>   Well, for non-trivial branches, anyway.
Feb 25 10:43:38 <flacoste>      when bzr send fires my editor
Feb 25 10:43:38 <mars>  :r ?
Feb 25 10:43:50 <flacoste>      mars: i see you aren't enlightened
Feb 25 10:43:57 <flacoste>      vim powers!
Feb 25 10:43:59 <danilos>       mars: it's likely just some vi crap, ignore it :)
Feb 25 10:44:05 <mars>  lol
Feb 25 10:44:28 <mars>  ah
Feb 25 10:44:39 <barry> dang, we're almost out of time.  let's drop this for now because i'd like to give mars's topic a shot
Feb 25 10:44:51 <barry> [TOPIC]  * Using OCR for JavaScript reviews (mars)
Feb 25 10:44:51 <MootBot>       New Topic:   * Using OCR for JavaScript reviews (mars)
Feb 25 10:44:52 <mars>  barry, I'll be brief
Feb 25 10:44:55 <barry> mars: thx
Feb 25 10:45:01 <mars>  Hi everyone
Feb 25 10:45:07 <mars>  Last Monday the AJAX team decided to expand the scope of JavaScript reviews in Launchpad.
Feb 25 10:45:08 *       Ursinha is now known as ra
Feb 25 10:45:11 *       ra is now known as Ursinha
Feb 25 10:45:13 <mars>  Any OCR should be able to pick up a JavaScript review, if they feel comfortable doing so.  We just ask that the review be unofficially mentored by one of the sprint attendees.
Feb 25 10:45:23 <mars>  These people were at the AJAX sprint, or on the AJAX team, and can mentor a JavaScript review: flacoste, mars, sinzui, Edwin, cprov, noodles, intellectronica, rockstar, danilo, and jtv
Feb 25 10:45:35 <mars>  Also, feel free to ask me if any questions come up during the review.
Feb 25 10:45:49 <mars>  that's all
Feb 25 10:45:56 *       allenap discovers that TTW means Table-Top Wargaming
Feb 25 10:46:02 <gary_poster>   lol
Feb 25 10:46:19 <gary_poster>   Through-the-web was how I've heard it used, and my intent :-)
Feb 25 10:46:21 <bigjools>      I thought it was ruder
Feb 25 10:46:34 <barry> mars: thanks
Feb 25 10:47:00 <barry> any comments on mars's request or should we break?
Feb 25 10:47:09 <sinzui>        I don't qualify to be a YUI/Windmill reviewer. I just abandoned using windmill to  test YUI + GMap. I'm back to despising YUI for reinventing everything to make mashups nigh impossible.
Feb 25 10:47:09 <gary_poster>   write it down someplace
Feb 25 10:47:13 <allenap>       Sounds like a good request.
Feb 25 10:47:18 <intellectronica>       barry: mention my item, since i don't think it requires much discussion :)
Feb 25 10:47:28 <mars>  sinzui, fair enough
Feb 25 10:47:34 <barry> intellectronica: ah, sorry
Feb 25 10:47:37 <sinzui>        PS. I hate GMap too
Feb 25 10:47:43 <barry> [TOPIC]  * Reviewers to enforce bug<->branch linking for all non-trivial branches (intellectronica)
Feb 25 10:47:44 <MootBot>       New Topic:   * Reviewers to enforce bug<->branch linking for all non-trivial branches (intellectronica)
Feb 25 10:47:55 <mars>  sinzui, I would love it if you could write a ranting email about that statement though
Feb 25 10:48:01 <barry> intellectronica: +1 :)
Feb 25 10:48:28 <gary_poster>   intellectronica: (1) I assume up mean --fixes=lp:XXX?
Feb 25 10:48:36 <gary_poster>   (2) how do we check that?
Feb 25 10:48:37 <barry> gary_poster: or you can do it TTW :)
Feb 25 10:48:47 <intellectronica>       gary_poster: either that, or you can do it ttw
Feb 25 10:48:47 <gary_poster>   ah ok
Feb 25 10:48:52 <intellectronica>       heh
Feb 25 10:48:54 <barry> heh
Feb 25 10:48:55 <gary_poster>   :-)
Feb 25 10:49:01 <sinzui>        mars: I was going to bring it up in the meeting, but my thoughts are not collected.
Feb 25 10:49:04 <intellectronica>       and you can check it ttw, or do it after the fact
Feb 25 10:49:04 <mars>  gary_poster, require a hook in pqm-submit, --no-fixes has to be explicitly set for this branch?
Feb 25 10:49:22 <mars>  kinda like explicitly setting --no-lint
Feb 25 10:49:35 <barry> okay, so apologies for going over.  thanks everybody and have a good day
Feb 25 10:49:38 <intellectronica>       mars: the thing is, --fixes is on commit, not on pqm submit
Feb 25 10:49:44 <intellectronica>       thanks barry
Feb 25 10:49:45 <barry> #ENDMEETING