RBTools 2.0 is out, bringing compatibility improvements and new features for all users. The biggest improvement is the support for Review Board 4.0’s upcoming multi-commit review requests.
Multi-Commit Review Requests
Review Board 4.0 beta 1 is coming in the next few weeks, and with RBTools 2.0, developers will be able to post a series of commits to a review request so that they can be reviewed individually or as one squashed change, depending on what the reviewer chooses to do.
Those changes can also be landed, preserving their history or squashing them back into a single commit.
To stay with the old behavior and squash the commits before posting to a review request, you can pass –squash to rbt post or rbt land (or set SQUASH_HISTORY = True or LAND_SQUASH = True, respectively, in .reviewboardrc).
This is available for both Git and Mercurial, and will require Review Board 4.0.
RBCommons users will receive multi-commit review request support in 2021.
Custom Certificate Authorities
If your Review Board server uses a self-signed certificate backed by an in-house Certificate Authority, you can now configure RBTools to recognize it through the --ca-certs, --client-key, and --client-cert options (or CA_CERTS, CLIENT_KEY, and CLIENT_CERT in .reviewboardrc).
Easier Repository Setup
rbt setup-repo has been redesigned to better help people configure their local repositories to connect to Review Board. It offers a more helpful guided setup, making it easier to find the right repository and generate your .reviewboardrc file.
Default Branches in Git
RBTools now understands the init.defaultBranch configuration for Git, helping you transition your primary branch from master to something like main.
Better Mercurial Integration
Compatibility issues are fixed, repository detection is faster, and custom scripts can benefit from performance improvements by connecting RBTools to the Mercurial command server.
And Better Perforce Integration
RBTools can work with a wider mix of configurations utilizing SSL and brokers.
There’s also a new reviewboard.repository_name Perforce counter that can tie a depot to a Review Board repository, which can be used if .reviewboardrc isn’t an option.
Plus…
Variety of improvements for Python 3 compatibility (including support for Python 3.9).
Additional Git arguments for fine-tuning rename detection.
Custom formatting for rbt status, which is useful for scripting.
rbt land and rbt patch now accept a review request URL, instead of just an ID.
rbt patch can print a patch from a review request without needing a local copy of the repository.
If you’re a regular follower of ChangeLog, you’ll notice we’ve gone from weekly to semi-monthly, and may be wondering what’s going on. Don’t worry, we’ll return to our regularly-scheduled ChangeLog in time.
We’ve been focusing heavily on wrapping up Review Board 4.0 development, testing things internally, and helping many of our support customers get out from under a backlog of internal support requests within their companies.
And just taking care of ourselves during a global pandemic.
So here’s some of what we’ve been busy with lately:
Review Board 4.0 beta and RBTools 2.0 beta preparation
Wrapping up our semester with CANOSP students
Higher Power Pack/RBCommons Trial Lengths
We’ve increased the amount of time you have to give Power Pack or RBCommons a try. Now, when you download a Power Pack license, or sign up for a team on RBCommons, you have two full months to fully explore and use the products.
We’ve applied the new trial period to all existing RBCommons customers who are still in their trial.
If you’re a Power Pack user, and have a trial license, come talk to us for an extension.
New Releases
RBTools 1.0.3
Last month, we released RBTools 1.0.3, which was long overdue. We’re going to try to release RBTools releases more frequently going forward, and we have some good stuff prepared for 1.0.4 for Perforce users coming up soon.
We also have two new releases for some tools we use to help build Review Board: kgb, and introducing babel-plugin-django-gettext.
kgb 5.0
kgb is a Python module that helps with writing unit tests, adding support for function spies. This lets you spy on any function or method, whether in your own code or elsewhere, and track all calls made to the function and inspect the results of those calls.
It’s also used to override what happens when a function is called, mocking results or behavior. This goes far beyond the capabilities of Python’s own mock patching, and instead alters things at a bytecode level. Super useful when you want to fake results from urlopen, for example.
kgb 5.0 introduces support for:
Python 3.8
New spy assertion methods, providing detailed output when they fail
Support for spying on “slippery” functions (functions generated dynamically when referencing the function itself — common in some API-wrapping Python libraries, like Stripe)
babel-plugin-django-gettext 1.0
We use Babel to let us build modern JavaScript and export it to older browsers. Something Babel allows for is custom plugins to transform JavaScript, and we’ve introduced a new plugin to help us write better localized text.
When using the standard gettext support, lines are not allowed to wrap, meaning you end up with some very long lines of text to maintain, and if you want to include the contents of variables in the text, you have to wrap in this interpolate() call, which is a pain.
This plugin takes all the annoyance out of this. Instead of writing:
var s = interpolate(
gettext('This is localizated text, and we can freely wrap lines how we want, or include variables like %(foo)s.'),
{'foo': foo},
true);
We get to write:
const s = _`
This is localizated text, and we can freely wrap
lines how we want, or include variables like ${foo}.
`;
Better, right?
If you use Babel and Django, give this plugin a try.
We’ll be releasing a new version soon with even better support for ngettext (used for strings that are based on singular/plural values) and combining with other tagged templates (like dedent).
Review Board 3.0.18 Release Prep
We’re getting close to a new Review Board 3.0.18 release. There’s a lot going into this one, but some highlights will include:
Preparation for GitHub and Bitbucket API/feature deprecations
Compatibility fixes for GitLab, Subversion, and Perforce
Improved API support for working with repositories
Faster SSH communication
Faster condensediffs for large MySQL databases
Lots of bug fixes
Expect 3.0.18 within the next two weeks.
Review Board 4.0 Release Prep
Work continues. We’ve had some people test 4.0 early, and found some regressions that pertain to extensions. We don’t want to release with those regressions in place, so we’re still iterating, but the good news is that the core product is looking pretty good now.
Remember, this release is a major architectural rewrite of the product, with equally major dependency updates, so there’s a lot to get right.
Meanwhile, we’re getting RBTools 2.0 ready for beta. This is meant to be used with Review Board 4.0, and features all the multi-commit review support, from posting changes to landing them. We’ll be shipping both at the same time.
CANOSP Student Wrap-Ups
We’ve talked before about the CANOSP student program we work with in Canada. Well, we’ve wrapped up our semester, and I can speak for the team when I say we’re going to miss working with this group.
By the way, if you’re looking to hire some strong developers coming out of college, we have plenty we can refer.
To wrap up their semester, they’ve put together some final demos of the work they’ve done, and we’d like to show them off.
Hannah Lin
Hannah worked this semester on a prototype for a new first-time setup guide for administrators, and some keyboard accessibility improvements in the diff viewer and modal dialogs, amongst other improvements. She’s also continuing on after the semester, working on a formatting toolbar for input fields.
Katherine Patenio
Katherine worked away on RBTools for most of the semester, fixing some bugs that shipped in RBTools 1.0.3, and completely reworking the rbt setup-repo experience (which we hope to ship in RBTools 2.0).
She also did a lot of work on investigating improvements to supporting users with different kinds of color-blindness, which she covers in this demo.
Monica Bui
Monica focused primarily this semester on keyboard navigation improvements in the New Review Request page (part of a big effort toward improved accessibility), and prototyping new guidance for filling in fields on a blank review request. We think that will pair nicely with work planned for Review Board 5.0.
Xiaohui Liu
Xiaohui worked on standardizing how we handle keyboard shortcuts, introducing a new registry on the page that anything can plug into to register shortcuts. This even offers a handy help screen, giving users an overview of all the keys can happily press to get their work done faster.
Xiaole Zeng
Xiaole’s projects covered help and accessibility improvements, such as adding a new Help menu to the top-right of every page (which could provide access to useful, relevant documentation), and making the review request infoboxes on the Dashboard less annoying and more keyboard-friendly. We’re looking to ship some of this in 4.0.
And that’s it for the moment
We’ll be back to a weekly format once we’ve gotten some of these releases wrapped up, and of course any time we have something pretty exciting to talk about.
Today’s release of RBTools 1.0.3 is a big one, featuring enhancements for Mercurial support, a vastly improved commit editing experience when landing changes, and several compatibility fixes for Python 3 and various types of repositories.
Landing Commits on Mercurial
rbt land now supports landing commits on Mercurial repositories.
You can land a local change from a Mercurial branch or bookmark, or a remote change from a review request. This will first verify that the change has been approved on Review Board before allowing it to land. Once approved, a new merge commit containing the information and URL of the review request will be placed on your destination branch.
This can also close the branch/bookmark being merged in on your behalf. See the documentation for details.
Improved Commit Editing
Patching a commit with rbt patch -c, or landing a commit with rbt land -e has always let you edit the message for the commit, but the experience was sub-par.
Now RBTools will mimic Git or Mercurial’s standard editing environment, helping your editor show the syntax highlighting or line length limits it would normally show.
Deleting all text in the editor and saving will cancel the patch/land operation.
You can also set a custom editor when working with RBTools by setting the new $RBTOOLS_EDITOR environment variable.
Compatibility Fixes
We’ve fixed a number of Python 3 compatibility issues. These largely centered around:
Changes in Python 3.8
Windows environment differences
Editing or processing commits containing non-ASCII characters
Normalizing URLs and paths for Subversion
Loading in Perforce metadata
Passing --help as the last argument
There’s also a fix for looking up available Git remotes for a branch when a tracking branch isn’t set. Thanks to Joshua Olson for this fix!
This is our first ChangeLog in several weeks. As you all know, the current pandemic has resulted in a lot of changes and hardships in the world. We’re doing fine here, and our team has stayed healthy and safe, if a little less productive than we’d like as we adjust and take care of our families.
Still, work never ceases, and it’s time to start keeping you all up-to-date again. Here’s a breakdown of what we’ll be covering today.
More companies than ever are in full-on work-from-home mode, and this brings with it a lot of new work challenges that are, right now, often mixed with personal-life stresses.
We can help with at least some of that.
Our company offers support contracts for Review Board, which can be tailored to meet your company’s needs. We help with anything from basic Q&A and troubleshooting to custom builds and assistance with developing in-house integrations.
If you’re managing Review Board at your company, and are feeling a bit overwhelmed right now, please reach out. We can help. And we take support seriously.
Basic Support
Basic Support is pretty well-suited for smaller companies that need general troubleshooting, installation/upgrade assistance, or may have other questions.
We guarantee a response by the following day, but always aim for same-day (just depends on the support load).
Unlike our community support forum, all your support requests are handled privately on a dedicated support tracker, where you can manage tickets, provide confidential attachments, and more.
We don’t farm out our support to some outside party. We, the developers of Review Board, will handle your support. You’ll probably hear from me personally quite a bit.
Premium Support
This is a better option for the larger companies.
Or if you’re working on any in-house integrations or need priority bug fixes or need to use an older version of Review Board but may need some custom builds with fixes on occasion.
Or have some terrible emergency that needs to be resolved quick.
With Premium, there’s a same-day guarantee, 24/7/365. We’ll usually respond within an hour, especially if it’s an emergency. I will personally wake up and take care of your issue at 4AM if you need something.
So again, if things are crazy right now and you need a hand, contact us and we’ll talk options with you.
Increases to Trial Lengths
Since things are slower-moving right now (again, with the work-from-home status of so many companies), we want to make sure that you’re not in as much of a rush to evaluate either RBCommons and Power Pack.
So we’re going to be increasing the trial lengths of both from 30 days to 60.
This isn’t done yet, as we’re still preparing the codebases to change this over. In the meantime, if you’re a trial user of either, we’ll try to make sure to be proactive and increase your trial period manually.
A much better commit editing experience (for rbt land and rbt patch)
Several bug fixes for various source code management systems and for Python 3 environments
We should have this release out next week.
KGB 5.0
KGB is our Python module for using function spies in unit tests. This lets you track when a function is called, with what arguments and results, and to even override what happens when that function is called.
It’s extremely powerful, and is a big part of how we maintain our large test suites.
We’re preparing a 5.0 release, which adds:
Python 3.8 support, with positional-only arguments
Workarounds for very corner-casey situations with method decorator that generate a new function every time it’s accessed (what we’re calling “slippery functions,” because they’re hard to hold on to)
Probably some new helpers for asserting the results of calls (TBD)
This should be released in the coming weeks. If you’re a Python user, I highly suggest giving KGB a try.
Review Board 4.0 Progress
Almost there.
We were going to get 4.0 in beta form by end of March. That was the goal. We hinted at this last time, and we were feeling good about it, but the impact from the pandemic changed some priorities.
So it’s delayed… I’m not going to give a new date at this point, but nearly everything is ready for beta. We just want to hammer on it some more first, make sure we’re pushing out a solid beta. Pretty much everything, including our extension ecosystem, is ready to go.
Student Demos
As you may know by now, we work with CS students every semester, mentoring them and helping them learn to contribute to real-world code bases through Review Board development.
They recently completed their second demo videos for the semester, showing off what they’ve built. Please take a look. I’m sure they’d love to hear some positive feedback on their videos:
Stay Safe, and Wash Your Hands
(Definitely the catch phrase of 2020, but it’s important!)
Hi everyone, and welcome to this week’s ChangeLog. This week, we want to talk about accessibility improvements for Review Board 4.0, and show you what this semester’s students are working on.
If you want to watch some videos instead of reading a bunch of stuff, jump down to Student Demo Videos!
Accessibility in Review Board
As we revise parts of our UI, introducing new features and designing new CSS Components, we have a goal of improving accessibility. We’re aiming to better support screen readers, improve keyboard navigation, and help people with visual impairments.
This will not be 100% implemented by 4.0, since we do plan to release sometime soon, but we will have laid the groundwork, working toward eventually being fully compliant with the Web Content Accessibility Guidelines (WCAG) 2.1.
There’s a lot that goes into accessibility on the web, but there’s two key areas that are important to get right, and are becoming a core part of our design and CSS component specifications: ARIA attributes and keyboard navigation.
ARIA attributes help screen readers and other assistive technologies understand, navigate, and communicate parts of the UI. They can communicate the intent of a UI component, provide more suitable labels or hints to screen readers, notify as important content updates, and more. They’re important, and we haven’t been good at using them, but they’re now being baked in to the design of any new UI we write.
Keyboard navigation is also very important. Not everyone can or wants to use a pointing device to navigate the UI, and we’ve identified several places where keyboard navigation (and focus presentation) is subpar or flat-out broken. So we’re making this a first-class citizen in new UIs, adding new keyboard shortcuts for important content areas or operations, and fixing cases where navigation is just busted.
To be clear, these aren’t the only focuses — there’s a lot more to the accessibility work than this. Improving accessibility is a long-term goal, and Review Board is a big product. We aren’t holding up 4.0 for this, but rather expect to spend time throughout the 4.0.x release cycle to gradually work on this.
And it’s a current focus of some of our student projects.
Student Demo Videos
In an earlier ChangeLog, we announced our new team of students working on Review Board. The big focuses this semester are on keyboard accessibility and first-time setup improvements.
They’ve been working hard for a month now, and have just completed their first (of three) demo videos. We’d like to show them off.
All videos are uploaded to our YouTube channel. Subscribe to keep up with content as we upload it.
Hannah Lin
Hannah’s been working on implementing keyboard navigation for file attachments, letting users focus on the attachments and control the pop-up menu (for reviewing, updating attachments, deleting, and downloading). That was her first warm-up project.
Her main project for the semester is working on a first-time setup guide, for new Review Board administrators. The goal is to help them get a new server up-and-running fast by walking them through the main setup steps as they progress through the administration UI.
Katherine Patenio
Katherine’s first demo covers some initial bug fixing work for RBTools on Python 3, addressing a problem where --help didn’t always work. She’s fixed this up and added a new layer of unit tests we can build upon.
Her main project for the semester isn’t covered here, but she’s going to be working on the rbt setup-repo command, helping streamline getting a new repository set up with Review Board.
Monica Bui
Monica’s also working on keyboard accessibility. Her focus in this demo is improving the New Review Request page, making sure that all elements can be tabbed to and navigated entirely by keyboard.
Xiaohui Liu
Xiaohui’s first project fixes up tab key navigation in the review request page. Previously, tabbing to fields would prioritize the fields on the right-hand side of review requests (Branch, Bugs, etc.) before the main fields (Description, Testing Done), which wasn’t really intuitive. His fix brings some sanity back to tab orders.
His second project is to implement common support in the UI for keyboard shortcuts, making it much easier for us to bake in better keyboard support on every page with less code to worry about.
Xiaole Zeng
Xiaole’s working on improving help within the product, giving users both a single place to go to when needing to find documentation or other useful information, and finding places within the UI where we can offer better inline guidance. For the latter, she’s working on adding helpful descriptions and documentation links when configuring repositories, based on the selected hosting service or repository type.
Next Week
We’re getting a new RBTools release ready to ship, so you’ll see that soon. We’re also testing 4.0 beta 1, and are getting that beta release on the calendar.
If you want to know more, have any questions, or are curious about anything else, please reach out on our community forum.
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:
Updating our diff parsers to allow additional information (such as repository details) to be extracted and stored
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
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:
Team Owner (capable of making all changes to an account, including cancelling and changing plans)
Team Administrator (capable of managing users, repositories, review groups, etc., but cannot manage anything billing-related)
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.
Today’s release of RBTools fixes some of the most common issues experienced in the recent 1.0 release:
Improved Windows compatibility
This release fixes some regressions on Windows, namely a crash when prompting for a password for Review Board.
If you’re continuing to hit problems on Windows, please let us know in our community support tracker so we can collect additional information on your setup.
Fixes for Empty Diff errors on Git
While RBTools 1.0 greatly improved how diffs were generated for Git repositories under many scenarios, it broke one important workflow.
Posting a branch for review after pushing that branch upstream no longer results in errors about empty diffs when a tracking branch is configured. Instead, the tracking branch is once again respected, allowing your topic branch to be posted for review in full.
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.
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 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).
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.
