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 GNOME Yourself
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. Garnome is easier, but less up-to-date. 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. jhbuild build from current CVS, so is the most up-to-date method, but can be more difficult. JHbuild has to be checked out of GNOME CVS using the following commands:
export CVSROOT=:pserver:firstname.lastname@example.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 documentation on configuring environment variables and executing gnome-session, in the 'starting/using garnome' section.
You will have to rebuild GNOME every week or two so you are testing the latest software. It becomes easier the second time.
Getting unstable packages of GNOME for your distribution
While building your own is usually preferrable for testing, GNOME packages are available for many distributions, and you can do a lot of very useful work just by using those packages for your daily work and reporting all bugs that you see!
Places to get unstable versions of GNOME for your distribution:
- Ubuntu: just run the 'unstable' version of Ubuntu. Be aware that this may install many other unstable packages.
Gentoo: get the Breakmygentoo overlay. You can use gensync from gentoolkit-dev to make this easier. However if you want something more "stabel" (and more recommended) you can try gnome-experimental, the Gentoo GNOME teams own prerelease overlay. Just use layman or have a look over at http://overlays.gentoo.org and look for GNOME.
add more here!
GNOME relies on the users of GNOME's beta releases to find and report bugs so that the users of the stable release have a bug-free experience. That means it is important to file every bug you find!
You can find bugs mostly by just using GNOME as you normally would, but keeping an eye out for anything that looks wrong to you. You can also read GNOME news sites like footnotes.org or planet.gnome.org to find out about new features, and gives those new features special attention.
As already pointed out, with people filing bugs, GNOME can't get more stable. So it is important to file bugs and file them well.
Telsa Gwynne has good online notes on bug reporting that are really worth a read, in conjunction with her slides.
If the bug is a crash, before filing the bug, you'll want to read GettingTraces, and learn how to get a 'stack trace' of the crash. With the right stack trace information, developers have a much, much better chance of fixing the crash you've found.
Bug reporting is done in bugzilla.gnome.org, or with the 'bug-buddy' bug reporting tool. If you are unfamiliar with Bugzilla, you should read the GNOME bug HOWTO. If you are really stuck, try asking in #bugs on irc.gnome.org and we'll try to help. Be patient! We're busy hunting bugs
Once you've filed the bug, you will get e-mail when it is changed. 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". You can also test FEATURE="splitdebug" if you know what you are doing.
- 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 the next step and helping more
The GNOME bugsquad read and filter (or '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. You can join the bugsquad by joining our mailing list, or stopping by on irc.gnome.org in #bugs and saying hi.
Many bugs will only manifest themselves under conditions particular to certain users, the classic example would be bugs that only happen when assistive technology support is enabled. Try to reproduce different use cases, such as by activating assistive technology support or changing your locale if possible.
Thank you for registering an interest in testing GNOME. I wish you success in compiling it and happy testing!
Credits and Comments
Thanks to Telsa Gwynne and AndrewSobala for writing earlier versions of this document. The current version is maintained by the GNOME Bugsquad; email email@example.com if you have questions or suggestions.