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.
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:
Garnome. This is an automated build system to build from released tarballs. Simply download the version for an unstable release and type "make" (after reading the documentation). Garnome installs GNOME into a different prefix, so it won't interfere with your current installation.
jhbuild will build from current CVS. This has to be checked out of GNOME CVS using the following commands:
export CVSROOT=:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome
cvs -z3 co jhbuild
Read the documentation. jhbuild will install GNOME into a prefix of your choice. To start the modified GNOME, read the Garnome page for documentation on configuring environment variables and executing gnome-session.
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.
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.
Lots of people like gentoo. If you use gentoo, you must remember a few things when beta testing.
Do not optimise your packages. This can cause crashes and ruin stack traces.
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".
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.
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 for registering an interest in testing GNOME. I wish you success in compiling it and happy testing!