ChangeLog: New Integrations, Releases, and Prep for RBCommons 3.0

We’ve had a really busy couple of weeks since the last ChangeLog. There were two Review Board releases, a small setback with RB-Gateway, and lots of testing and infrastructure work for RBCommons 3.0.

Review Board 3.0.4 and 3.0.5

Last week, we put out Review Board 3.0.4, a feature-packed release introducing:

It was a pretty great release, fulfilling a lot of feature requests we’ve had for a while an providing the foundation for some new work we’re doing. Unfortunately, there was a last-minute error that, in production, broke part of the form for repository configuration.

Really embarrassing.

Now, we’ve found most people don’t upgrade the same day that a release goes out (downtime must be scheduled, people are busy, etc.) so we mostly started hearing about it two days later. As soon as we realized the mistake, we quickly got a new release out, Review Board 3.0.5, and put some changes in place to help prevent this sort of last-minute problem from happening again.

The good news is that, in the meantime, we went through and fixed a bunch of bugs that didn’t make the 3.0.4 release, but were ready for 3.0.5. So really, we’re just hoping we can all pretend 3.0.4 was just a pre-release for 3.0.5 now 🙂

Review Board 3.0.6 is currently scheduled for April 10th. I’m expecting it to go smoothly.

RB-Gateway Difficulties and Delays

RB-Gateway, our API wrapper around Git and Mercurial repositories, was supposed to release, well, today. Sadly, that’s not happening.

Let me back up. RB-Gateway is written in Go, unlike most of our projects which are Python-based. Go was chosen partly due to concurrency benefits for handling and serving up requests, and partly for its ease of cross-compilation and distribution (just drop it into a directory and run it on any supported platform).

It’s the cross-compilation that posed a problem. We use git2go, a Go wrapper around libgit2, a C library for talking to Git repositories. We don’t need a lot from it, but it made sense to “go” with that (sorry).

Problem is, including a C library makes cross-compilation much harder, and there’s threads full of discussions on issues with compiling and utilizing git2go in production, depending on how it’s compiled and used. So we’re planning to remove git2go usage.

Instead, we’re evaluating other Git libraries. We probably won’t roll our own, but as we don’t really need much from a Go library, we’ll “go” that route if we need to (sorry).

When that’s done, we should be ready to release.

Prep for RBCommons 3.0

This Friday, we’re beginning an upgrade of RBCommons, bringing many of the features of Review Board 3.0 to the service. We’ve spent much of this week getting this ready — rebuilding servers, testing database migrations, running through checklists of manual feature tests, etc.

There’s going to be a lot to love in this release, but those following Review Board development will surely notice that some features (such as Slack, Asana, etc. integrations) will not be there on launch. We have just a bit more work to do before those are ready. We want those as much as anybody, so they’re high up on the priority list.

The blocker right now is that the administration pages for some of these features are built to plug into the Django administration page, not the custom RBCommons team administration page. So there’s still some work to do before that’s complete. Soon, though!

The upgrade should be smooth, and we should be back up in only a few hours, but just in case, we’re leaving the maintenance window open through Sunday. We aimed for a holiday weekend (well, holiday for a lot of people, anyway) to reduce the impact on users.

Read More

A new stopwatch extension for Review Board

In any business setting, it’s nice to measure as many data points as possible in order to optimize processes. One common request we’ve had over the years has been the ability to know how much time people are spending on code reviews. This can be used to identify problems on both ends of the spectrum. If people are knocking out reviews in just a few seconds, they’re probably not giving the code the attention it needs to find the defects. Likewise, if code reviews are eating up too much time, it can point to problems of accumulated technical debt or the need for training or mentoring.

Stopwatch Extension

We’re working on a new extension that adds a “stopwatch” to the bottom-right of a review request. This can be toggled on and off, and the total time will be recorded in the review. This data is also available in the API for use by external tools, and we’ll be adding some nice reporting of this data to Power Pack.

Stopwatch Extension - Review header

Read More

Extensions can now reference static assets from Djblets/Review Board

I’ve made some fixes to the extension packaging today that allow stylesheets in an extension to reference assets (images, fonts, other stylesheets) found in Review Board or Djblets. This wasn’t working before, due to some assumptions Django makes when it comes to post-processing and packaging of static files.

Django allows you to define a list of static namespaces with a given name, and any static path starting with that name is looked up in that resource. So, djblets/images/<blah> or rb/fonts/<blah>.

Works great in templates and everywhere else, except for static file packaging. There, the assumption appears to be that any referenced resources live in the same app. The paths built are always relative to the directory or the top of the static namespace, making it impossible to do the kind of references an extension author would want.

Well, almost impossible. I pretty much beat that into submission. And here it is: https://reviews.reviewboard.org/r/7437/

Read More