Review Board

One whole year… While attending SuperHappyDevHouse, David and I realized that it was the one year anniversary of Review Board’s public announcement. (This was the evening of May 17th. I’m just a few hours late in getting this post up.) It’s been a ... [More] pretty awesome year for Review Board. What begun as a small project intended for use in our team at VMware and in our personal open source projects turned into a large project with a great community of developers and users. It’s now being used by dozens of companies and projects (some of which have given us permission to list them publicly) and has had code contributions from over 35 users. To everyone who has contributed to the project, we’d like to give our thanks. Review Board wouldn’t be the tool it is today without your help. I’d like to list some of the major things that have happened in the past year. Review Board has been adopted by one or more teams at around 40 companies (including Yahoo! Search, VMware, and Tripwire). Received contributions from over 35 users. Added support for CVS, Subversion, Perforce, Git, Mercurial, and Bazaar. Added support for useful features such as interdiffs, screenshot commenting, syntax highlighted diffs, customizable dashboard for keeping track of review requests, status reports, a full JSON API, and more. Several presentations were given at various companies and conferences on Review Board by third parties. One public presentation was given by us at LugRadio Live USA 2008 (view the presentation) We’ve started hosting projects for this year’s Google Summer of Code on our Summer of Code server. That’s just a small sampling. There have been many changes made to stabilize the codebase, improve usability, and generally make the product more awesome. And of course there’s a number of things happening in the near future: Monotone support. A new, improved administration UI. Extensions support, allowing Review Board to be extended in a variety of ways and integrated into other products. A new set of command-line tools and a Python library for working with Review Board servers. Support for P4V (for Windows Perforce users). Database Migration and Parent Diffs Today, a change went in that improves Review Board in two fundamental ways. First, we now have a fast, powerful way of doing database migrations in-place, without dumping and loading the database. While this should make life easier for users and allow us to modify the database without fear of breaking people’s installs as often, it will also save administrators of large Review Board servers a lot of time. Before this change, the VMware database (of over 25,000 review requests) took at least 30 minutes to do a full migration. Now it shouldn’t take more than a minute. Second, we’ve just landed the initial support for diffs based on parent diffs. If you’re a user of a distributed version control system (such as Git or Mercurial) you’ll appreciate this. Before, your change had to apply against revisions in the master repository, making it impossible to put up a review request for a change on a sub-branch of a branch when the parent branch didn’t exist on the server. Now, a diff of the parent branch can be uploaded along with your sub-branch’s diff. Confused? Maybe an example will help. Say you’re working on a large restructuring change in your “code-restructure” branch in your local Git checkout. You have a topic branch off of your “code-restructure” branch with changes you want to put up for review. This used to be impossible without including the whole “code-restructure” branch’s changes in your diff as well, but now, you can put up a diff of the topic branch along with a diff of the “code-restructure” branch, and the topic branch’s diff will appear on Review Board, ready for review. The backend code for this is now in Subversion. We’ll be adding support to the post-review tool shortly, making this accessible to anyone. Review Board will become fully usable for distributed version control systems. Are you using Review Board? Review Board is gaining popularity, and more companies are beginning to use it. If you work for a company or an open source project that’s using Review Board and can give us permission to list you on our Happy Users page, please let us know! And here’s to an even better year for Review Board. [Less]

One of the things Christian and I looked at as we were getting Review Board off the ground was the tech talk on Mondrian. At the time, it was disappointing to us that Google had created this great tool, and kept it inside. Well, it’s still inside ... [More] , but Guido has just announced a public code-review project based on the idea of Mondrian. I played around with the demo server he’s got running, and it’s still pretty rough — a lot like Review Board was back when we first did our first public announcement. Since that time, we’ve had an amazing ride, with lots of contributions and the building of a fairly vibrant community. I wish the yet-to-be-named Mondrian-like project similar luck; code review is one of those things that can be a major drag, and having an excellent tool makes all the difference in the world. Just as a reminder, if you’re involved in this year’s Google Summer of Code as a mentor/student/organization, we’re offering to host a server for you. [Less]

Google Summer of Code 2008 is on, and soon students will begin coding, which means mentors will be reviewing code. While the Review Board project is not a participating project in this year’s Summer of Code, we felt Review Board could help with the ... [More] whole process, improving things for both the students and the mentors. Starting today, and for the duration of this year’s Summer of Code, we at the Review Board project would like to supply up to 30 projects with free Review Board hosting at gsoc.review-board.org. We’ll handle maintenance of the server, support, and provide assistance to get students and mentors set up. Doing code reviews with Review Board is simple and saves time over reviewing standard raw diffs, with features such as a powerful diff viewer with syntax highlighting and inline commenting, interdiffs, status reports, and support for a wide variety of revision control systems. We believe it can be as effective a tool for open source development as Bugzilla and Trac have become. Th Summer of Code server is intended for Summer of Code-related changes only. While we’d love to provide hosting for projects in general, we have limited resources. However, should your project decide to set up its own Review Board server in the future, we’ll be able to assist in migrating your Review Board history to your new server. If you’re interested in trying out Review Board for your Summer of Code project, you can find out how to apply on our Summer of Code Hosting page. To learn more about Review Board and how it works, you can look at our project website or watch our presentation from this year’s LugRadio Live USA. [Less]

Google Summer of Code 2008 is on, and soon students will begin coding, which means mentors will be reviewing code. While the Review Board project is not a participating project in this year’s Summer of Code, we felt Review Board could help with the ... [More] whole process, improving things for both the students and the mentors. Starting today, and for the duration of this year’s Summer of Code, we at the Review Board project would like to supply up to 30 projects with free Review Board hosting at gsoc.review-board.org. We’ll handle maintenance of the server, support, and provide assistance to get students and mentors set up. Doing code reviews with Review Board is simple and saves time over reviewing standard raw diffs, with features such as a powerful diff viewer with syntax highlighting and inline commenting, interdiffs, status reports, and support for a wide variety of revision control systems. We believe it can be as effective a tool for open source development as Bugzilla and Trac have become. Th Summer of Code server is intended for Summer of Code-related changes only. While we’d love to provide hosting for projects in general, we have limited resources. However, should your project decide to set up its own Review Board server in the future, we’ll be able to assist in migrating your Review Board history to your new server. If you’re interested in trying out Review Board for your Summer of Code project, you can find out how to apply on our Summer of Code Hosting page. To learn more about Review Board and how it works, you can look at our project website or watch our presentation from this year’s LugRadio Live USA. [Less]

This year’s LugRadio Live USA conference was a blast. There were some great talks, interesting booths, and fun swag. The Review Board presentation went pretty well. I think in my next presentation I’ll demo more often instead of just at the end, but ... [More] all in all people seemed to find it interesting. The presentation focused on what Review Board is, how it works, and how it could benefit open source. With luck, it will encourage projects to begin using a real code review system, making life easier for all involved. For those that missed it, the slides and the presentation video are now available. Enjoy! [Less]

This year’s LugRadio Live USA conference was a blast. There were some great talks, interesting booths, and fun swag. The Review Board presentation went pretty well. I think in my next presentation I’ll demo more often instead of just at the end, but ... [More] all in all people seemed to find it interesting. The presentation focused on what Review Board is, how it works, and how it could benefit open source. With luck, it will encourage projects to begin using a real code review system, making life easier for all involved. For those that missed it, the slides and the presentation video are now available. Enjoy! [Less]

Table of contents for Django Development with DjbletsDjango Development with DjbletsDjango Development with Djblets: Custom Tag HelpersDjango Development with Djblets: Unrooting your URLsDjango Development with Djblets: Data GridsDjango Development ... [More] with Djblets: Dynamic Site Configuration Typically, Django sites are designed with the assumption that they’ll have a domain or subdomain to themselves. Often times this is fine, but if you’re developing a web application designed for redistribution, sometimes you can’t make that assumption. During development of Review Board, many of our users wanted the ability to install Review Board into a subdirectory of one of their domains, rather than a subdomain. There’s a few rules that are important when making your site relocatable: Always use MEDIA_URL when referring to your media directory, so that people can customize where they put their media files. Don’t hard-code URLs in templates. Use the {% url %} tag or get_absolute_url() when possible. These solve some of the issues, but doesn’t address relocating a Django site to a subdirectory. Djblets fills in this gap by providing a special URL handler designed to act as a prefix for all your projects’ URLs. To make use of this, you need to modify your settings.py file as follows: settings.py TEMPLATE_CONTEXT_PROCESSORS = ( ... 'djblets.util.context_processors.siteRoot', )   SITE_ROOT_URLCONF = 'yourproject.urls' ROOT_URLCONF = 'djblets.util.rooturl'   SITE_ROOT = '/' SITE_ROOT specifies where the site is located. By default, this should be “/”, but this can be changed to point to any path. For example, “/myproject/”. Note that it should always have a leading and a trailing slash. The custom template context processor (djblets.util.context_processors.siteRoot) will make SITE_ROOT accessible to templates. SITE_ROOT should be used in templates when you need to refer to URLs that aren’t designed to respect SITE_ROOT (such as User.get_absolute_url). Your own custom applications should always respect SITE_ROOT whenever providing a URL. ROOT_URLCONF is typically what you would set to point to your project’s URL. However, in this case, you’ll be pointing it to djblets.util.rooturl. This in turn will forward all URLs to your project’s handler, defined in SITE_ROOT_URLCONF. This is all you need to have a fully relocatable Django site! To sum up: Add djblets.util.context_processors.siteRoot to your TEMPLATE_CONTEXT_PROCESSORS. Set SITE_ROOT_URLCONF to your project’s URL handler. Set ROOT_URLCONF to ‘djblets.util.rooturl’ Prefix any URLs with SITE_ROOT in your templates, unless the URL would already take SITE_ROOT into account. This is functionality that will hopefully make its way into Django at some point. For now, you have an easy way of unrooting your Django project. Previous in series Next in series [Less]

Table of contents for Django Development with DjbletsDjango Development with DjbletsDjango Development with Djblets: Custom Tag HelpersDjango Development with Djblets: Unrooting your URLs Typically, Django sites are designed with the assumption that ... [More] they’ll have a domain or subdomain to themselves. Often times this is fine, but if you’re developing a web application designed for redistribution, sometimes you can’t make that assumption. During development of Review Board, many of our users wanted the ability to install Review Board into a subdirectory of one of their domains, rather than a subdomain. There’s a few rules that are important when making your site relocatable: Always use MEDIA_URL when referring to your media directory, so that people can customize where they put their media files. Don’t hard-code URLs in templates. Use the {% url %} tag or get_absolute_url() when possible. These solve some of the issues, but doesn’t address relocating a Django site to a subdirectory. Djblets fills in this gap by providing a special URL handler designed to act as a prefix for all your projects’ URLs. To make use of this, you need to modify your settings.py file as follows: settings.py TEMPLATE_CONTEXT_PROCESSORS = ( ... 'djblets.util.context_processors.siteRoot', )   SITE_ROOT_URLCONF = 'yourproject.urls' ROOT_URLCONF = 'djblets.util.rooturl'   SITE_ROOT = '/' SITE_ROOT specifies where the site is located. By default, this should be “/”, but this can be changed to point to any path. For example, “/myproject/”. Note that it should always have a leading and a trailing slash. The custom template context processor (djblets.util.context_processors.siteRoot) will make SITE_ROOT accessible to templates. SITE_ROOT should be used in templates when you need to refer to URLs that aren’t designed to respect SITE_ROOT (such as User.get_absolute_url). Your own custom applications should always respect SITE_ROOT whenever providing a URL. ROOT_URLCONF is typically what you would set to point to your project’s URL. However, in this case, you’ll be pointing it to djblets.util.rooturl. This in turn will forward all URLs to your project’s handler, defined in SITE_ROOT_URLCONF. This is all you need to have a fully relocatable Django site! To sum up: Add djblets.util.context_processors.siteRoot to your TEMPLATE_CONTEXT_PROCESSORS. Set SITE_ROOT_URLCONF to your project’s URL handler. Set ROOT_URLCONF to ‘djblets.util.rooturl’ Prefix any URLs with SITE_ROOT in your templates, unless the URL would already take SITE_ROOT into account. This is functionality that will hopefully make its way into Django at some point. For now, you have an easy way of unrooting your Django project. Previous in series [Less]

Table of contents for Django Development with DjbletsDjango Development with DjbletsDjango Development with Djblets: Custom Tag HelpersDjango Development with Djblets: Unrooting your URLsDjango Development with Djblets: Data GridsDjango Development ... [More] with Djblets: Dynamic Site Configuration I’m planning to cover all of what Django can do, but for now, let’s start simple with something most Django developers spend way too much time creating: Custom tags. Django’s nice enough to provide a @register.simple_tag decorator for creating very basic tags that don’t take a context but do take parameters. This is great, but what if you want more? Many Django applications use the same boilerplate time and time again to create their tags, but we make it much easier. Introducing @basictag and @blocktag. @basictag Ever wanted to use Django’s @register.simple_tag but needed access to the context? I’ve found far too many cases where this would be useful, but Django doesn’t make this easy. Your tag code would end up looking like this: class MyTagNode(template.Node): def __init__(self, arg1, arg2): self.arg1 = arg1 self.arg2 = arg2   def render(self, context): arg1 = Variable(self.arg1).resolve(context) arg2 = Variable(self.arg2).resolve(context)   return context['user']   @register.tag def mytag(parser, token): bits = token.split_contents() return MyTagNode(bits[1], bits[2]) Do this a few times and it’s bound to drive you nuts. How about this instead? from djblets.util.decorators import basictag   @register.tag @basictag(takes_context=True) def mytag(context, arg1, arg2): return context['user'] Far less code and increased readability. Hooray! @blocktag @blocktag aims to do the same thing @basictag does but for block tags. A block tag is a tag that contains nested content, like @spaceless or @for. This usually requires even more boilerplate than the above code fragment, except with the added complexity of having to grab the contents of the block. We’ve condensed it down to this: from djblets.util.decorators import blocktag   @register.tag @blocktag def blinkblock(context, nodelist, arg1, arg2): return "<blink>%s</blink>" % nodelist.render(context) If you’ve built block tags in the past, you’ll appreciate how simple that was. Previous in series Next in series [Less]

Table of contents for Django Development with DjbletsDjango Development with DjbletsDjango Development with Djblets: Custom Tag Helpers I’m planning to cover all of what Django can do, but for now, let’s start simple with something most Django ... [More] developers spend way too much time creating: Custom tags. Django’s nice enough to provide a @register.simple_tag decorator for creating very basic tags that don’t take a context but do take parameters. This is great, but what if you want more? Many Django applications use the same boilerplate time and time again to create their tags, but we make it much easier. Introducing @basictag and @blocktag. @basictag Ever wanted to use Django’s @register.simple_tag but needed access to the context? I’ve found far too many cases where this would be useful, but Django doesn’t make this easy. Your tag code would end up looking like this: class MyTagNode(template.Node): def __init__(self, arg1, arg2): self.arg1 = arg1 self.arg2 = arg2 def render(self, context): arg1 = Variable(self.arg1).resolve(context) arg2 = Variable(self.arg2).resolve(context) return context['user'] @register.tag def mytag(parser, token): bits = token.split_contents() return MyTagNode(bits[1], bits[2]) Do this a few times and it’s bound to drive you nuts. How about this instead? from djblets.util.decorators import basictag @register.tag @basictag(takes_context=True) def mytag(context, arg1, arg2): return context['user'] Far less code and increased readability. Hooray! @blocktag @blocktag aims to do the same thing @basictag does but for block tags. A block tag is a tag that contains nested content, like @spaceless or @for. This usually requires even more boilerplate than the above code fragment, except with the added complexity of having to grab the contents of the block. We’ve condensed it down to this: from djblets.util.decorators import blocktag @register.tag @blocktag def blinkblock(context, nodelist, arg1, arg2): return "<blink>%s</blink>" % nodelist.render(context) If you’ve built block tags in the past, you’ll appreciate how simple that was. Previous in series [Less]