Meeting Minutes: November 10, 2013

Annoucements

m_conley: Now’s about the time when you should be battening down the hatches and trying to get your patches out of WIP. At least, beginning that process. You still have ~1 month remaining. but that time flies by. It’s more like 3 weeks, anyhow. We’ve been saying this week after week, but it’s worth saying again. If any of you are worried, are stuck, or otherwise feel like you’re really on the wrong track – please come talk to us.

ChipX86:  Given where we are, it’s best to start getting as much done as possible, getting WIP requests out frequently. If you have anything you haven’t posted yet, put out one today, and put in the description what’s done and what needs to be done still, so we know where you are. There’s only a few weekly meetings left.

Round Robin:

endee

There has been some performance issues with queries. There are some Django tools that help identify slow or sub-optimal queries. django-debug-toolbar is a good one.

Tweek

[how do you feel about your projects progress? Any lingering questions or issues?]
-Overall I feel like I’m a little behind (like I could have had more done up to this point) but after getting the basics down for the file uploading test, I’m not concerned about moving forward. Like it was a lot easier than I thought it would be + took a lot less time.

[do you feel the code is at a point where, as it is, it could be checked in (after a round of reviews)?]
-I think it would probably need a couple hours of polish before I’d want to check it in. Just to move it from “This is sort of working” to “This would be scaleable”

[also, not to get you off track from your project, but there was an EasyFix you’d assigned yourself]
-I’ll get that done tomorrow as well.

-In terms of uploading/DLing a file right now I’m not sure where I can find the address of the current server I’m on?
There’s a Site object that has it. If you grep for Site.objects.get_current() and ‘domain’, you’ll find it. We have to build these URLs in other places as well. Here is how Review Bot does it: https:/githubcom/reviewboard/ReviewBot/blob/master/extension/reviewbotext/extension.py#L105

elaineM

[You’re tackling creating a WebAPI resource – pretty intense stuff, isn’t it? Lots of documentation in that WebAPIResource thing to wrap your head around]
-It is, like I think I lagged behind a week or so, just because it’s such a beast. I thought I was going to get the API stuff done this weekend.

(ChipX86 On WebAPIResource)
List resources are things like a list of review requests, and item resources are like a single review request.
item_child_resources and list_child_resources build that tree.
item_child_resources are child nodes of the items that the WebAPIResource represents.
list_child_resources are the child nodes of the list itself.
So, review-requests has a list of reviews as a child.

purple_cow: (it’s maybe worth pointing out at this point that a WebAPIResource often provides both the list and the item implementation in one class).

To make that happen, we put ReviewResource in ReviewRequestResource.item_child_resources.
Very rarely does a list have specific children, so mostly you care about item_child_resources. You may not even need them for your implementation.

If a Checklist doesn’t have any child resources, you can ignore these when you set Extension.resources, we basically take that and turn it into an item_child_resources on your extension’s own resource, which is how you get that link.

The tree is built up of links. We also use those relationships to build the URLs.
Since WebAPIResources know how to construct URLs by themselves, you don’t need URLHook.
URLHook is a way to tell Review Board that you’re creating an arbitrary URL somewhere

-What kind of testing do you guys expect to see from this extension?
given where we are, I’m not expecting a full unit test suite, but if you can write some unit tests, that’s always good

edwlee

-I’ve started working on a new search implementation using Haystack with Whoosh. I have a basic, working proptype that indexes Review Requests on a couple of fields. I’d like to try the current search to get an idea of how to proceed with the prototype, but I don’t have PyLucene configured. I’d like to try it in a vm instead of configuring PyLucene on my current env. Does our vm have it configured?
No. But messing with all that inside a linux VM could be easier than on your OSX box anyways

[so, what exactly are you looking for now? a list of things to index?]
-Yes, that and how search is used from the user’s perspective

Doc on full text search: http://www.reviewboard.org/docs/manual/dev/users/searching/full-text-search/

-I’ve left this issue open: https://reviews.reviewboard.org/r/4902/#comment12667. I’ve tested it and it seems okay. Just wondering if it can be closed or if i should do some more testing.
ok, if that’s the case, great / sounds like it can be dropped

classy_baboon

-I feel like im a bit behind. I have some code for which i need to post a review request. my unit test still isn’t working and i’m not sure why, i’ll investigate that more. when i get that going, a review request would create a possible trophy and assign it to the review request, user and local site. it is all hard coded though. i’m not sure what my next step should be. should it be to 1) connect it to UI, 2) to make it so that all the review requests of someone are checked when their profile is visited, 3) to make it abstract so that it will work with extensions or 4) something else?

[what do you mean by “it is all hard coded though”?]
-well, it is calculating for milestone and palindrome, but as ChipX86 pointed out, we want to get rid of that eventually, and have extensions dictate the trophy types and their logic

[…that really should be 15 minutes of work though. It’s mostly copy/paste from the other parts of the codebase I pointed out. This extendable pattern is very common in Review Board. This is a very core part of what we want from the new trophy implementation.]
-i’ll do it just as soon as the unit tests pass so that i’m sure everything is fine

-Since rbt post takes an -r argument for the review request to which this commit will be added onto as a diff, would that be “rbt post -g -r <id>”?
You can leave off the -g unless you’ve changed your description

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s