Plans for Review Board’s bug tracker

Many of you may have heard that Google Code is going read-only starting tomorrow, and some have asked us how this will affect the project, since we host our bug tracker there.

Not to worry. Google’s been nice enough to whitelist us for a little while, so even though most of Google Code will be down, we’ll continue to be up. This is not permanent, but for the time-being, you’ll still be able to report bugs at the old address.

Going forward, we’ll be migrating off of Google Code and onto a new tracker. That will happen in the coming weeks, and we’ll talk more about it when it happens.

So why the delay? Why did Google need to extend the shutdown date for us? We actually have something new on the way that we’re pretty excited about. We call it Splat, and while still very young, it’s shaping up to a pretty cool bug/issue tracker. We weren’t quite prepared to switch over to it by the shutdown date, but we have enough of it ready to launch pretty soon.

There’s a lot more that I’d like to say about Splat, but there will be time for that. We’ll make a more formal announcement soon.

Read More

Lots of UI cleanups in preparation for Review Board 2.5 RC 1

2.5 beta 2 looks to be working pretty well, and we’re working hard to get ready for RC 1. As part of this, we’ve fixed up a number of little UI issues here and there. For instance, login on mobile now works:

 

Mobile Login (Review Board 2.5)

 

As does registration and password resets.

Gravatars are now showing up more reliably in the dashboard. Depending on the settings on the server, these may have been hidden unintentionally. Basically, defaults weren’t being taken into consideration in some calls.

The user page now works properly on mobile, with filters moving to a little menu:

 

Mobile Dashboard (Review Board 2.5)

Mobile Dashboard with Filters (Review Board 2.5)

 

Also, some fixes for visual issues with text and Markdown file attachment review pages.

Read More

On-the-fly syntax highlighting when using Markdown

Review Board 2.0 introduced Markdown support for text fields, and we’ve been iterating on this since. One nice advantage to using Markdown is that it’s really easy to syntax-highlight a code fragment, like:

```python
def foo():
print "oh hi there"
```

When saving the comment, this would appear rendered with some syntax highlighting, same as the diff viewer.

In 2.5, we’re adding on-the-fly syntax highlighting for most popular languages: CoffeeScript, CSS, Go, HTML, JavaScript, Perl, PHP, Python, ReStructuredText, Ruby, Shell Scripts, SQL, XML, and YAML.

That means when you type code in a code block, like above, it will show the syntax highlighting immediately, without having to save.

Now, it’s not perfect. We use a different highlighting engine for rendered content vs. on-the-fly content, and they don’t 100% agree on how things should be styled, but it’s close enough.

We’re gaining this ability through an upgrade of CodeMirror, the widget we use for the text fields. We’re giving 5.5 a try (we previously tried upgrading to 4.2 and had issues, but so far so good with 5.5).

This will all ship with Review Board 2.5 RC 1.

Read More

A new polished issue summary table for review requests

Since Review Board 1.6, we’ve had a table of all open issues (comments that have a task that needs fixing before a change can go in), sitting right below the fields of a review request. This could be filtered by reviewer and by status type, showed summaries of the comments, the date/time the comment was filed or last updated, and the status type.

It was pretty text-heavy, though, and not easy to read at a glance. As such, most people probably ignored the nice filtering abilities and, really, most of the content.

So, I redesigned it.

Here’s how it looked before:

Old issue summary table

And here’s how it’ll look in Review Board 2.5 beta 2:

New issue summary table (Review Board 2.5)

New issue summary table (Review Board 2.5)

It’s even more mobile-friendly:

Mobile issue summary table (Review Board 2.5)

Users will get to use the new table later this week.

Read More

Using Review Board with Amazon CodeCommit

Today, Amazon released their all-new CodeCommit service as part of the Amazon Web Services family. CodeCommit is a Git repository hosting service built for scalability and reliability, helping to securely store encrypted versions of your code, binaries, and configuration related to your products and cloud infrastructure.

They’ve put together a guide on integrating AWS CodeCommit with Review Board that you can follow if you’re wanting to give this service a try. It’ll walk you through deploying a Review Board server, setting up access to CodeCommit, linking your repository, and posting changes for review.

Currently, setup requires maintaining an in-sync clone of your repository on the Review Board server. We’re aiming to work with the CodeCommit team to help bring direct support for hosted CodeCommit repositories to a future release of Review Board and RBCommons.

For more information on getting set up, check out the CodeCommit page and read our guides on configuring Git repositories and our recommended RBTools workflows for Git.

Read More

Some early design notes on Review Board API v3

We’re still working on wrapping up 2.5, and have plans for a small 2.6, but we’re also doing some work on the large 3.0 release. This will feature a lot of things, but one of those things is a major set of improvements on top of our API.

Our API is pretty great, overall. A lot of people use it with great success in quite a number of ways. It’s lacking, though, when it comes to some of the types of queries that can be performed.

Basically, the API is nested a bit too deeply. You can’t really make a query like “Give me all diff comments across all review requests from the past year.” We want that to be possible.

We also want a flexible approach to versioning, to help us going forward. There are a lot of options for this, and some work really well for many APIs, but maybe less so for our needs.

So, I’ve been toying with all this, and put together some initial design notes on API v3.

Nothing here is set in stone. I’m totally open to feedback!

Read More

Djblets REST API improvements

We maintain a Django application/utility framework called Djblets. Amongst other things, this provides the framework for implementing REST APIs. We use this for the Review Board API.

Review Board adds a utility layer on top of this that supports a bunch of other features, including API tokens, base test cases and utilities for API unit testing, API resource module registration/lazy lookups, and more. These are all pretty useful things, so we’ve decided to move them in to Djblets.

What this means is that, starting in Djblets 0.9, any consumers of the API will be able to offer:

  • API tokens, with access control defined by a powerful JSON policy definition language.
  • An easier, more complete way to test APIs.
  • Helpers to make more complex API codebases manageable.
  • Utilities for implementing flexible API queries (less than, greater than, etc. for numeric fields, for instance).

This also lets us slim down the Review Board API codebase just a bit, and keep our API support consistent on future projects.

Read More

Some diff viewer polish going into 2.5

In Review Board 2.5, we’re working on polishing up bits of the UI, while at the same time keeping a level of familiarity. We’re not going for a radically changed UI, but rather something that feels more like an evolution of what we had.

So tonight, we have two small polish changes going in that we’re playing with.

A more appealing comment dialog

The first is a softer, less boxy-feeling comment dialog. Here’s how it looked before:

Old comment dialog

Here’s how it looks now.

New comment dialog in Review Board 2.5

We’ve softened the borders, added some rounded corners, moved the dirty state indicator into the title, and added a slight drop shadow to help it pop. We also made it a bit larger by default, giving you more room to write in.

Again, nothing revolutionary, but nicer to look at.

A less bold chunk highlighter

When navigating through chunks of a diff, Review Board would highlight the selected chunk by surrounding it with 2px-wide black borders. While effective, this was a bit of an eye-sore.

Old diff chunk highlighter

We’re trying something a bit more subtle, yet still quite visible, and cleaner.

New diff chunk highlighter in Review Board 2.5

We’ll still be tweaking all this, and we’re not aiming for any new massive changes in 2.5 at this point (2.6 and 3.0 may have some more refinements/redesigns though). Our aim is to make 2.5 just feel a lot more comfortable and clean, compared to 2.0.

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