next-review 1.3.0

Installation

From PyPi:

$ pip install next-review

Usage

If you can use git-review, you can probably use next-review. Assuming you’re watching some projects in gerrit, have an SSH key public key somewhere obvious and your login name matches your gerrit username, you can just do:

$ next-review
https://review.openstack.org/20404 Use AuthRef for some client fields

The link will be automatically opened for you, because that’s how lazy I am.

You can also abuse the return code to see how many reviews you have left to go until it’s time for beer and/or sleep:

$ echo $?
5

Or, you can just view the entire list without automatically opening any links:

$ next-review --list
https://review.openstack.org/20404 Use AuthRef for some client fields
https://review.openstack.org/26665 Fail-safe mechanism: issue unscoped token if user's default project is invalid.
https://review.openstack.org/29878 A minor refactor in wsgi.py
https://review.openstack.org/29393 bp/temporary-user-provisioning
https://review.openstack.org/30386 Add name arguments to keystone command.

Configuration File

next-review has the concept of a multi-section (ini-style) configuration file. The default location it looks for it is ~/.next_review. In this configuration file the default section is [DEFAULT] and the following options are supported: host, port, username, email, key, and projects. These values will override the defaults, but any cli-arguments that are explicitly set will take precedence over the config file.

If you specify sections other than [DEFAULT] you can use the --config-section argument to specify the section that should be used. If a given option does not exist in the specified section, the parser will look in [DEFAULT] and if the option does not exist in either section, it will fall back to the global defaults. So the order of precedence would be option passed on the command line, options in the section specified by the --config-section argument, options in the [DEFAULT] section, and finally the global defaults.

Philosophy

1. Older changes should be reviewed first.

2. If Jenkins is failing a change, then the author has work to do.

3. If SmokeStack is failing a change, then the author has work to do. If SmokeStack hasn’t reviewed a change, that’s okay… SmokeStack is lazy, too.

4. If a change is already blocked by a core reviewer or marked WIP or Draft, then it’s not going to merge right now anyway.