Testing GNOME

Introduction

GNOME needs beta-testers. Beta-testers are the people who make sure that a released version of GNOME works, and doesn't have any critical bugs. The more people who beta-test GNOME, the less chance of a major bug slipping into a stable release. This document aims to help guide people beta-testing GNOME.

Building it

gnome.org does not ship binaries, only source, and distributions do not normally package beta software. You'll have to build GNOME from source. To do this, you'll need a machine with a fair processor and quite a bit of time. Unstable releases of GNOME are designated by an odd number y in the release numbering system x.y.z.

The 2 most popular ways of building GNOME are:

Of the two, Garnome is the easiest but less up to date.

You will have to rebuild GNOME every week or two so you are testing the latest software. It becomes easier the second time.

When you start GNOME in a different prefix for the first time, you may have to move away the $HOME/.gnome2/session file.

Testing it

Because so many fewer users test beta GNOME software compared to those using stable GNOME software, it is more important to file bugs. This is because it is less likely that someone has already filed your bug, and if the issue goes unknown GNOME could ship with it unresolved.

Telsa Gwynne has good online notes on bug reporting that are really worth a read, in conjunction with her slides. The GNOME bug reporting system is Bugzilla, or you can use bug-buddy. Bug-buddy is especially useful for reporting crashes, since it gets a stack trace.

If you are unfamiliar with Bugzilla, you should read the Bugzilla documentation. If you are really stuck, try asking in #bugs on irc.gnome.org and we'll try to help.

You will get e-mail from bugs you report. If you are asked for more details, please respond or the developers will be helpless.

It is useful, but not essential, to search bugzilla for the issue before reporting it. If you find it, you can add that you see the issue too (which helps the bugsquad to judge the impact of the bug) and can add yourself to the Cc list if you want to track its progress. Ultimately, it is more important to report bugs to bugzilla than be afraid of re-reporting an existing bug.

Please report bugs when you find them. Otherwise, you may forget, or the information you provide may be inaccurate.

Gentoo

Lots of people like gentoo. If you use gentoo, you must remember a few things when beta testing.

  1. Do not optimise your packages. This can cause crashes and ruin stack traces.

  2. Add "nostrip" to your FEATURES line in /etc/make.conf if you are compiling beta GNOME using Gentoo's emerge tool. When you report a bug, please include the output of "emerge info".

  3. Bugs may be caused by gentoo packaging problems. Many packages in gentoo are configured in non-standard ways. This can cause problems that appear to be GNOME, but are actually something else. There is not much we can do about this.

Going further

The bugsquad triage all the bugs reported to bugzilla. If you are a regular bug reporter, and you want to contribute further, the bugsquad is a logical progression. Please stop by on irc.gnome.org in #bugs if that's the case. You may have to wait a while before anyone responds; this is normal!

Thank-you

Thank you for registering an interest in testing GNOME. I wish you success in compiling it and happy testing!