Showstopper Reviews

Purpose

The purpose of "showstopper" reviews is to find the bugs that look the most problematic for our next release(s) and publicize them in an attempt to encourage more people to assist in fixing them. It is not for berating/shaming anyone (if you want to do that, get involved in the tinderbox status reports once those get going), nor for trying to re-prioritize the work of maintainers (while that may sometimes be the side effect of these reports, we'd like to find other people to help the maintainers and bring more eyeballs to the problems if possible). These reports also serve to alert the release team to important issues, and save some of the Bugsquad's rare time.

Getting involved

We need lots of volunteers to create "showstopper" review reports, which ideally would be sent out once every week or two. We try to focus only on the most embarassing of bugs, the kind that could potentially hold up a release, though others not quite that severe often get included. Nearly anyone can do such a review or assist with one. The steps involved look kind of overwhelming at first, but really aren't so bad. You can look at the last reviews to get an idea of the work involved. The steps involved in creating such a report are:

• Make sure no one else is working on a showstopper report

• Write a brief summary of changes since the previous showstopper report

• Copy & update the relevant portions of the old report

• Find new potential showstopper bug reports

• Write up a summary of the new showstopper bugs

• Get others to review your new report

• Send out your report

• Update this page

Making sure no one else is working on a showstopper review

We don't want to duplicate work, so if you decide to work on a showstopper review, please add your information here. Note that if the last report was sent out less than a week ago, then we don't need another one yet. Also, note that if the information here about the volunteer to be in charge of the next review is more than a week old, it should be removed and considered out of date. If no date is listed, the other volunteer information should be considered out of date and removed.

Last reviews:

Writing a brief summary of changes since the previous showstopper report

If the last review was done in the previous two months, a summary of changes since the last report should be included in your new report. Look at the last review, determine which bugs were fixed, which have extra patches, and any other notable activity. Try to summarize this information in a paragraph or less.

Using the relevant portions of the old report

If the last review was done in the previous two months, you need to find out the relevant portions of the old report, so that you can update them and include it in your current report. Fixed bugs obviously need no longer be included; if they were fixed after the last review, add them to the "Changes" section, as already mentioned. Other bugs may need to be excluded for any of a variety of reasons (e.g. one of the maintainers has applied a workaround and says that a correct fix won't be possible until the next release cycle). You will need to read both (a) the bug reports included in the last review, and (b) the responses on the mailing list to the last showstopper review report (Note: You do not have to be subscribed to the desktop-devel-list, you can use the archives at http://mail.gnome.org instead). Both locations may have information about which bugs are still relevant and what information may need to be updated from the old report.

Note that if you find any information on the mailing list that should be in corresponding bug reports but isn't there, please add it to the bug report.

Finding new potential showstopper bug reports

There are lots of ways to find new potential showstopper bugs: your own testing of GNOME, triaging bugs, listening to others on IRC, talking to distribution packagers and maintainers, taking a look at the patch dilegence, searching for bugs with an old gnome-target set, and many other ways. However, all of those methods go above and beyond the call of duty. You are perfectly welcome to do those things, but typically all you really need to do is

• Look for bugs with the appropriate gnome-target set. This page should help you.

and if you want to go the extra mile, then

• Look for bugs with lots of recent duplicates. This page should help you. If you think that some of these bugs should be showstoppers and part of your review, but aren't marked yet, feel free to set the gnome-target for those bugs.

If you think you found a potential showstopper add it to the ../ShowstopperCandidates .

Writing up a summary of the new showstopper bugs

Write up a summary of the new showstopper bugs you have found. Some general guidelines:

• People seem to like the buglist organized by product
• For each bug:
  • Include a short (2-3 sentences at most) summary of the bug is and its impact, especially if the official summary/title of the bug isn't very expressive.
  • Include a direct Bugzilla link to the bug report
  • Include information about the current state of the bug; examples of important state:
    • whether there are patches
    • whether it looks like there are people actively working on the problem

    • whether there is information the maintainers are looking for to help them fix the bug faster (note that if the developers need extra information to be able to work on the bug, then it probably does not belong on the showstopper report)

    • whether the bug is blocking on another bug
• Do not include these things in your report
  • action items (this is a review of existing problems, not an agenda or tasklist)
  • questions/comments directed at individuals

    [AndreKlapper]: I beg to differ with the last two ones. One sometimes has to be snappy and pushy. I'm not here to make new friends, but to see some progress.

• Try to keep any information outside the buglist, such as basic information about why/how/when you're making the showstopper list, to a minimum

• Include a link to the list of current blockers (namely https://bugzilla.gnome.org/buglist.cgi?query=gnome-target:2.even.x with even replaced by the appropriate even number)

Getting others to review your new report

Send the draft of your report to the bugsquad mailing list and maybe to distributor-list. Others may point out improvements to make to the wording and bugs that really shouldn't be on the list. They may also point out bugs that should be on the list, though you can feel free to tell them that they should just set the appropriate gnome-target of the corresponding bug so that it can show up in the next report. If no one responds within 24 hours, feel free to just move on to the next step.

Sending out your report

Email your report to the desktop-devel-list (d-d-l) and release-team (r-t) and maybe to distributor-list.

Updating this page

Go back to the section on making sure no one else is working on a showstopper review and update all the relevant information (e.g. remove your name and the date you started, update the last review link, etc.).

We haven't had a lot of showstopper reviews yet. These guidelines may need to be updated in response to feedback from d-d-l.