(Sorry for the big delay in posting this!)
Hey everybody! We’re just over half-way through November! Your other courses are probably starting to wrap up, and other final assignments are starting to approach their due dates. Keep your eye on the ball, keep your eye on the calendar, and really work to get your stuff out of WIP.
Also a reminder that we like to do a Google Hangout session at the end of the term so we can demo our projects to each other. It’s not mandatory but it’s fun.
I think I can get a non-WIP request up tonight or tomorrow. I’m just finishing up with bridging the back-end with a few of the functionalities of the checklist. WebAPIResources are more or less cleared up. And thanks to ChipX86. He’s been really patient with me.
Just wanted to open by thanking purple_cow for the thorough review! Gives me lots to work on.
How exactly would I format an htaccess file in terms of testing its execution? I’ve tried to look up examples of htaccess files but am not sure what’s needed.
Turns out we don’t actually need to test htaccess files.
Are there any other filetypes in particular that I should be checking?
.pl, .py, .rb, .cgi, variants on those. Look at reviewboard/cmdline/conf/apache-wsgi.conf.in
purple_cow mentioned that since i am adding the extra_data field to ReviewRequest, I have to make an evolution for it. Is that just running ./reviewboard/manage.py syncdb and ./reviewboard/manage.py evolve –hint –execute?
Never run –hint –execute under any circumstances. It might blow up your computer. http://www.reviewboard.org/docs/codebase/dev/tasks/database-evolutions/ once you create the evolution file, add it to your patch.
purple_cow also mentioned that we should have a discussion of how this field will work with drafts.
Maybe we can make the draft one be a special kind of dict that keeps track of operations. Or the draft one can be blank at first, and its contents are copied over, so extensions/API just need to choose which they really want to be operating on.
Is there a preference for how I should have suggestions display?
I think adding some vertical spacing would help a lot. No bold necessary there. Maybe cahnge its style to not be bold and see how that looks.
If I fix an issue but don’t put up a new review request with the fixes should I be marking the issue as fixed or waiting till I put up the change?
I tend to mark mine as fixed as I fix them, so I don’t forget. It also lets us see your progress before a change is actually put up.
I made a very small change in djblets, I’m guessing I’d need to make a whole different review request for that despite it being connected to the same change?
I’m having trouble finding a more powerful and suitable query parser to replace Haystack’s simple query parser with.
imho, having Haystack + the simple parser is fine for now, since most people don’t even have search at all and don’t know about the complex query syntax.
http://pyparsing.wikispaces.com/ <- looks interesting