Meeting Minutes for September 23rd


  1. Upgraded our version of jQuery: so keep your eyes out for weird behaviour in ReviewBoard over the next few days. (Please report bugs!)
  2. Added a more specific list of automated static analysis projects to the ideas page. So if you were interested in that project, you should check it out.
  3. Making good progress on the basics for pluggable UIs, so we’ll try to get that in before anyone begins their work on it.

Project Assignments:

  • aam1r: Pluggable UI*
  • michee: Pluggable UI*
  • slchen: Thumbnail Renderers (Pluggable UI* + Inline File Attachment)
  • yangtina: Inline File Attachments
  • Allyshia: Automated Static Analysis**
  • tahnok: Automated Static Analysis** / ReviewBot
  • jzamb: Fewer Page Reloads
  • johns187: RBTools / Client Scripts
  • Karl-L: SSH Key Association

* Pluggable UI will be broken down into the individual file types: e.g. plaintext, XML, etc. We’ll assign one for each Pluggable UI student.

** The static analysis: look at the subprojects that smacleod posted, and talk with him about which ones you want to do.

Questions / Answers / Tips:

Tip: We typically don’t go around more than once unless it’s really necessary. If you have questions, you should ask them on your turn.

Tip: Typing out questions in advance during Q&A helps keep things going.

Q: How to: write minutes for meetings?
A: After the meeting:
– Look at the log
– Write up the salient points
– Boil it down
– Examples:

Q: Is the thumbnail renderer’s description listed somewhere? or is that a pluggable UI?
A: We have two classes. One defines a review UI, which handles rendering a page and loading in comments and such. Another defines a renderer for a file type to provide a thumbnail. It’s related, but it’s its own class.

Q: Do we have pluggable UI for any file type at the moment?
A: One for screenshots is up for review, one for images (as file attachments — replacing our screenshot-specific support) will be up soon.

Q: Are we assigning pluggable UIs now or at the sprint?
A: We need to figure out which make sense first. There are some we know we probably want, like plaintext, XML, .doc. For now, you guys can look at the reviews and get a feel for the architecture, get a sense of what is being done, and how – both server-side and client-side:
– Come to us for questions
– We’ll determine your file types and give them to you soon

Q: I may have found a bug and mentioned it in IRC last night, how I should I go about reporting / assigning the bug? Do we use google code review for that and for code submission reviews?
A: Bug reports should go on google code, but talk to us first:
– Use for code review
– Only use Google Code for the wiki (sometimes) + the bug tracker.

Q: Where can we find more information about the project to which we are assigned?
A: Talk to us about it. There’s no docs anywhere. This is all bleeding edge!

Q: Every time we sync from upstream, do we have to go through all of the installations again for djblets / reviewboard / rbtools?
A: You shouldn’t have to do any installations in general on those.

Q: Overview of the the code review process at RB?
A: Starting with your git clone:
– Create a feature branch, and work on your bug / project. You commit to that branch, merging in updates from master periodically
– Then, when you’ve got something you’d like people to look at (it doesn’t have to be done – review early, review often), use post-review to toss it up on RB
– Bug us to look at it. We give you feedback, you make corrections / revisions
– Eventually, we give it a Ship It, we take your patch, and commit it to master.
– If it’s not done, though, say so in the description and say what’s left
– If possible, break your project up into distinct parts that can go in individualyl without breaking things (Smaller, atomic review requests are good, if they can be managed).

Q: So as long as the patch doesn’t break existing functionality for other people, we can submit patches for a feature that’s still incomplete, as long as the remaining items are listed?
A: Your patch, when landed *might* break other people’s. That’s sort of the challenge though – have to watch the tree, and get a sense of what people are working on. If you think you and another person are touching the same code, coordinate. In some occasions, we may just commit to a branch and not master for such projects (Someone else [i.e. a mentor] would create a branch on the main repo, if necessary – but you’ll never need us to).

Q: What was meant by: “Someone else would create a branch for me on the main repo, if necessary – but you’ll never need us to?”
A: You can do all your work for your project on your own branches. There’s nothing you *need* upstream, branch-wise. What was meant was that: if you’re working on a large project, and getting pieces of it in, we may decide not to commit anything to master until it’s all done; but we may decide to put it in a branch, just to make sure we don’t lose track of that work

Q: How do we host ReviewBoard on our local machine so we can test our code changes. Any guidance/docs that I can go to?
A: Getting Started guide should cover that. You want to run the ./contrib/internal/ script (see

Tip: You should all be able to access your local instances of Review Board and tinker with them. We want you to be able to do that before you reach the sprint. If you still need help getting that set up, please let us know, and we’ll dive in and help.

Q: The static analysis project “Implement manual triggering of Review Bot Tools” : is it purely a UI project? I understand that adding analysis tools is part of another project, so is this project really just adding an interface for manual trigger?
A: Mostly an interface. It might involve some other more backend stuff, but that is secondary (like adding places you can hit with ajax to trigger a review). It adds the UI to support manually triggering the analysis, and the corresponding backend.

Q: I am confused on how bouncers work. when I disconnect from IRC, the bouncer puts me as away. but when I come back, I don’t see any of the conversation that I have missed. Is it supposed to be like that?
A: Nope it is not. We’ll troubleshoot this after the meeting. Speak to ChipX86 regarding this if you still have issues.

Q: Fork and branch, same meaning?
A: Not exactly. Fork is an independent clone of an entire repository. Your local clone is a “fork”. (Also see

Tip: If your project is still fuzzy and you don’t know how to tackle it, ask us for more information. And working on EasyFix bugs is a great way to get warmed up to the code.

Leave a Reply

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

You are commenting using your 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