Infrastructure/Review Board: Difference between revisions

    From KDE TechBase
    (→‎Using post-review to post changes for review: add corresponding package name for debian/ubuntu)
    (6 intermediate revisions by 4 users not shown)
    Line 27: Line 27:
    === Using post-review to post changes for review ===
    === Using post-review to post changes for review ===


    Once you are done with the above, it is time to post the changes to ReviewBoard. The easiest and most comfortable way to do that is <tt>[http://www.reviewboard.org/docs/manual/dev/users/tools/post-review/ post-review]</tt>, a handy command line tool which takes care of creating review requests for you. This is normally in a package called RBTools (openSuse has a 1-click package in the [http://software.opensuse.org/search?q=rbtools devel:tools repository])
    Once you are done with the above, it is time to post the changes to ReviewBoard. The easiest and most comfortable way to do that is <tt>[http://www.reviewboard.org/docs/manual/dev/users/tools/post-review/ post-review]</tt>, a handy command line tool which takes care of creating review requests for you. This is normally in a package called RBTools, available as [http://software.opensuse.org/search?q=rbtools <code>rbtools</code> in OpenSuse's devel:tools repository] and [apt://python-rbtools <code>python-rbtools</code> in Debian/Ubuntu].


    ==== Prerequisites ====
    ==== Prerequisites ====
    Line 45: Line 45:


    If your <tt>origin</tt> remote was already using the git:// url, substitute <tt>anonupstream</tt> with <tt>origin</tt> throughout the rest of this tutorial.
    If your <tt>origin</tt> remote was already using the git:// url, substitute <tt>anonupstream</tt> with <tt>origin</tt> throughout the rest of this tutorial.
    If you used a <tt>kde:</tt> prefix for your git remotes, post-review won't expand it (it uses <tt>git config --get remote.origin.url</tt>).
    This can be fixed by editing 
    <tt>/usr/local/lib/python2.7/site-packages/RBTools-0.4.1-py2.7.egg/rbtools/clients/git.py</tt>
    and at the end of the function "def get_origin", adding the following line before the return line:
    <tt>origin_url = origin_url.replace("kde:", "git://anongit.kde.org/")</tt>


    ==== Creating the review request ====
    ==== Creating the review request ====
    Line 61: Line 68:


      post-review --parent=master --tracking-branch=anonupstream/master -r 54
      post-review --parent=master --tracking-branch=anonupstream/master -r 54
    ==== Create a convenient git alias ====
    To reduce the typing needed you can create a git alias with the options you use for post-review. Add the line
    below to the <tt>[alias]</tt> section of your ~/.gitconfig file.
    post-review = !post-review --guess-summary --guess-description --username=<YOUR USERNAME> --parent=master --tracking-branch=anonupstream/master
    Now you can submit a committed patch for review by just typing
    git post-review
    If you want to amend an already existing review request just add <tt>-r NUM</tt> to the end of the command.


    ==== Creating a ReviewBoard-compatible diff ====
    ==== Creating a ReviewBoard-compatible diff ====
    Line 70: Line 90:
    === Closing a review request ===
    === Closing a review request ===


    To close a review request, you can either use the ReviewBoard web interface or more conveniently, right in a commit. This is done by using the REVIEW keyword followed by the review ID you want to close. For example, to close review 54, you would put
    A review request can be closed in two ways. Either the user who opened the review request can use the ReviewBoard web interface. Or you close the review right in a GIT commit. This is done by using the REVIEW keyword followed by the review ID you want to close. For example, to close review 54, you would put


      REVIEW: 54
      REVIEW: 54


    in your commit. A message will also be posted to ReviewBoard indicating the commit SHA1 that closed the request.
    in your commit. A message will also be posted to ReviewBoard indicating the commit SHA1 that closed the request. Please note that this only works for GIT commits, and not for Subversion commits.
     


    == Using Review Board With Subversion ==
    == Using Review Board With Subversion ==

    Revision as of 04:59, 11 September 2012

    KDE Review Board

    KDE currently uses the Review Board software for performing reviews on code changes.

    There are separate versions of Review Board for use with Git and Subversion:

    Note that http://reviewboard.kde.org/ redirects to the Git version.

    Using Review Board and post-review with Git

    Every Git Project repository has its own entry on the KDE Git Review Board.

    Creating your changeset

    To create your changeset, you probably want to work in a separate branch - or even in your clone. This is actually suggested and the proper way to do changesets in Git. You can create any number of commits, amend them, and do whatever you want to do - it won't affect the next steps, as you will submit the whole branch for review.

    Before proceeding it is good practice to rebase your branch onto the branch you want to target for the merge. So, supposing you want to target master, make sure it is up-to-date with the remote and then run, and want to publish a review for a local branch:

    git pull --rebase
    

    If you want to post a review for merging a non local branch, you might want to run the following:

    git merge master
    

    Using post-review to post changes for review

    Once you are done with the above, it is time to post the changes to ReviewBoard. The easiest and most comfortable way to do that is post-review, a handy command line tool which takes care of creating review requests for you. This is normally in a package called RBTools, available as rbtools in OpenSuse's devel:tools repository and [apt://python-rbtools python-rbtools in Debian/Ubuntu].

    Prerequisites

    The following has to be done only once to make your local clone fit for use with post-review.

    First of all, you have to tell it about the ReviewBoard server. If your project does not ship with a .reviewboardrc file (encourage the project manager to add one!), the first thing you have to run is:

    git config reviewboard.url https://git.reviewboard.kde.org
    

    ReviewBoard currently only knows the project repositories by their git:// URLs, making it necessary to have a remote using the git:// URL in your clone. If your origin remote is already using the git:// URL, you are all set. If not you need to add another remote now.

    Let's suppose you are looking to have some changes to Amarok reviewed, and the URL of your origin remote is [email protected]:amarok. To add another remote using the git:// URL you might run:

    git remote add anonupstream git://anongit.kde.org/amarok
    git fetch anonupstream
    

    If your origin remote was already using the git:// url, substitute anonupstream with origin throughout the rest of this tutorial.

    If you used a kde: prefix for your git remotes, post-review won't expand it (it uses git config --get remote.origin.url). This can be fixed by editing /usr/local/lib/python2.7/site-packages/RBTools-0.4.1-py2.7.egg/rbtools/clients/git.py and at the end of the function "def get_origin", adding the following line before the return line:

    origin_url = origin_url.replace("kde:", "git://anongit.kde.org/")

    Creating the review request

    You are now ready to create the review request. The post-review command should look something like this:

    post-review --parent=master --tracking-branch=anonupstream/master
    

    This command tells post-review that your branch is based upon master, and it is set to track the remote branch anonupstream/master. You can also give post-review some more arguments to avoid using the web interface later - have a look at the user manual for more on that.

    After the command has been run a web address will be shown in the terminal, pointing at your review request.

    Updating a review request

    If you need to update an existing review request you can invoke post-review with an additional -r argument, which should be the numeric id of the review request you want to update. Supposing you want to update review request 54, you would run:

    post-review --parent=master --tracking-branch=anonupstream/master -r 54
    

    Create a convenient git alias

    To reduce the typing needed you can create a git alias with the options you use for post-review. Add the line below to the [alias] section of your ~/.gitconfig file.

    post-review = !post-review --guess-summary --guess-description --username=<YOUR USERNAME> --parent=master --tracking-branch=anonupstream/master
    

    Now you can submit a committed patch for review by just typing

    git post-review
    

    If you want to amend an already existing review request just add -r NUM to the end of the command.

    Creating a ReviewBoard-compatible diff

    In some rare cases you simply want to generate a diff and submit it to ReviewBoard later. You can do that by running:

    post-review --parent=master -n > your-patch.patch
    

    Closing a review request

    A review request can be closed in two ways. Either the user who opened the review request can use the ReviewBoard web interface. Or you close the review right in a GIT commit. This is done by using the REVIEW keyword followed by the review ID you want to close. For example, to close review 54, you would put

    REVIEW: 54
    

    in your commit. A message will also be posted to ReviewBoard indicating the commit SHA1 that closed the request. Please note that this only works for GIT commits, and not for Subversion commits.

    Using Review Board With Subversion

    Not all KDE Subversion projects use Review Board so first you need to check if the project you've created the patch for is actually using reviewboard. For this, go to the groups section and see if the project's group is listed there. If it is listed there, you should use the reviewboard, otherwise send the patch by other means.

    For sending a patch, you first need to register. Then simply click New Review Request and fill out the form. The most important parts of the form are:

    • The actual patch. You need to upload the patch you've created earlier here
    • The SVN base path. This is needed for the inline patch display to work. This can be a bit tricky, if you are unfamiliar with KDE's SVN layout, check WebSVN. For example, if you're svn diff'ing from /path/to/your/copy/of/kdelibs/cmake/modules, the base path should be /trunk/KDE/kdelibs/cmake/modules. If you still don't know the correct base path, ask a developer on IRC. You can also edit the review request later.
    • A summary of the patch. This should be short, it will show up as subject of the notification emails.
    • A description of the patch. This can be longer.
    • The group(s). Make sure you enter the correct group ID here, as seen earlier on the groups page.

    After you completed the form, a notification mail will be sent to the developers and they will answer you.

    /!\ You need to use svn diff in english, if your system is not english, please do LC_ALL=C svn diff