openSUSE:Review tools

Jump to: navigation, search

Interactive review with osc

This depends on the just released osc version 0.135 (get it from the openSUSE:Tools repository).

Open up a large terminal window, enter "osc request list -U <your-id> -i" and go through the list. It will show you the submit request and offer you the following options (the letter in (brackets) is the letter to type, e.g. i for diff):


The important options are:

  • diff: Opens your editor with a diff of the changes
  • accept: Accept the review/request (you can give some comment with "-m comment")
  • decline: Decline the review/request. If you requested the diff before, it will open the diff again in your editor and allow you to easily copy and paste some lines to your decline message which will be added at the top of the diff.
  • revoke: Revoke the request
  • buildstatus: Show whether the package has been built.
  • clone: create a new SR cloned from the SR being reviewed.
  • skip: Ignore the review/request for now, go to the next one.
  • cancel: Stop reviewing.
Pay attention to the keys that are used to select "diff" and "decline". You may be tempted to press "d" to show the source diff, and find that after pressing "d" you are faced with the process for declining the SR. Thankfully the "decline" action requires confirmation so that you can abort the "decline" process if you pressed "d" by mistake.

Some examples:

  • osc review list -G opensuse-review-team openSUSE:Factory -i: Review interactively all packages that has an open review for group "opensuse-review-team" and as target project openSUSE:Factory.
  • osc request list -U a_jaeger -i: Review interactively all packages that have an open submit request and that I'm (my user is a_jaeger in the openSUSE Build Service) allowed to approve/decline.

If you're part of a group, you should add to your ~/.oscrc also the option "review_inherit_group = 1". This way, it will not ask you for which group you do the review but take the one you used as command line ("-G opensuse-review-team").

Interactive review with web ui

Visiting the OBS List of Projects shows the list of "Main Projects" at the top. These Main Projects are normally those that are subjected to the Review Processes. Click on the project link that you will be reviewing.

The resulting page is the project summary page. In the "Information" section you will see a link to the "open incidents" which also displays the number of currently open incidents. Click the "open incidents" link. The list of incidents will be displayed.

Generally, as a reviewer, you should review only those that are in the "review" state. All incidents that are in the "review" state are marked with a yellow flag in the "Info" column.

For each SR that you review, start by verifying that all the data in the table indicates that the SR is ready for review. Of particular importance:

  • Verify that the SR has a sane Summary
  • Verify that the patchinfo bug references and CVE references match those listed in the package. (See the "Issues" column.)
  • Ensure there's a green check mark in the "Build" column, indicating that the packages have been successfully built in the maintainer's project.
The details of the review -- how to review, what is accepted and what should be declined -- are not described here, but are discussed in other pages of this Portal.

To do the review, click on the yellow flag. The "Request <SR#> (review)" page is displayed.

The source diff of each package is displayed in the main section of the screen. You can switch to each packages using the tabs at the top of the main section. At least one of the tabs will also be the patchinfo.

You can also view the "build results" and the "mentioned issues" (the bugzilla data) in panes at the right.

As a member of the Review Team, you can add your comments at the top, then press either "accept review" or "decline review". If you would like to skip this review and do it later or allow someone else to review, just press the browser's "back" button.


Missing mention of patches

Please see

=> Added / removed patches need to be mentioned by name in .changes, in
order to get a full trail of life cycles.

Missing or wrong bug number abbreviation

Please see

=> Anytime you have fixed a bug (or implemented the feature), you have to mention the number of bug in changes. As fix should be reported in upstream bugzilla, also add a prefix before the number, so people will know where to find an information. 

The full list of prefixes is available on

Cleaning the buildroot in %install

Please read the thread about "cleaning the buildroot correctly" on
and fix your package ...   Thanks!

Only version number in changes

Please be a bit more verbose in the changes entry ... (not just version number).

Please read for more details about a good changelog entry.