[15:00] <barry> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is barry.
[15:00] <barry> hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
[15:00] <rockstar> me
[15:00] <mrevell> me
[15:00] <abentley> me
[15:00] <adeuring> me
[15:00] <bigjools> me
[15:00] <allenap> me, but only half (sprinting in Lexington)
[15:00] <EdwinGrubbs> me
[15:01] <abentley> allenap: m ?
[15:01] <danilos> me
[15:01] <allenap> abentley: This week it's e
[15:01] <flacoste> me
[15:02] <mars> me
[15:02] <barry> [TOPIC] agenda
[15:02] <MootBot> New Topic:  agenda
[15:02] <barry> i don't have much today...
[15:02] <barry>  * Roll call
[15:02] <barry>  * Agreement on statuses:
[15:02] <barry>    * needs-reply == needs-fixing
[15:02] <barry>    * merge-approved == approve
[15:02] <barry>    * merge-conditional == approve + comment
[15:02] <barry>  * If there's time, the old boring script
[15:02] <barry>    * Next meeting
[15:02] <barry>    * Action items
[15:02] <barry>    * Queue status
[15:03] <barry>    * Mentoring update
[15:03] <barry> [TOPIC]  * Agreement on statuses:
[15:03] <MootBot> New Topic:   * Agreement on statuses:
[15:03] <BjornT> me
[15:03] <gmb> me
[15:03] <barry> at the asiapac meeting, i explained what we'd agreed from last week on the mapping between our review status and m-p statuses
[15:03] <barry> everyone there agreed with our mapping
[15:03] <barry> so i guess that makes it official
[15:04] <barry> any comments or other thoughts?
[15:04] <flacoste> can you remind us of that mapping?
[15:04] <danilos> flacoste: it's up in the agenda
[15:04] <danilos> :)
[15:04] <flacoste> doh
[15:05] <barry> :)
[15:06] <barry> silence is assent :)
[15:06] <barry> that's all i have except for the boring stuff.  does anybody have anything not on the agenda?
[15:06] <danilos> yeah
[15:07] <danilos> I wonder about how do we see if there are branches waiting for review in merge-proposals?
[15:07] <barry> danilos: the floor is yours
[15:07] <barry> danilos: they mythical dashboard
[15:07] <danilos> I've tried digging that up, but was unable to find it once I cleared general queue yesterday
[15:07] <barry> s/they/the/
[15:07] <danilos> ok, so it's actually not there?
[15:08] <danilos> can we maybe agree to put branches in 'Mature' until it's there?
[15:08] <danilos> or some other status
[15:08] <abentley> danilos: Other that this: https://code.edge.launchpad.net/~launchpad-pqm/launchpad/devel/+merges ?
[15:09] <danilos> abentley: that doesn't show me only unassigned ones
[15:09] <barry> abentley: that's a good page.  i can already tell that the separate approve step doesn't work 'cause no one set it ;/
[15:09]  * sinzui forgot to type me
[15:09] <sinzui> me
[15:10] <abentley> danilos: All of them will be assigned to Launchpad Developers by default.
[15:11] <danilos> abentley: ok, so the only missing bit is that we need to update merge proposal statuses to 'Approved', right?
[15:12] <bac> me
[15:12] <danilos> and, can we make this URL more visible? I tried getting something along those lines
[15:12] <abentley> danilos: Right.  When they're reviewed, and ready to be merged.
[15:13] <abentley> danilos: It's the "12 branches       proposed for merging into this one." link on https://code.edge.launchpad.net/~launchpad-pqm/launchpad/devel
[15:13] <danilos> abentley: ok, thanks
[15:13] <barry> anything else?
[15:13] <danilos> so, my suggestion would be to make reviewers set "Approved" as well
[15:13] <danilos> barry: nope, that's it from me
[15:14] <barry> danilos: +
[15:14] <barry> +
[15:14] <abentley> barry: How do I subscribe to the new wiki page?
[15:14] <barry> jeebus.  +1
[15:14] <barry> abentley: that's a very good question.  i tried to find it and couldn't
[15:14] <bigjools> you can't!  the price of progress ...
[15:14]  * barry has a BIG LIST of issues with the new wiki
[15:14] <abentley> +1.  Thought that was already done.
[15:15] <barry> abentley: go to your profile page, scroll down to subscriptions and add .* to the list :)
[15:15] <rockstar> abentley: there's a bug for it, we talked about it yesterday.
[15:16] <barry> rockstar: a bug for wiki subscription?
[15:17] <barry> someone wake rockstar :)
[15:17] <barry> anyway...
[15:18] <barry> if there's nothing else, i just want to run through the outstanding action items from like, last decade
[15:18] <BjornT> barry: i have a small agenda item as well (or rather a question)
[15:18] <barry> BjornT: cool, go ahead
[15:19] <BjornT> when are we going to evaluate how the merge proposals are going, and which issues are the most important (for the LP team as a whole) to fix?
[15:20] <barry> BjornT: great question.  i'm inclined to say let's do the evaluation at the beginning of '09.  your thoughts?
[15:20] <BjornT> barry: well, i was hoping sooner, so that we could get the most important fixes in the next milestone :)
[15:21] <barry> BjornT: :)
[15:21] <barry> BjornT: i'm okay with that.  what about doing that for the next round of reviewer meetings?
[15:22] <BjornT> barry: sure
[15:22] <barry> iow, people should come prepared to discuss/lobby for their top m-p bugs
[15:22] <bigjools> diffs plz
[15:22] <barry> we can spend next week's meeting prioritizing them for us
[15:23] <barry> bigjools: bug numbers plz :)
[15:23] <bigjools> haha :)
[15:23] <BjornT> barry: maybe we should tell everyone to pick their 1-2 top bugs, in an attempt to limit the discussions?
[15:23] <barry> BjornT: yes, good idea
[15:24] <abentley> barry: We can decide here what lp reviewers consider high priority.  Please don't expect the code team to adopt those priorities verbatim.
[15:24] <flacoste> abentley: that's for sure
[15:24] <barry> [ACTION] everyone come to next week's meeting with your top 1-2 merge-proposal bug numbers
[15:24] <MootBot> ACTION received:  everyone come to next week's meeting with your top 1-2 merge-proposal bug numbers
[15:24] <barry> abentley: right
[15:24] <abentley> barry: Or alternatively, we could have a meeting where thumper was involved.
[15:25] <barry> abentley: we should do that, but only after we've agreed among ourselves
[15:25] <abentley> And then the outcome might be clearer.
[15:25] <barry> abentley: and remember i have asiapac meetings with thumper and co on monday nights (i know you know that :)
[15:25] <barry> well, /my/ monday nights
[15:26] <BjornT> abentley: agreed, the priorities we come up with here only serves for guidelines. i don't think thumper needs to be in this meeting.
[15:26] <abentley> Okay.
[15:26] <barry> any other topics not on the agenda?
[15:27]  * bigjools raises hand
[15:27] <bigjools> can I nominate a new reviewer?
[15:27] <barry> bigjools: of course!
[15:27] <bigjools> good - Muharem wants to start.
[15:28] <bigjools> he's looking for a mentor right now
[15:28] <bigjools> OAO
[15:29] <barry> bigjools: +1. let me know if he can't round someone up
[15:29] <bigjools> copy that
[15:29] <barry> anything else?
[15:30] <barry> 5...4...3...2...1
[15:30] <barry> [TOPIC] action items
[15:30] <MootBot> New Topic:  action items
[15:30] <barry> please tell me if we should continue these or just forget they ever happened
[15:30] <barry>  * flacoste and foundations to look into techniques for eliminating back-patching of schema types (avoiding circular imports)
[15:30]  * bigjools would love that --^
[15:30]  * barry too, and he doesn't think it's that hard
[15:30] <flacoste> hmm, yeah, i forgot about that
[15:31] <flacoste> barry, patch is welcome ;-)
[15:31] <barry> flacoste: ah, a challenge! :)
[15:31] <bigjools> wow, OSS fever :)
[15:31] <barry> flacoste: sounds like the perfect thing to do while on hold waiting for your isp to un-fsck you
[15:32] <barry> so we'll continue that one
[15:32] <barry>  * rockstar to take discussion of adding launchpadlib tests for exposed api to ml
[15:32]  * barry thinks rockstar fell asleep again :)
[15:32] <barry>  * abentley to investigate current code coverage tools for lp tests
[15:33] <rockstar> barry, well, we discussed it at the Epic.
[15:33] <abentley> Current tools don't do what I want.
[15:34] <barry> rockstar: good.  i will remove it from the agenda! thanks
[15:34] <barry> abentley: cool, you've investigated so i can take it off the agenda :)
[15:35] <flacoste> rockstar: could you file a bug about allowing launchpadlib to speak directly to the publisher for testing purpose?
[15:35] <rockstar> flacoste, sure.
[15:35] <abentley> What I want is a way to know whether a given test command exercises all the new code in a patch.
[15:35] <flacoste> rockstar: that's the main blocker to allow this
[15:35] <rockstar> Okay.
[15:36] <barry> i think that's it.  if there are no objections we can end early today
[15:36] <barry> 5
[15:37] <barry> 4
[15:37] <barry> 3
[15:37] <barry> 2
[15:37] <barry> 1
[15:37] <barry> #endmeeting
[15:37] <MootBot> Meeting finished at 09:37.
[15:37] <barry> thanks everyone!
[15:37] <bigjools> cheers
[15:38] <mars> thanks barry
[15:38] <barry> see ya back at the ranch


[00:07] <StevenK> The bugtask subscriber vocab is built in place
[01:03] <StevenK> wgrant: mawson is updated, my patch cowboyed and JS unshelved, but it only renders timeouts
[01:04] <StevenK> Ah, /auditor finally works
[01:05] <lifeless> zomg'
[01:05] <StevenK> lifeless: Ah, the auditor project page on DF
[01:05] <lifeless> oh
[01:20] <StevenK> wgrant: Right, so the exact matches are great for DF
[01:20] <StevenK> Very fast
[01:20] <wgrant> StevenK: I'd certainly hope so!
[01:20] <StevenK> Maybe we want to restrict the MP vocab
[01:21] <wgrant> One thing I thought of is that you probably want to do a case-insensitive match
[01:21] <wgrant> On Branch.name
[01:21] <StevenK> wgrant: So searching for 'devel' on proposing a LP branch returns too many matches
[01:21] <StevenK> But I'd honestly expect to usually paste in a URL
[01:22] <wgrant> StevenK: You're conditioned to paste a URL because search is so useless today
[01:22] <wgrant> It usually times out, and when it doesn't time out it doesn't return useful results unless you're very accurate
[01:23] <StevenK> Maybe we want to search on unique_name too
[01:23] <StevenK> But I discounted that
[01:24] <wgrant> Prefix search on unique_name makes sense if there's a / in the term
[01:24] <wgrant> Otherwise I don't think it's valuable
[01:27] <StevenK> wgrant: Thoughts on using BranchRestrictedOnProduct for BMP's vocab?
[01:28] <wgrant> StevenK: Remember that BMPs work for more than products
[01:28] <StevenK> wgrant: Prefix search? Then searching for launchpad/devel won't work
[01:30] <wgrant> StevenK: That's true.
[01:30] <wgrant> But mmm
[01:30] <StevenK> contains_string is probably too heavy handed for unique_name
[01:31] <wgrant> Yes, but it's all we have without schema changes
[01:34] <wgrant> And I don't think it's going to be toooo long for a trigram to be effective
[01:34] <wgrant> But you should try.
[01:36] <StevenK> You mean like http://pastebin.ubuntu.com/1641700/ :-)
[01:37] <wgrant> StevenK: Right, that sort of thing
[01:37] <wgrant> Ideally a unique_name match would be component-wise rather than character-wise, but we can't really do that atm
[01:38] <StevenK> Right
[01:38] <StevenK> Let me patch that onto DF
[01:38] <StevenK> wgrant: Oh, shall we TGRM up name and unique_name ?
[01:39] <wgrant> StevenK: Try with and without
[01:39] <wgrant> Max length of unique_name today is 141
[01:39] <wgrant> Which isn't great, but not fatal
[01:40] <StevenK> What's that one?
[01:40] <wgrant>  ~openerp-commiter/openobject-addons/trunk-configuration_wizard_improvement-atp-improve-general-apply-button-color-in-configuration-wizard-pja |         141
[01:40] <StevenK> That's digusting
[01:40] <StevenK> *disgusting
[01:41] <wgrant> Then
[01:41] <wgrant>  ~78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5m-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in/syncany/delimiters       |         135
[01:41] <wgrant>  ~78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxs-phn5hho65-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq5/sysbench/sysbench-pg           |         131
[01:41] <wgrant> Then more openerp
[01:41] <StevenK> I can't complain about the 135 or 131, those are effectively our fault
[01:42] <wgrant> Yep
[01:42] <wgrant> https://code.launchpad.net/~chipaca/ubuntuone-client/dobey-needs-a-nice-self-contained-dbus-signal-to-let-the-applet-know-when-content-queue-changes
[01:45] <StevenK> Apparently, the searches are all ~ 2 seconds
[01:46] <wgrant> ie. awful
[01:46] <wgrant> get a plan
[01:49] <StevenK> wgrant: http://pastebin.ubuntu.com/1641721/
[01:49] <wgrant> StevenK: Heh
[02:02] <wgrant> StevenK: FYI I prefer to name cowboyed indices and tables temp_* so they can be easily found and removed
[02:06] <StevenK> It's still 440 ms with the TRGM
[02:36] <StevenK> wgrant: Would gist rather than gin help?
[02:36] <wgrant> StevenK: No
[02:36] <wgrant> GiST vs GIN is mostly a write vs read tradeoff
[02:36] <wgrant> GIN is slower at writes, but faster at reads
[02:36] <wgrant> So we want GIN
[02:38] <StevenK> But then we're stuffed even with the index
[02:38] <wgrant> Not if it's a relatively consistent 4s
[02:38] <wgrant> It's not create
[02:38] <wgrant> great
[02:38] <wgrant> But it's better than 2s consistent.
[02:38] <wgrant> And will be faster on prod
[02:38] <wgrant> StevenK: Is this unique_name or name?
[02:39] <StevenK> The former
[02:39] <wgrant> Which is rare
[02:39] <wgrant> though most of the length will be in name too, see how it performs
[02:39] <StevenK> That index is just creating now
[02:42] <StevenK> TRGM for name is 300ms
[02:42] <wgrant> Reasonable.
[02:43] <StevenK> I was expecting more on the order of 100
[02:43] <StevenK> Not 300 or 400
[02:43] <wgrant> Not with a long large GIN index
[02:44] <StevenK> What's the \d magic to see the index size?
[02:44] <wgrant> \di+
[02:45] <StevenK> Holy crap, they're 200MiB all up
[02:47] <StevenK> wgrant: So, push the changes for this branch, and create a new branch for two shiny TRGMs?
[02:48] <wgrant> I think so
[03:14]  * StevenK stabs the branch scanner and reaches for carob
[03:33] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/branch-trgm-indicies/+merge/148082
[03:33] <StevenK> wgrant: And new-branch-search is updated
[08:59] <adeuring> good morning


[06:12] <alkisg> cascardo: sure, it's just disappointing when I file a bug report in launchpad, then I get asked for feedback "is this still happenning on 10.10 or should we close it? On 11.04? On 11.10? On 12.04?", and that's all there is to it, time spent to maintain bug reports when it could instead be spent on reporting them upstream
[06:12] <alkisg> IMHO upstream bugs should first be solved upstream, and then launchpad bugs should be filed when we need a backport
[06:13] <alkisg> Time is precious and if wasted inefficiently, people won't be willling to spent more time on that in the future...
[06:15] <alkisg> (and let's not kid ourselves, in the launchpad bug tracker, 9 out of 10 bugs are not handled by the package maintainers, they're just noice that should be directed upstream instead)
[06:15] <alkisg> A whole lot of wasted resources there