Meeting Minutes for May 27th, 2012

This was our first official meeting for GSoC! We’re pleased to welcome Bogdana Popa to the project, and welcome back Steven MacLeod.

The nature of their projects will be made more apparent in future blogposts from the both of them.

• A general announcement – there’s a big change going on in the codebase right now; RB is changing its model a bit to have a core concept of hosting services and accounts (with things like API token storage) for those services.
  • This is in response to GitHub changing their API (which we require for fetching files from GitHub to show diffs) in a way that’s incompatible with what we have today
  • Reviews are the key thing to help with this. Testing wouldn’t hurt either if you wanted to spend the time.
  • A final patch should be up this week.
  • These changes will likely have an impact on Steven’s project, since they will give us the ability to start doing things like better DVCS integration with these services, which will affect the API and what tools we’ll need.
• From Bogdana
  • Just came back from a holiday in Japan, and ready to tear into her project.
  • Have started coming up with solutions for the activity feed
  • Stumbled on a Django App that we might want to incorporate, or at the very least, emulate.
    • We need to study this – we’ve been broken by third-party things before…
  • Has started a rough implementation of the action feed with the app – patch should be up for perusal sometime this week.
    • This sort of thing is good fodder for the blog!
  • Q: My proposition was to add an activity feed as a Dashboard entry, but it doesn’t seem like it fits in there since the other entries are based on the datagrid.
    • A: That’s true, but they don’thave to be based on the datagrid.
    • Depending on the entry, it actually branches off into different views (all datagrids, but only because that’s what we’ve been showing so far)
  • Q: Should I leave the activity feed in the Dashboard and try to get around the datagrids, or should we introduce it as a separate menu item?
    • A: Leave it in the Dashboard, and make it the top entry
    • The view would basically be doing “if view_name == ‘activity’: return activity_view()
  • Q: When upgrading to this feature, should we also populate the activity feed with events from the past?
    • A: No, let’s only do it for new things.
• From Steven
  • Working through the asynchronous stuff for the API.
  • Still trying to figure out how asynchronous stuff works in Python
  • Q: Asynchronous implies multi-threaded?
    • A: Not necessarily, no. It can be done many ways, in response to events, in a mainloop, multi-process…
  • Q: What should I use for urllib2? Threads?
    • A: Ignore threads for now. Design for async usage without making it async yet.
    • We’ll likely end up providing something like a gevent backend for the data transfer, which will do our async stuff.
    • You should be able to design a proper async API without having to have an async backend yet.
  • There are some outstanding review requests from last semester still waiting for review!
    • Let’s not forget about ReviewBot, people.
• Bogdana also has some review requests up there. Let’s clear those out.
• Contact ChipX86 if you want an IRC bouncer (irssi running on ChipX86′s server)
  • ZNC is another pretty painless solution.

Who’s Doing What (Winter 2012 Term)

So each student on the team has a few extra responsibilities this semester.  In particular, a student will be responsible each week for collecting / hounding down status reports and posting them on this blog before the weekly IRC meeting.  Another student will be responsible each week for taking the meeting transcripts and turning them into nice, summarized posts which will also be posted here.

Here is an example of a status report post – notice how short and punchy each status report is.  They get right to the point:  Status, Next Steps, Roadblocks.  Point form is fine.  Again, these should be collected and posted, and then read by the team before the IRC meeting.  This way, we’re all more or less on the same page when the meeting begins.

And here is an example of an IRC log summary.  Again, point form is fine.

So, here’s the schedule – please note that it might be subject to change, so check back often.

January 28th – status reports: Jim, minutes: Curtis
UCOSP Blog Post (Due January 30th) - Anthony

February 4th – status reports: Wei Lu, minutes: Jim
February 11th – status reports: David, minutes: Wei Lu

UCOSP Blog Post (Due February 13th) – Curtis

February 18th – status reports: Wilson, minutes: David
February 25th – status reports: Steven,  minutes: Wilson

UCOSP Blog Post (Due February 27th) – Jim

March 3rd – status reports: Anthony, minutes: Steven,
March 10th – status reports: Yazan, minutes: Anthony

UCOSP Blog Post (Due March 12th) – Wei Lu

March 17th – status reports: Curtis, minutes: Yazan
March 24th – status reports: Jim, minutes: Curtis

UCOSP Blog Post (Due March 26th) – Steven

March 31st – status reports: Wei Lu, minutes: Wilson
April 7th – status reports: Anthony, minutes: Steven

UCOSP Blog Post (Due April 9th) – Wilson

Post-mortem (date TBA) – notes: Mike

Team:  I highly recommend bookmarking this post, and marking your days down in a calendar somewhere.

Polishing the Student Experience

After every semester of UCOSP or GSoC, the Review Board team has a post-mortem.  The post-mortem is an opportunity for students to give us mentors some feedback on:

1. What worked and what didn’t work
2. What we should do more of, and what we should do less of
3. What we need, and what we can do without
4. What things we should provide, and what unnecessary things we can trim back

Here’s some of the things we learned last semester:

We’ve got some decent set up documentation

The instructions for setting up the development environment are well written – students were able to get set up really quickly, and hit the ground running.

Git is a major stumbling block for students

Students are coming at us with varying levels of knowledge regarding version control systems – let alone distributed version control systems.  We really need to make sure they have a solid foundation in Git, or else it’ll bite them later on in the semester when their trees get more complicated.

So it’s not good enough to just show them how to clone a repository, make some changes, and commit them.  Students need to know how to recover from easy mistakes.  They need to know how to think about how their branches relate, what a tracking branch is, and what rebase-ing does.

They need to know how to use Github to set up a fork, and why that’s useful.  They need to know tricks like stashing changes,

We should probably be more visual, and can probably help this by introducing gitx / gitk earlier on, to make it easier for students to understand the relationship between their branches.

And then, on top of all of this, we need to explain how Review Board developers are expected to use Git, and how post-review works in tandem with Git.

On Editors

Some students are coming at us having only used full-blown IDEs to do development.  It might be worth-while to try to help the student set up their IDE to hack on Review Board, as opposed to forcing a student to adopt a foreign editor along with a foreign codebase.

IRC

Distributed development hinges on communication.  IRC is a very important tool in this arsenal, and we cannot assume that students are familiar with it right off the bat.  We need to be able to get students up and running on IRC quickly.

We need to be strict on posting status reports

There were a few instances last semester where status reports were posted after a meeting had started.  This is no good, because then we have to waste time at the beginning of the meeting getting caught up on everyone’s progress, as opposed to immediately diving into blockers.

We started getting more strict on that in the second half of the semester, and we’re going to be quite vigilant from here on in.

The blog is good for some things, but we might want to invest in a Wiki

Students have expressed that the blog is uncomfortable and clumsy for things like writing development notes, and for keeping track of progress on things.  Something like a Wiki might be better suited for such things.  We use Google Code to host the Review Board issue tracker – we might want to investigate giving our students access to the built-in Wiki.

Students need examples of good meeting minutes and status reports

We need to show students acceptable examples of both minutes and status reports, so that they have a target to aim for.

We need to map out the layers of Review Board

Review Board is a pile of technologies:  Python, Django, Djblets, jQuery, HTML and CSS.  We need to map out for students how these technologies are used, and how they relate to one another.  We cannot assume that our students are proficient in any of these technologies.  We cannot assume that they know what a web framework is.  We cannot assume that they know how server side software generally operates.

Students are eager for review feedback, and we can’t let it slide

This has been a problem for a few semesters now, but sometimes review requests pile up, and the reviewers lose track of them.  We need to make sure students are periodically reminding us that they’re blocked on particular review requests.  They cannot be shy about this.

Who knows, maybe a student will automate a reminder system as part of Review Board itself.

So that’s the wisdom that we garnered from last semester’s students.  Thanks for the review!

Running Subsets of Review Board Tests

Have you been writing tests for Review Board?  If so, you’ll want to read this.  This is copy-paste from a super-useful e-mail that David Trowbridge sent out to the UCOSP mailing list:

Mark in our UCOSP group this semester had a question, and I think the answer would be handy to many of you who want to use our test suite. Specifically, because the suite takes several minutes to run, is there a way to run a subset of the tests?

We use a test runner called “nose”. Presumably when you were running through the initial development instructions, you installed this package. It supports a lot of special arguments for limiting test cases and other functionality, but any arguments you want to pass to it have to come after a “–” argument to manage.py test.

To run only the tests in a specific module:

./reviewboard/manage.py test -- reviewboard.scmtools.tests

To run the tests in a specific class:

./reviewboard/manage.py test -- reviewboard.scmtools.tests:GitTests

And finally, if you want to run only a specific test case:

./reviewboard/manage.py test -- reviewboard.scmtools.tests:GitTests.testFilemodeWithFollowingDiff

Some other flags which come in handy are -x, –pdb and –pdb-failures.

This will stop the test runner after the first encountered failure.

./reviewboard/manage.py test -- -x

This will drop into pdb (the python debugger shell) when an error occurs. In django test parlance, errors are problems that aren’t “test failures” per se — things like uncaught exceptions.

./reviewboard/manage.py test -- --pdb

Similarly, –pdb-failures will drop into pdb when a test case assertion fails.

Hope this help cut down your turnaround time!

Who is doing what for Fall 2011?

So each student on the team has a few extra responsibilities this semester.  In particular, a student will be responsible each week for collecting / hounding down status reports and posting them on this blog before the weekly IRC meeting.  Another student will be responsible each week for taking the meeting transcripts and turning them into nice, summarized posts which will also be posted here.

Here is an example of a status report post – notice how short and punchy each status report is.  They get right to the point:  Status, Next Steps, Roadblocks.  Point form is fine.  Again, these should be collected and posted, and then read by the team before the IRC meeting.  This way, we’re all more or less on the same page when the meeting begins.

And here is an example of an IRC log summary.  Again, point form is fine.

So, here’s the schedule – please note that it might be subject to change, so check back often.

September 18th – minutes: Yazan, status reports: Waleed
September 25th – minutes: Waleed, status reports: Jacob

UCOSP Blog Post (sent to reviewboard-ucosp before October 2nd):  Waleed

October 2nd – minutes: Jacob, status reports: David
October 9th – minutes: David, status reports: Yazan

UCOSP Blog Post (sent to reviewboard-ucosp before October 16th):  David

October 16th – minutes: Yazan, status reports: Waleed
October 23rd – minutes: Waleed, status reports: Jacob

UCOSP Blog Post (sent to reviewboard-ucosp before October 30th):  Yazan

October 30th – minutes: Jacob, status reports: David
November 6th – minutes: David, status reports: Yazan

UCOSP Blog Post (sent to reviewboard-ucosp before November 13th): Jacob

November 13th – minutes: Yazan, status reports: Waleed
November 20th – minutes: Waleed, status reports: Jacob
November 27th – minutes: Jacob, status reports: David
December 4th – minutes: David, status reports: Yazan
Post mortem date TBD – minutes / status reports:  Mike

Team:  I highly recommend bookmarking this post, and marking your days down in a calendar somewhere.

An Introduction to Git

The new Review Board UCOSP team just had its first IRC meeting (minutes forthcoming).  A ton of learning has already taken place — Christian Hammond (ChipX86) and David Trowbridge (purple_cow) were generous enough to stick around after the meeting to give an introduction to Git.

The following is a transcript of that introduction from our IRC meeting.

<ChipX86>    so, git is a bit different than what you’re probably used to. It’s a DVCS — distributed version control system

*    markstrmr has quit (Ping timeout: 276 seconds)

<ChipX86>    a Git checkout stores the entire history of the repository

<ChipX86>    where this is useful is that you don’t need a central server for your sourcecode. Anyone who has a checkout can work with anyone else with a checkout

<ChipX86>    this is done by way of “remotes.” A git repository can be linked up to ther repositories by specifying a “remote” to their repository

<ChipX86>    you’ll be dealing with two remotes:

<ChipX86>    origin (our reviewboard git repo) and your own (usually designated by your github username)

<ChipX86>    so your first step will be to check out the repository

<ChipX86>    you’ll want to pick a place for the sourcecode and do:

<ChipX86>    git clone git://github.com/reviewboard/reviewboard.git

<ChipX86>    then, once you’ve “forked” our repository (go to https://github.com/reviewboard/reviewboard/ and click Fork near the top right), you can add it with:

<ChipX86>    git remote add yourusername git@github.com:yourusername/reviewboard.git

<ChipX86>    you’ve probably done the initial checkout at this point, given that you’ve hit setup issues, but just to go over it..

*    markstrmr (~mstriemer@wnpgmb1154w-ds01-92-212.dynamic.mts.net) has joined #reviewboard-students

<ChipX86>    now, any development you do should be done on “topic branches.” A branch in git is a very light-weight thing. It just gives a name to a set of commits. You can easily switch back and forth between branches.

<ChipX86>    “master” is the main branch. It will contain the commits made upstream, which you’ll need to sync every so often (more on this later)

<Mengyun>    question

<ChipX86>    sure

<Mengyun>    what’s the purpose of the 2nd step?

<ChipX86>    adding your own repo?

<Mengyun>    remote add…

<ChipX86>    the idea there is that any projects oyu’re working on will be occasionally “pushed” to your own fork of reviewboard

<Mengyun>    creat own repo as a fork of rb?

<ChipX86>    which is a way of backing things up

<ChipX86>    and also lets us see your code

<ChipX86>    since git is distributed, it’s common for people to have their own copy of a project somewhere with their own changes

<Mengyun>    oh i see thx!

<ChipX86>    we had a case last term where a harddrive failed

<ChipX86>    and much of the project was lost

<ChipX86>    if the code had been up on the github fork, there wouldn’t have been as much of a setback

<ChipX86>    I’ll go into pushing the code more in a bit

<ChipX86>    so, branches

<ChipX86>    when you’re doing work, you’ll want to create a new branch for that work

<ChipX86>    to do this: git checkout -b <branchname>

<ChipX86>    that creates the branch and switches to it

<ChipX86>    from there, go about your coding

<ChipX86>    when you want to commit, you can do: git commit -a, which will commit all modified files, prompting you for a change description

<ChipX86>    you can use `git add` to add any new files

<ChipX86>    sometimes you’ll want to be more specific

<ChipX86>    you may have 10 files modified, but you only want to commit 2

<ChipX86>    in that case, do `git add` on the files you want to commit, and then `git commit`

<ChipX86>    one thing that git is really good at is staying organized

<ChipX86>    you’ll want to develop a habit of trying to keep your commit history clean

*    markstrmr (~mstriemer@wnpgmb1154w-ds01-92-212.dynamic.mts.net) has left #reviewboard-students

<ChipX86>    there are a few ways to do this

*    Mark_ (~markstrmr@wnpgmb1154w-ds01-92-212.dynamic.mts.net) has joined #reviewboard-students

*    Mark_ (~markstrmr@wnpgmb1154w-ds01-92-212.dynamic.mts.net) has left #reviewboard-students

<ChipX86>    `git add` has this awesome parameter, `-p`, which will allow oyu to stage only certain parts of your change for committing

*    markstrmr_ (~markstrmr@wnpgmb1154w-ds01-92-212.dynamic.mts.net) has joined #reviewboard-students

<ChipX86>    useful for leaving out, say, debug output

<ChipX86>    if you’ve committed a bunch of changes that you want to clean up, oyu can do: git rebase -i master

<m_conley>    back

<ChipX86>    that will present the commit history between the master branch and the tip of your branch

<ChipX86>    you’ll be able to delete commits, squash them together, rearrange them, change the descriptions, etc.

<ChipX86>    powerful feature. Worth playing with with some test commits.

<ChipX86>    a good goal is to squash commits together often and have one commit per logical change

<ChipX86>    as an example:

<ChipX86>    say I’ve made 5 commits while trying to get something to work

<ChipX86>    commits 2, 3 and 4 are really the same effective change, but I’ve tried a few ways of doing it before settling on it, and I don’t want all that history around forever because it’s hacky or something

<ChipX86>    I can do:

<ChipX86>    git rebase -i master

<ChipX86>    scroll down to commits 3 and 4 and change the action from “pick” (which means to just keep that commit) to “squash” (which means to squash it into the previous commit)

<ChipX86>    when I save and close, it’ll squash those commits into one commit, let me edit the change description, and then save the new history

<ChipX86>    that’s one option for git rebase. rebase is typically used to take a branch of commits and move it onto another branch. Such as when you update the master branch and want to make all oyur changes up to date

<ChipX86>    the thing is, you only want to use rebase if you haven’t yet pushed those changes to your own github

<ChipX86>    if you have done that, you’ll instead want to use `git merge master`

<ChipX86>    the reason is that rebase actually creates new commits and deletes the old ones, which will mess up your history on your github. `git merge` will instead keep those commits and create a new one with the merge.

<ChipX86>    that can be kind of confusing, so if you have quesitons I’d be happy to answer them

<Steve_Sutcliffe>    so git merge master will do the same thing as rebase?

<ChipX86>    they’ll both have the same end result of making your branch up-to-date

<ChipX86>    but the way they do it is different

<ChipX86>    every commit has an identifier, a SHA1

<ChipX86>    if you use rebase, the commits all get new SHA1s

<ChipX86>    if someone else is using your github fork, and you rebase something that’s on there, they won’t be on your set of commits anymore. Those commits will have moved.

<ChipX86>    if you instead use merge, the commits retain their SHA1s. A new commit is then made with the merge.

<ChipX86>    so, rule of thumb: use rebase to clean things up, *before* those commits are pushed to your github. Use merge after.

<ChipX86>    that also means it’s important to organize your commits prior to pushing

<ChipX86>    once you push, you can’t really go back

<ChipX86>    so, pushing and pulling

<ChipX86>    you’re going to want to periodically update your master branch with any upstream changes

<ChipX86>    quickest way to do that is to check out the master branch, and type: git pull origin master

<ChipX86>    which pulls the master changes from the “origin” remote (our project’s github)

<ChipX86>    when you want to push to your own repository, be on that branch (git checkout <branchname>) and push with: git push <yourusername> <branchname>

<ChipX86>    the <branchname> is only needed the first time

<ChipX86>    after that, just: git push <yourusername>

<ChipX86>    (the first time, it’ll create that branch on your github, and subsequent “push <yourusername>” will push all branches that your github knows about)

<ChipX86>    questions?

<m_conley>    the more you use Git, the easier it gets.  So I recommend practice, practice, practice.

<ChipX86>    yeah

<ChipX86>    you can create branches and just play with them, and then delete the branches

<ChipX86>    also, there’s tihs tool, gitk

<ChipX86>    (on MacOS X, download and install gitx instead)

<ChipX86>    gitk comes with git. Run it with: gitk –all

<ChipX86>    leave it up and running while you code

<ChipX86>    it will visually show your commit history

<ChipX86>    help you to visualize how these operations impact things

<m_conley>    Is everybody still OK out there?

<purple_cow>    one thing which I want to reemphasize is that you should leave “master” as a tracking branch for “origin/master” and only commit your own work onto other branches

<ChipX86>    yeah, good point

<m_conley>    Steve_Sutcliffe / Teresa / Mengyun / markstrmr_ / KAmlani / CrystalLokKoo:  all good?

<CrystalLokKoo>    for hte time bieng yes

<ChipX86>    I know I threw a lot at you

<CrystalLokKoo>    being*

<Steve_Sutcliffe>    I think so

<Mengyun>    i think so

<markstrmr_>    Sounds good

<ChipX86>    it’ll make more sense once you play with it. Just don’t commit to master and you won’t mess anything up

<Teresa>    I think so

<m_conley>    I’ll be putting what ChipX86 wrote up on the blog for reference

<ChipX86>    one more thing to go over

<ChipX86>    our post-review tool

<Mengyun>    is push a kind of commit?

<ChipX86>    push just takes your commits and puts them on a remote

<Steve_Sutcliffe>    when we do a push does that go to the main repository? or to that branch we created? or both?

<Steve_Sutcliffe>    (I mean the fork we created)

<ChipX86>    that’s where the <yourusername> part comes in. That’s the remote name. It’ll try to push to whatever origin you specify

<ChipX86>    I’d use: git push chipx86

<Teresa>    ok, so all of our commits are local until we push them?

<m_conley>    Teresa:  exactly.

<ChipX86>    nothing you do will impact the main reviewboard codebase

<purple_cow>    If you get confused and do something and it looks like your work is gone, don’t panic. Come here and we can usually figure out how to get it back.

<m_conley>    Yep.  In Git, it’s actually really difficult to lose everything.

<Steve_Sutcliffe>    those updates we do then, the pulls, that will only be from the main reviewboard codebase? Not from any work that any of us are doing?

<m_conley>    what’s more likely is that it’s all there.  And more.  And you need to disentangle it.

<ChipX86>    even if it looks like the commits are deleted

<m_conley>    Steve_Sutcliffe:  It depends.  If you’re working with a partner, you might want to pull in commits to their repository.

<Mengyun>    will this happen : i work with my fork but the main repo is updated during my work

<m_conley>    Steve_Sutcliffe:  but you’ll definitely want to pull from the reviewbaord codebase to keep up to date.

<purple_cow>    Steve_Sutcliffe: “git fetch” takes an argument for which remote you want to fetch (and also knows –all). Typically the only changes you’ll see are in the main codebase

<m_conley>    Mengyun:  definitely.

<Mengyun>    so what should i do then

<Steve_Sutcliffe>    ah I see

<m_conley>    Mengyun:  it’s your responsibility to keep your fork up to date.  On your machine, merge with reviewboard’s codebase, and then push to your fork.

<Mengyun>    how often do u recommend to do this update?

<ChipX86>    doesn’t have to be every day. Just as often as you need to.

<m_conley>    Mengyun:  well, every time you do a git pull origin master, if you notice some things have changed upstream, it’s a good idea to push them.

<ChipX86>    I tend to do it before I’m about to put somtehing up for review

<ChipX86>    you may have to resolve conflicts (wihch we’ll have to go over later)

Who is doing what for Winter 2011?

So each student on the team has a few extra responsibilities this semester.  In particular, a student will be responsible each week for collecting / hounding down status reports and posting them on this blog before the weekly IRC meeting.  Another student will be responsible each week for taking the meeting transcripts and turning them into nice, summarized posts which will also be posted here.

Here is an example of a status report post – notice how short and punchy each status report is.  They get right to the point:  Status, Next Steps, Roadblocks.  Point form is fine.  Again, these should be collected and posted, and then read by the team before the IRC meeting.  This way, we’re all more or less on the same page when the meeting begins.

And here is an example of an IRC log summary.  Again, point form is fine.

So, here’s the schedule:

• Jan 16:  minutes: Teresa
• Jan 23:  end-of-code-sprint status reports:  Steven
• Jan 30:  status reports: Mengyun, minutes: Crystal
• Feb 4:  UCOSP Blog post:  Mengyun
• Feb 6:  status reports: Crystal, minutes: Kahlil
• Feb 13:  status reports: Kahlil, minutes: Mark
• Feb 18: UCOSP Blog post: Steven
• Feb 20:  status reports: Mark, minutes: Teresa
• Feb 27:  status reports: Teresa, minutes: Steven
• Mar 4: UCOSP Blog post: Mark
• Mar 6:  status reports: Steven, minutes: Mengyun
• Mar 13:  status reports: Mengyun, minutes: Crystal
• Mar 18: UCOSP Blog post: Teresa
• Mar 20:  status reports: Crystal, minutes: Kahlil
• Mar 27:  status reports: Kahlil, minutes: Mark
• Apr 1: UCOSP Blog post: Crystal
• Apr 3:  status reports: Mark, minutes: Teresa
• Apr 8: UCOSP Blog post: Kahlil
• Screencast blog post:  Mengyun
• Post-mortem (date TBD) minutes:  Steven

Team:  I highly recommend bookmarking this post, and marking your days down in a calendar somewhere.

Meeting Minutes: Dec 5, 2010

• We’re on the home stretch!  Screencasts are going up this week!
• In general, the team seems to be feeling good / dandy / less-panicked
• Screencasts are going to be posted on YouTube.  Once you’ve recorded yours, either post them on YouTube yourself (you’ll need an account), or send them to Mike via a service like YouSendIt, and he’ll post it.  Please don’t e-mail him the videos as attachments.
• Once your video is up on YouTube, just embed it into a blog post, and you’re all set.
• Christian and David will be putting the videos up on reviewboard.org as well.
• Beanbag, Inc
  • Beanbag, Inc. was recently formed!  Beanbag, Inc is Christian / David’s start-up centered around Review Board-related development and services.
  • Beanbag, Inc does NOT change anything about Review Board with respect to it being free, open-source, etc.  If anything, Beanbag, Inc will foster open-source development on Review Board.
• Even though your projects are coming to a close, you can still contribute to Review Board!  It’s be awesome if you did.  Even if its just to polish up loose threads on your projects.
• Cleaning up Git history:
  • Once you’ve pushed to GitHub, those changes are staying there unless you wipe out the branch – so it’s good for things to be clean BEFORE you post to GitHub
  • Failing that, you can kill off the old branch (git push my_repo :<branch_name>) and recreate
  • The big tools for local history cleanup are “git rebase -i master” and “git commit –amend”
  • A trick there is to create a new temporary branch at the tip of your current branch, and it’ll act as a save point
  • It’s also nice to have one commit per conceptual change – and to merge bug fixes in with the change that introduced that code
  • Another tip:  ‘git add -p filename’ will allow you to choose only the pieces of your change for that file that you want to stage for commit, instead of the whole file
• Post-mortem
  • We’re meeting again next Sunday, same time as usual.  No status reports.  No meeting minutes.  We’re just going to talk about pluses and minuses about the course.
  • Also, after the course is done, each student should send Mike a quick e-mail talking about how they felt they did in the course.
• Continuing contributions to Review Board
  • Everybody is absolutely welcome to keep contributing to Review Board once the term is up!  It’s encouraged!
  • The reviewboard-ucosp list, however, should be deprecated in favour of the official reviewboard-dev and reviewboard mailing lists.

Status Reports – December 5, 2010

Laila

Status

• changed from depricated original webapi to the new 1.6 one on Christian’s suggestion
• file attachment is working (we are able to attach files) and the UI is reasonably good-looking
• file comments are not working but much of the code for them is done

Next steps

• improve code look (it’s a bit messy)
• get comments working
• improve UI of uploaded files (if necessary? I’ll post a picture)

Roadblocks

• there are some problems with the new webapi review draft code which are spilling over into my code. I’ve spoken to Christian about it
• some of those problems have been resolved but others have not
• I have a lot of other projects due monday and some have encountered catastrophe and stolen time this week

 

Lindsey

Status

• finished the graphical resource browser up enough to be usable
• fixed rb.py and rb<name>.py commands to be able to be run from anywhere

Next Steps

• clean commit history
• record the screen-cast with Brendan

Roadblocks

• none.

 

Brendan

Status

• finished rb-diff
• finished adjustments to serverinterface to allow for different mime-types
• fleshed out the settings, to allow comments, blank lines, ints, floats and bools
• found screencast software (screenr)

Next Steps

• finish up rb-patch (I’ve been busy, this should be finished tomorrow)
• record the screencast

Roadblocks

• none

 

Kevin

Status

• finished everything.  Waiting for more feedback on the user page

Next Steps

• upload screencast to youtube.  Perhaps one more blog

Roadblocks

• none

 

Lianne

Status

• got rid of errors. Now just trying to get the webhook to successfully call a script

Next Steps

• get this webhook working (hopefully tonight)
• record screencast (some time in the next couple of days)

Roadblocks

• none

 

Hongbin

Status

• polished the code I had
• prepared the screen cast

Next Steps

• screen cast

Roadblocks

• none

So, where are we?

If you’ve been following this blog, you’ll know that the team has been working very hard on their projects.  But I’ll bet those status reports can be a bit cryptic sometimes.

So here’s my take on where we are so far, in no particular order:

1. Hongbin has been working on an extension that will allow communication between Review Board and various bug-trackers.  Currently, his extension listens for events on Review Board (such as publishing a review request, publishing a review), and then alerts the appropriate issue/bug in the bug-tracker by posting a comment with a link to the review request.  Hongbin’s extension currently only works with Google Code projects, but will eventually be extended to other bug-trackers as well (Bugzilla, Github’s issue tracker, etc).
2. Laila has put together a new version of the Windows Review Board installer.  The installer is responsible for making sure a Windows machine has everything it needs in order to get an instance of Review Board up and running.  Laila is also working on a project that will allow review requests to have files attached to them.
3. Lindsey and Brendan have been putting together an impressive suite of client tools to interact with the new Review Board API.  The monolithic “post-review” script will, I believe, be eventually modified to use these scripts.  The scripts are also designed to be easily imported, so that developers can write their own tools to interact with Review Board.
4. Lianne has been working on an extension that will give Review Board WebHook notification abilities.  This means that, when various events happen on Review Board, the extension can send a request to a remote server to trigger another action.  Example:  when a review request has been marked as submitted, the Webhook might signal a script that publishes a notification to Twitter, or to an IRC bot, or to an RSS feed, etc.
5. Kevin has completed his “collapsible-reviews” project: for review requests with a long series of reviews/revisions, we can save on vertical screen real-estate by automatically collapsing the reviews that have been read.  Kevin has also implemented a one-click Ship-It function, which makes easy reviews even easier.  Kevin is now working on the designs for a new user profile page for Review Board.

I hope I didn’t forget anything.  Comment (or update this post) if I have.  Keep up the good work, team!