ChangeLog

What’s going on in the world of Beanbag development.

ChangeLog – November 22, 2019 — Review Board 3.0.16 Status

Christian Hammond

As the holidays quickly approach, we’re trying to wrap up what we can from some of our bigger projects so we can enjoy some much-needed downtime with our loved ones. Thanksgiving is only a week away, and we’ll be taking a short break from ChangeLog in order to focus on stuffing ourselves full of turkey.

So this week will be a but short, but we wanted to go over the next Review Board release on our roadmap, Review Board 3.0.16.

It’s been 5 months!

Yeah, we haven’t had a 3.0.x release in a while. There’s a few reasons for this, and we’ve gone over some of them before. In summary, we’ve been focusing primarily on getting Review Board 4.0 done and adding some much-needed improvements to RBCommons.

Believe it or not, though, there’s active work going into 3.0.16, right now. As in, I’m taking a break from writing 3.0.16 code to write this ChangeLog.

What’s coming?

So there’s an assortment of bug fixes, for sure. Things like:

  • Subversion diff parsing improvements
  • Better bullet-proofing when dealing with truncated Bitbucket webhook payloads
  • Fixes for edge cases where dashboard counters might not update correctly
  • Some search indexing improvements

Along with that, though, we’re making some more important mini-architectural changes:

  • New API for updating a user’s name, e-mail address, and active flag (indicating whether they’re still able to use the server)
  • New API for filtering review requests based on the Branch field
  • Some future-proofing around registration of SCMTools (which handle talking to repositories like Git and Subversion) and HostingServices (which talk to services like GitHub and Bitbucket)
  • Allowing repository configuration to show custom forms for different types of repositories (in-progress)

These are actually pretty important improvements that we wanted to finish before releasing 3.0.16. The API changes are based on a lot of user feedback, and we’re going to finally get this to you soon (sorry for the wait!)

The repository-related functionality is going to not only allow for a better repository configuration experience, but to open the door soon for official support for ClearCase.

ClearCase

Historically, our ClearCase support was entirely community-driven. We were dependent on volunteers to develop and test any fixes or improvements going into that support. This was tough for us, because we know many of you out there do use ClearCase and have had trouble upgrading Review Board due to breakages that we just couldn’t do much about.

This is changing. While it’s still early in development, I’m glad to say we’ll be able to announce a new official ClearCase integration before too long. This will be part of Power Pack and will replace the old, sorta-bitrotted and limited community version.

We’ll have more on this later, but for those of you using ClearCase, we want you to know that improvements are coming. Not for 3.0.16 — again, it’s still early — but before too long.

What about Review Board 4.0?

The last major thing left before beta 1 is a completion of the new administration UI, a topic we’ve also discussed before. This is a big project, required for moving to Django 1.11 and Python 3, but it’s mostly done now. We’re aiming for a 4.0 beta 1 in January, and fast-tracking beta 2 after.

So stay tuned for that after the holidays!

Wrapping Up

That’s it for this week! Again, we’re off next week, probably collectively in food comas. We’ll resume the following week.

If you have any questions, or anything you’re curious about and want us to cover, please reach out on our community forum.

We’re also on Reddit (/r/reviewboard), Twitter, Facebook, and YouTube if you want other ways to keep up with what we’re up to.

Read More

ChangeLog: November 14, 2019 — Student Demos

Christian Hammond 1 Comment

This week’s ChangeLog is a bit different in focus. Instead of the work we’re doing, we want to talk about some of the work our students are doing.

Want to skip the text but see some cool demos? Scroll down!

Student Programs

For over a decade now, we’ve worked with hundreds of CS students eager to get their feet wet in the industry, mentoring them and giving them cool projects in Review Board to explore. Some have turned into features you use today (such as issue tracking and extensions).

There have been multiple programs over the years that we’ve worked with:

  • Google Summer of Code
  • UCOSP (a Canadian university program we were a part of for many years, now defunct)
  • Open Academy (an experimental university program ran out of Stanford, now defunct)
  • CANOSP (the phoenix rising out of the ashes of UCOSP, currently focused on the University of Alberta)

We’re currently working with CANOSP, piloting the program and mentoring a small group of students as they build some features and prototypes for Review Board.

This Semester

We have three students this semester: Adil Malik, Ceegan Hale, and Nicole Hagerman. They’re all working on various projects that improve the review experience:

  • Review UIs for XML, JSON, and Jupyter Notebooks
  • Hiding the content for minified files in the diff viewer, by default
  • Supporting binary files in the diff viewer

These projects are considered prototypes at this stage. We’re hoping they’ll make it into a release sooner rather than later, but a big part of this work is seeing how feasible these ideas are and what sort of work still needs to be solved before rolling it into production.

XML, JSON, and Jupyter Notebook Review UIs

Adil and Nicole are both primarily focused on the Review UIs, working together on some aspects to beef up the Review UI capabilities under the hood.

Adil built a Review UI for XML files (letting you diff the tree structure, and providing options for changing how that tree is rendered). He’s also been working on a Jupyter Notebook Review UI, playing with ideas for how these would be rendered, diffed, commented on, etc.

Hey, if you’re interested in Jupyter Notebooks, he’s looking for feedback.

Nicole built a Review UI for JSON files, the counterpart to the XML Review UI. To allow for custom rendering options required by both, Nicole’s been building out our baseline Review UI support, allowing them to define utility URLs that can, for instance, re-render parts of content based on the toggle of a checkbox. Adil’s been working with her on the client side of this.

Binary Files and Minified Files in the Diff Viewer

Ceegan’s been building out a feature that we’ve been wanting to bring for a long time. Years back, when we first wrote Review UIs, we intended to use them in the diff viewer so that images, PDFs, etc. that are part of commits could be reviewed without having to upload a separate file attachment.

The base of this work existed in Review Board but was never completed. There were still some missing pieces, problems to solve. That’s what Ceegan’s focusing on: Prototyping the rest of this, getting binary files in the diff viewer working so we can see what’s left.

To get his feet wet, Ceegan built another really useful feature that will make web app developers out there happy. Minified files (*.min.js, *.min.css, etc.) no longer show up as a giant wall of text. Instead, we note to the reviewer that it’s a minifed file and they might not care about it but they can click to see the content. Just like with deleted files.

Demos!

Throughout the semester, we have our students put together demo videos showing off and talking about their work up to that point. We’ve recently completed the Demo 2 milestone, so we have a nice batch of videos to show off.

All videos are uploaded to our YouTube channel. Subscribe to keep up with content as we upload it.

And here are the videos this semester:

Adil Malik

Ceegan Hale

Nicole Hagerman

Wrapping Up

Our students work really hard for their projects, so if you have anything encouraging to say, you’d make their day by saying it on their videos 🙂

We’re hoping to get these in shape to land as part of Review Board 4.0 and 5.0, but it depends on the work that remains once the semester is over.

That’s it for this week, though. If you have any questions, or anything you’re curious about and want us to cover, please reach out on our community forum.

We’re also on reddit /r/reviewboard, Twitter, and Facebook, and of course YouTube if you want other ways to keep up with the latest.

Read More

ChangeLog: November 7, 2019 — Multi-Repo Diffs, Admin UI, and RBCommons

Christian Hammond

This week in ChangeLog, let’s talk about three projects we’ve been working on this week:

  • Multi-repository diffs
  • The latest administration UI improvements
  • Billing improvements and user roles in RBCommons

Multi-Repository Diffs

It’s pretty common to work with a lot of repositories at the same time, linking them together using Git submodules, SVN externals, or some other method. Sometimes you need to make changes across many repositories at once, and it’d be helpful to post those changes as one review request.

The problem is that diffs made across repositories aren’t always so useful. Not only do they generally lack repository information for each file, but Review Board itself assumes a single repository per review request. This matters because in order to show the diff viewer, Review Board needs to load each source file from the repository before it can apply the diff.

We’re trying to work toward multi-repository diff support as part of Review Board 4.0. Our existing DVCS work got us part-way there. The remaining pieces are/were:

  1. Updating our diff parsers to allow additional information (such as repository details) to be extracted and stored
  2. Updated our FileDiff model (representing a parsed file from a diff) to link to a Repository, and updating code to use that instead of ReviewRequest.repository
  3. Getting this information into diffs

Step 1 is done as of this week, and step 2 is mostly done. Step 3 is where things get interesting.

We talked last week about DiffX, our initiative to make diffs better. We’re hoping to start using DiffX from within RBTools and to inject repository information into the diff.

This is a longer-term goal, though. We’re exploring some options shorter-term, and talking to one vendor about natively providing this information in diffs they generate.

So will this be usable in Review Board 4.0? Kind of. We should have the core functionality all done, but not much may take advantage of this at first. Long-term, we’ll introduce multi-repository diff support for more types of repositories, and it’ll be amazing.

Administration UI Updates

Another week, another batch of screenshots to share of the new administration UI. We’ve completed the main database page and the Change List page, which lists all changes made to the database for a specific type of model (table).

These build upon new CSS components coming to 4.0, which offer slide-out action drawers and filters for datagrids, inline warning/error/info alerts, and more goodies that extension authors can use for their own projects.

Next up are the Settings and Change Form pages, which allow for making changes to models in the database.

Once these are done, we get to upgrade Django!

RBCommons Roles and Billing Updates

RBCommons, our Review Board SaaS, has received a lot of our attention lately. Particularly in the areas of billing, team administration, and sign-up.

Much of this work is based on customer feedback. As RBCommons has grown, our user base has moved from primarily Silicon Valley startups to an international community of companies, organizations, and educational institutions of all sizes. And some of those need a bit more from us when it comes to how they manage their teams and handle billing-related matters.

As part of our plans, we’re working on:

  • Splitting the existing Team Administrator role into three new roles:
    1. Team Owner (capable of making all changes to an account, including cancelling and changing plans)
    2. Team Administrator (capable of managing users, repositories, review groups, etc., but cannot manage anything billing-related)
    3. Billing Contact (can view invoices, change payment information, and receive billing-related e-mails, but nothing else)
  • Improving our invoices, showing more useful information to help users better meet any company-internal, regulatory, or tax requirements they might have
  • Adapting our billing process to work better with credit card billing changes that are or will be going into effect in some countries, to ensure these customers’ payments go through without any headaches
  • Improving the sign-up flow, to help get teams up-and-running a bit faster

We’ll talk about all this in more detail later when we launch our next big update to RBCommons.

Next Week

We’ll have more Administration UI work to show off, and with it a new collection of CSS Components to talk about. We’ll also go over what our CANOSP students from the University of Alberta have been up to.

If you have any questions, or anything you’re curious about and want us to cover, please reach out on our community forum.

We’re also on reddit /r/reviewboard, Twitter, and Facebook, if you want other ways to keep up with the latest.

Read More

ChangeLog: October 31, 2019 — DiffX, CSS Components, Admin UI

Christian Hammond 1 Comment

This week, we’re going to dive into three major topics:

  • DiffX, our proposed standard for a better Unified Diff format
  • Our new in-house CSS Components standard
  • The work being done on the Review Board Administration UI

DiffX

Unified Diffs, the most common type of diff files, are pretty lacking in standards. Nearly every type of source code management solution outputs its own version of a unified diff, shoving metadata into it however the developers saw fit. This frankly makes it a pain to work with diffs in Review Board, and I’m sure anyone else building similar tools can say the same thing.

A few years ago, we jotted down some ideas of what we’d like to see in diffs. We wanted:

  1. A superset of Unified Diffs that’s fully backwards-compatible (no way would a new diff format gain traction if existing tools couldn’t use it)
  2. A format that could be reliably serialized/deserialized (complete with metadata and file contents) as easily as something like JSON without writing a parser for a dozen different variations of the format
  3. Information on the encodings of a diff file and of the contents of a file, so we no longer have to guess
  4. Changes across multiple commits in a single file
  5. Some standard way of representing changes to binary files

We feel this is important. You wouldn’t believe how wildly different two diff files can be, and how broken most are (just having spaces in a filename means you’re going to run into all sorts of crazy problems).

So we put these ideas together and called it DiffX. Our plan was to build a specification, a standard Python library (and later libraries for other languages), and RBTools/Review Board support.

This week we put up the initial draft of the DiffX specification and documentation. Take a look. See what horrors tools like ours go through, and what we’d like to do about it.

Do you work on another code review tool or source code management system? Let’s talk!

Note that this is still a work-in-progress, and we have a lot we need to better formalize the parsing and the metadata format (and make a public, useful reference implementation).

CSS Components

During Review Board 4.0 development, we kept running into clashes between CSS rules, and had to deeply nest CSS classes and elements in order to ensure our styles would apply. Yuck. This was not sustainable.

We sought to fix this for our code, and looked into what others have done. We considered BEM, BEMIT, and a few other approaches. None felt quite right for our needs (particularly since we want to avoid clashes between third-party extensions).

So we took what we liked in each and drafted our CSS Component Style Guide.

This gives us a better way of thinking about what goes into our stylesheets and HTML pages. We think in terms of formal, reusable components, instead of just haphazardly tacking on styles for whatever HTML we’re writing.

We group together LessCSS variables (used for colors, sizes, etc.) and macros (for customizing a component’s presentation in a safe way) under organized namespaces. Stylesheets (ours and extensions’) that are looking to fit in with our styles or specialize a component can rely on these to better fit in.

We’re also taking care to add formal documentation for everything we add, which forces us to think about our styles, reason about them, and support them.

Want to see this in action? Here’s a few examples:

We’re still working on moving over to this, writing all new CSS using this standard and migrating old styles as needed. This is a long-term project, but we thought it might be interesting to some of you.

If you’re developing extensions for Review Board, we encourage adopting these new styling conventions. It’ll make your life so much easier.

The New Administration UI

Last week, we talked about the work on Python 3 and Django 1.11, and some of the huge tasks we’ve had to work through to support this.

One of the large — and final — hurdles is our administration UI. Django helpfully provides a built-in administration UI that projects get out of the box, and it’s very useful. And we extend and customize it heavily.

The problem is that Django’s administration UI has changed a lot since 1.6, and frankly it wrecked ours. So we’re rebuilding it, better than it was before.

Here’s a breakdown on the new UI:

  • It’s mobile-friendly
  • Organization is now much more clear — all navigation is in the sidebar, not split between sidebar and the top header bar
  • The administration dashboard widgets are so much better — larger, less cluttered, faster, and trimmed down to only the most useful widgets
  • It’s completely our own, no longer dependent on Django’s rendering, so future upgrades will be smoother

It’s also built with our new CSS component standard, and introduces new components that we can use throughout the product. Extensions can take advantage of these, too, helping them look like a native part of Review Board without worrying too much about our styling.

Here’s a couple in-progress screenshots.

Next Week

We’ll go over some of the new diff functionality being worked on in Review Board 4.0, and what we’ve been up to in RBCommons land.

Again, if you have any questions, or anything you’re curious about and want us to cover, please reach out on our community forum.

Read More

ChangeLog: October 24, 2019 – The Python 3 and Django 1.11 Migration

Christian Hammond 2 Comments

Hi, Christian Hammond here. Welcome back to ChangeLog, where we cover the latest going on in Review Board, RBCommons, and Beanbag in general. It’s been a while since we’ve posted one of these, but we’re aiming to bring this back as a weekly series.

There’s a lot to talk about.

The Short Version

  • We delayed Review Board 4.0 to bring Django 1.11 and Python 3 support. This will not be released by Python 2’s End Of Life date.
  • Python 3 and Django 1.11 support has been in the works for a long time, but is far more complex than it may seem.

The Longer Version: Where are we today

We’ve had four main focuses this year:

  • Getting Review Board 4.0 beta 1 ready to launch. This is way behind our original schedule, but intentionally so — we’ll go over the reasons why in a minute.
  • Bringing integrations options to RBCommons and improving team management, billing, and signup.
  • Building out new functionality for Power Pack (PDF diffing, and in-progress authentication improvements).
  • Growing our business (the prior two tasks were part of that), supporting customers, and assisting some with large projects of their own.

This along with a multitude of smaller tasks taking our time throughout the year (and, on a personal note, dealing with the aftermath of the Paradise, CA “Camp Fire.”)

Most of you are here to find out about Review Board, so let’s dive into that.

The “World Update”: Review Board 4.0, Python 3, and Django 1.11

Our original goal for Review Board 4.0 was to bring support for multi-commit review requests and to ship that. This was a large project, as Review Board was originally written before DVCS was common (Subversion and Perforce were the primarily open source and enterprise solutions).

The problem though, is Python 2 End Of Life is coming up fast, and if we kept on schedule with Review Board 4.0, it would be a long time until we’d support Python 3. So we decided to delay 4.0 in order to get it ready for Python 3.

Note that we also still need to support Python 2.7, since many companies are still heavily tied to 2.7 (older distros, custom extensions and scripts).

So what’s hard about supporting Python 3? Welllll….

The Python Compatibility Problem

Python 3 is leaps and bounds better than Python 2 in most ways, but porting a large and complex product from Python 2 to 3 is even harder than you think.

Most Python users know of the major differences:

  • Modules have moved and functions have been renamed
  • The default string type has changed from byte strings to Unicode
  • Some operators have changed
  • There’s new syntax additions
  • etc.

We thought we prepared years ago to make this move easy. We used Unicode strings in every file. We used the six module to help with using the right modules, types, and functions.

In the end, it was harder than we expected. Our biggest challenge was definitely the Byte Strings vs. Unicode Strings differences. We thought we were in good shape for this, but we weren’t close.

Review Board does a lot of text processing. We’re parsing uploaded diffs, pulling source files from repositories, matching those up and applying the patch to the source, and generating side-by-side diffs. Much of this logic is over 10 years old, even so, we put a substantial amount of work in preparing for Python 3 years ago, so we were shocked by how much we got this wrong.

The problem comes down to the differences in how Python 2 and 3 would handle shoving two different string types together, which is very easy to do accidentally. Python 2 would roll with it, as in many cases the string types were compatible (and would automatically encode/decode so long as the content was basically ASCII). In Python 3, they outright break — which is a better approach, but hard to transition to — and it led us down a rabbit hole of problems.

Missing b'...' prefixes, changes in string return types from Python functions, functions that are no longer compatible with both string types, and very difficult decisions to make regarding compatibility with third-party SCMs.

All the little regressions and inconsistencies added up. Here’s a few more examples:

  • Using Python’s pickle library was a mess. Defaults have changed and pickled data became incompatible (due to module reference and string type changes). We had to build in compatibility layers here and test them thoroughly.
  • Anything that even subtly/unintentionally relied on dictionary sort orders would break.
  • Getting data in/out of processes, streams, and many other objects and functions is now way more sensitive to encoding issues, and required a lot of careful rewrites and testing.
  • Many functions (in Python and third-party modules) that used to return lists now return generators, due to their reliance on other functions that changed return types, and this can cause all sorts of subtle behavioral changes.

We’ve spent a lot of time tracking down issues that might immediately crash or might affect data several stages down, and sometimes be traced to something outside our codebase.

Fixing some Python issues means upgrading third-party modules, which can introduce their own new set of changes, regressions, and new rounds of work.

And the biggest source of that was Django.

The Django Problem

Django 1.6 (the version we’ve been using) breaks on Python 3.6+. This meant we had to upgrade to a newer version, something we’ve been putting off.

Django 1.7 introduced built-in support for database migrations. Quite nice for many projects, but the design was sub-optimal for applications like ours (upgrades could take hours or days longer than our approach) and was fundamentally incompatible with our own Django Evolution.

Many other core components of Django (the foundation for the administration UI, template rendering, URL management, forms, and all sorts of other common and obscure parts) have also largely changed over time in some pretty important ways.

We needed a solution for all of this, and we knew that would take time. To compensate we had to:

  1. Rewrite Django Evolution completely to coordinate evolutions and migrations and support modern Django: ~2 years of work, off and on, with hard problems to ponder
  2. Rewrite our administration UI completely to disconnect from Django’s (ensuring we don’t break again when we move to Django 2.x): estimated ~3 months of steady work, still in progress
  3. Build compatibility layers to help keep older code working and help with new code: ~2 months
  4. Just porting in general, updating dependencies, etc: ~3 months

We’re not done, but we’re close.

The Extensions Problem

Review Board is built to allow third-parties to extend its functionality, modify behavior, and link up with other in-house services. We try to be careful not to break extension functionality, and over time we’ve gotten more strict about providing compatibility and an upgrade path for functionality we want to deprecate or change.

The Python 3 and Django 1.11 upgrade is going to affect just about everybody who’s writing an extension. Some of the work we’ve done on adding compatibility layers will help with this process, but it’s going to mean a longer upgrade cycle for some companies.

We knew from the beginning that we’re going to have our hands full helping these companies out (as part of our support contracts), and that it’d be in our best interest to delay the release and break everything all at once instead of spreading out the breakages across multiple releases, and to also give ourselves time to figure out how best to minimize those breakages.

Most projects moving to Python 3 or to newer versions of Django don’t have to worry about this domino effect in the same way.

Timetable?

I hesitate to say when beta 1 will be done (been wrong before), but I can say that the last major piece of development is wrapping up. We’ll be kicking the tires on it, and want to get a beta out as soon as it’s stable enough.

We may not enable Python 3 builds for beta 1, focusing instead on Django 1.11 testing (Python 3 support is still going to be in development during this time), however we’re working with select customers on real-world testing against Python 3.

Community Questions

Every week, we’d like to address some questions, concerns, suggestions, etc. from the community. If you have any questions for next week, please reach out to us.

Q. The community forum seems quiet at times. Why is that?

A. Support requests from companies with support contracts are conducted over a separate support tracker. We always prioritize these support requests over any other work, and increasingly more companies are moving to this method of support for Review Board.

Q. Will Review Board 4.0 ship with Python 3 before the Python 2 End Of Life date?

A. No, it’s going to miss that date. Python 2.7 is still going to be required for now.

Q. There’s years of open review requests on reviews.reviewboard.org. Why is that?

A. We work with university students every semester to help prepare them for their jobs in the tech industry. They spend their semester building features for Review Board, most of which are prototypes. These make up the majority of the review requests on there. Others are contributions that might be outdated, might have been missed, might be incomplete, or might just not have been reviewed yet.

Next Week

We’ll be going over our new CSS component standard for the project and dive deeper into the new administration UI.

Again, if you have any questions, or anything you’re curious about and want us to cover, please reach out on our community forum.

Read More

ChangeLog: November 5, 2018

Christian Hammond

The World Update: Python 3 and Django 2

In a previous post, we talked the work we’re doing to move to modern versions of Python and Django. We’re calling this the “World Update,” and it’s quite a large and difficult project.

Database Migrations and Django Evolution

Much of the difficulty comes from an incompatibility between how we handle database migrations (using Django Evolution) and how Django handles them (using their built-in migrations support). These aren’t at all compatible, and for many reasons (legacy support and performance), we don’t want to ditch Django Evolution. This has by far been the biggest hurdle to overcome for the World Update.

We’ve been working on this, reworking nearly all of Django Evolution to better utilize migration support in Django, to provide a new set of generic structures for describing database state and modifications, and to (soon) hook into and partly override the migration process to allow both to co-exist.

Progress on this had been steady, and we feel we’re reaching a point where we’ll be able to fully support migrations in Django Evolution.

Djblets and Review Board Work

We now have Djblets working with modern Python 3.x releases and Django 1.6 through 2.1, so we’re in good shape there.

Review Board has a large number of patches in the works to bring Python 3.x and Django 2.1 compatibility. The biggest challenge in Review Board has to do with string type safety. In Python 2.x, Unicode and byte strings are somewhat interchangeable, but there’s a sharp divide in Python 3. We’ve found many cases where we’ve made bad assumptions about string types in Review Board, and are working on both fixing these and adding strict type checks.

World Update Releases

We’re expecting that Review Board 5.0 will require Python 3.5+ and the latest Django 2.x. Administrators will have to make sure they’re running a modern OS with the necessary version of Python, and extension authors will have some updates to perform, but in the end this will be so worth it.

Review Board 4.0 Status

We were initially hoping to release this in August, but that certainly didn’t happen. Too many things came up over this year that took away from the release.

The good news is, DVCS works, and we’re trying to polish up the experience. There’s a few other features we’re also trying to get into 4.0, but once we’re at a point where we feel people can begin safely using DVCS, the beta will start shipping. That will be… soon-ish. We’ll see what happens with the holidays.

Read More

RBTools 1.0 is here!

Christian Hammond

RBTools has been an important part of the life of Review Board users for many years. While it started off as a single tool for posting review requests, its feature set has evolved with time, turning into an extensible set of tools and APIs for talking to Review Board.

Today, we’re finally pulling RBTools out of the 0.x era with the release of RBTools 1.0.

Compatible with Python 3

Both the RBTools commands and the Python API now support Python 2.7 and 3.5+.

(Please let us know if you hit any issues on Python 3, as this is still pretty new.)

Better Repository Detection and Git Support

RBTools now does a better job determining which repository it’s working with, in case there’s confusion. For example, a Mercurial repository nested in a Git-managed home directory will no longer cause problems.

Git repositories in particular are now easier to work with. When generating a diff, RBTools now looks for the nearest upstream parent commit or branch, instead of requiring that users or repositories configure a specific tracking branch.

Publish Automated Reviews

Writing your own automated review solutions for Review Board 3.0 or RBCommons just became easier through the new rbt status-update command. Your scripts can use it to file a pending status update on a review request (showing that checks are being performed) and then update it to say that all is well or to report issues that need to be fixed.

This is useful for in-house continuous integration setups where you’re analyzing code for errors, style issues, documentation, or any other requirements you might have.

Easily Land Complex Dependent Changes

rbt land can now land multiple review requests tied together using the Depends On field.

This works with -r to take the ID of the review request you want to land. It will figure out which review requests must land before it and in which order. For example, if review request 3 depends on 2, which depends on 1, you can run:

$ rbt land --recursive -r 3

Instead of:

$ rbt land -r 1
$ rbt land -r 2
$ rbt land -r 3

This is a precursor to the new DVCS support coming soon in Review Board 4.0.

And That’s Not All

  • rbt setup-completion was added to enable auto-completion of RBTools commands and arguments in Bash and ZSH shells.

  • rbt alias was added to help you list and test out your custom aliases.

  • rbt post –submit-as can now automate posting review request updates, and not just new review requests, on a user’s behalf.

  • rbt post -m and rbt publish -m let you specify a custom description of your draft’s changes when publishing (equivalent to filling out the “Describe your changes” box when publishing in the browser).

  • rbt post –trivial-publish and rbt publish –trivial let you publish trivial updates to a review request without sending out e-mails to everyone (when using Review Board 3.0 or RBCommons).

  • rbt status now lists the review state and local branch for each review request you have up for review.

  • Warnings and errors in command output is now specially highlighted to help it stand out.

  • Several fixes and improvements for Git and Subversion compatibility.

  • The API has been improved, supporting extra_data fields and easier pagination of resources.

And plenty of other fixes and improvements. See the release notes for the full list of changes in 1.0.

Download It Today!

RBTools is out today for Windows, Linux, and Mac. Head on over to the downloads page for installation instructions.

Read More

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

Christian Hammond

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

ChangeLog: Catching Up

Christian Hammond 2 Comments

It’s been too long since we last ran the ChangeLog series, and felt it was the right time to start it back up again. ChangeLog is a look into the latest behind-the-scenes work going into Review Board, RBCommons, and other Beanbag projects. While intended to be a weekly series, we’d like to start off with some of the bigger tasks and feature development from the past month.

Moving to Django 1.11 and Python 3

Today, all current versions of Review Board depend on Django 1.6, an old release that’s no longer supported by the Django project but is by us, and doesn’t support modern Python 3 releases.

We’ve been stuck on 1.6 because 1.7 introduced (and later mandated) a new way of handling database migrations, which is incompatible with the method we’ve always used. Reconciling the differences has been a challenge.

In the past month, we’ve made significant progress toward both the Django and Python updates:

  • Djblets 2.0 (our development release) is now compatible with Django 1.6 through 1.11 and Python 2.7, 3.4, 3.5, and 3.6.
  • Django Evolution (used for database migrations) now works with Django 1.6 through 1.11 and Python 2.7, 3.4, 3.5, and 3.6. Work’s being done to let it co-exist with Django migrations now.
  • Review Board has started receiving patches for Django 1.11 and Python 3.5+ now. This is still in development, and likely won’t make the Review Board 4.0 release, but will be there for 5.0.
  • RBTools 1.0 (shipping in a few months) now has full Python 3 support.

New Release Schedules


We’ve began moving to a train model for releases, and have all of our main and upcoming products now on the calendar.

Here’s what this currently looks like:


  • Review Board 4.0 (with DVCS support!) is expected to ship in August, 2018
  • Review Board 3.0.x releases will ship (generally) every other Tuesday
  • RBTools 1.0 is expected to ship April 12th
  • RB-Gateway is expected to ship March 28th

We’re planning to release a new major Review Board release every ~6 months, meaning smaller but more frequent releases. We’re still experimenting with the schedule and timeframe for these releases.

RB-Gateway

We’ve releasing RB-Gateway 1.0 this month. This is a microservice designed to sit in front of a Git or Mercurial repository, providing an API and set of integrations that can be used by Review Board or any other tool or service for more deeply working with your repository.

RB-Gateway doesn’t change your workflow, and can be dropped in with minimal effort. It completely replaces the cgit/gitweb workaround for standalone Git repositories, and means you don’t need to set up something more complicated like GitLab just to work with Review Board.

You’ll see more information on RB-Gateway’s capabilities when we release later this month, and we’ll cover improvements being made to it here.

Wrapping Up…

Those are really just the major highlights, to get everyone up to speed. It doesn’t include the new features we’ve recently built, like being able to filter files in the diff viewer based on filename patterns, a new command for creating Review Board extension source trees, the work done on kgb, or the crazy investigation into deadlocks that’s delayed Review Board 3.0.4.

Going forward, these will be smaller, covering only what’s been done over the past week. If you like these posts, and want to see this continue, please let us know! You can find us on reddit or on the community support list.

Read More

Announcing virtualenv-multiver for Python Development

Christian Hammond

If you’ve worked with virtualenvs for Python before for development/testing, then you may have hit cases where you really wanted multiple versions of Python installed in your virtualenv. Which, you may actually have working, because virtualenv, in theory, supports this. In fact, you’re supposed to be able to do:

$ virtualenv -p python2.6 my-env
$ virtualenv -p python2.7 my-env

That’d be great, if it always worked. It doesn’t. When your virtualenv gets built, bin/python may end up being a link to bin/python2.7 (or what have you), or it may be the contents instead of a link. Subsequent installs may end up overwriting binaries, producing a python2.6 and python2.7that are both Python 2.7.

Oh and it gets worse. On Mac, with a standard Python install, these binaries actually end up invoking ../.Python, a symlink pointing to the system Python. This link is not versioned. So much for multiple Python versions in one virtualenv on the Mac.

A solution!

We fixed this. Now you can run a single command to get a working environment going, without messing with things or running into problems on the Mac. This is virtualenv-multiver.

Now, setting up an environment is as simple as:

$ pip install virtualenv-multiver
$ virtualenv-multiver my-env 2.6 2.7

Couldn’t be easier. This works both for new environments and existing ones.

This is a beta, so there may be some issues here or there. If this is useful to you, give it a try and let us know!

Read More