The Official GNOME 2 Developers Guide

9.1 Reading, Discussing, and Collaborating

You can begin your foray into the GNOME community by digging up more GNOME information and finding ways to communicate with other GNOME enthusiasts .

Perhaps you feel obliged to give something back to the GNOME Project in return for all of this software available under a free license. Or you may have a practical reason to work with GNOME ” maybe a piece of software that you're using doesn't work quite right, or something is missing.

Whatever your goal, there are many ways to start exploring the GNOME community. Check out http://www.gnome.org/resources/ .

9.1.1 Real Life

GNOME Project volunteers and several companies are regulars at large computer trade shows, especially those that pertain to free software. In addition, a GNOME Users and Developers Conference (GUADEC) takes place every year.

For more details, see the GNOME website; check out the event calendar at http://www.gnome.org/resources/calendar.html .

9.1.2 WWW

Most of the available GNOME resources are on the World Wide Web. Because of GNOME's broad international base and the range of component projects, countless GNOME- related sites are spread across the Internet.

The primary GNOME website is http://www.gnome.org/ , and this is where you should start to find other resources, such as the GNOME FAQ, information on how your company can support GNOME, and a list of developers.

GNOME Foundation

The GNOME Foundation is a nonpolitical, nonprofit , democratic group registered in California. Take a look at the charter and by-laws at http:// foundation.gnome.org/ to get an idea for what the foundation does. If you get deeply involved with GNOME, you can become a voting member and run for official posts.

News

FootNotes ( http://www.gnomedesktop.org/ ) is a semi-official user - maintained GNOME news site. In addition to the latest general announcements, you'll find weekly summaries, CVS activity statistics, and Bugzilla activity.

Software Downloads

The central GNOME software distribution site is http://download.gnome.org/ . Refer to Appendix D for information on how to choose software.

For a directory of all third-party GNOME software, go to http://www.gnome . org/softwaremap/ . If you're looking for something particular, this is the first place to start, and if you're writing an application, you should add an entry here.

RDF site summary (RSS) information is available from http://ftp.gnome.org/ pub/GNOME/LATEST.xml . Use a program such as Straw to view this information.

GNOME Bugzilla

One of the most important resources for GNOME users and developers is the GNOME bug-tracking system, GNOME Bugzilla ( http://bugzilla.gnome.org/ ). If you have perused ChangeLog in any package, you may have already seen entries such as "Fixes #88325" and "fix mem leak (bug #72976)." The numbers here are Bugzilla indices that you can look up in Bugzilla.

You get a new bug number when you submit a problem report with GNOME Bugzilla or Bug Buddy ( Applications > Programming > Bug Report Tool ). To help manage the report, Bugzilla creates these fields:

• Product: The package containing the problem (for example, nautilus).

• Component: The piece of the package with the problem. The component depends on the product; for example, Documentation is a component of the Nautilus package, and General is a default, catch-all component.

• Short Summary: A very short summary of the problem.

• Opened by: The person who reported the bug.

• Long Description: A detailed description of the problem, including how to replicate the issue. You can add to the description later and include files (as attachments similar to an email attachment).

• Status: One of the following:

  • UNCONFIRMED: No one has confirmed that this is actually a bug yet. Bugzilla users with sufficient privileges can change this status to NEW if they confirm the bug or to RESOLVED if they address the problem immediately.

  • NEW: Someone confirmed the bug, but no one has taken responsibility for it yet.

  • ASSIGNED: Someone has decided to fix the bug.

  • NEEDINFO: There's some trouble in fixing this bug, and the person who originally reported the bug needs to provide more information.

  • RESOLVED: Someone fixed the bug, and the person who reported the bug should verify the fix.

  • REOPENED: There are still some issues involving a bug that was resolved.

  • VERIFIED : Someone has verified that the bug fix works.

  • CLOSED: The bug is completely dead (there is no reason for further action).

• Severity: Indication of how bad the bug is:

  • Blocker: The problem prevents a new release of the package.

  • Critical: This is a severe problem that leads to crashes and data loss.

  • Major: The problem makes most of the package unusable.

  • Normal: The problem makes only a small part of the package unusable.

  • Minor: The package is usable, but the bug is still visible enough to cause errant behavior.

  • Trivial: The problem doesn't affect the way the package works; it's just annoying (a typographical error, for example).

  • Enhancement: This isn't a true problem, but rather, a suggestion on how to make the package better.

• Priority: Indication of how quickly the bug should be fixed:

  • Immediate: As soon as possible.

  • Urgent: Before the next release.

  • High: Before the next major public release.

  • Normal: Soon.

  • Low: Whenever.

• Target Milestone: The version release that should include a fix.

• Resolution: A hint on a resolved bug:

  • FIXED: Someone fixed the bug.

  • WONTFIX: No one can or will fix the bug, ever.

  • LATER: Later versions will include a fix.

  • REMIND: The bug will probably reappear in later versions.

  • DUPLICATE: Someone already reported the bug (supply this bug's number in the duplicate's description).

  • INCOMPLETE: No one could reproduce the bug.

  • NOTGNOME: This bug has nothing to do with GNOME.

  • NOTABUG: "That's not a bug, it's a feature!" There's no reason to "fix" this, especially if it's not a problem.

• Operating System/Details: The platform and version where the bug appears.

• Assigned To: The person responsible for fixing the bug.

• Depends: If the bug can't be fixed until other bugs are fixed, this is a list of the other bugs .

• Blocks: Numbers of bugs that can't be fixed until someone fixes this bug.

A large portion of GNOME development is channeled through Bugzilla because it manages all problems and most smaller ideas. The person who reports a bug gets any changes and additions to the original description via email. If you want to work on GNOME, you should register with Bugzilla; it requires nothing other than a valid email address.

For more information on Bugzilla, see [Barnson].

Developer Home

The GNOME Developer's Site is http://developer.gnome.org/ . Here, you can find news, documentation, current projects, and more. Here are some projects that may especially interest you:

• GNOME Documentation Project ( http://developer.gnome.org/projects/gdp/ ): This project provides GNOME documentation of every kind, including a table listing current package documentation status.

• GNOME Usability Project ( http://developer.gnome.org/projects/gup/ ): In addition to the GNOME usability guidelines and standards, this project provides a testing system that runs through GNOME's CVS tree and extracts information about user interfaces.

• GNOME Accessibility Project ( http://developer.gnome.org/projects/gap/ ): This project provides GNOME access to those with disabilities .

• GNOME Translation Project ( http://developer.gnome.org/projects/gtp/ ): This project aims to translate GNOME software to other languages. It includes a status report with an entry for each package; the goal is to make each entry "100% translated."

• GNOME Webhackers ( http://developer.gnome.org/projects/gwh/ ): Here, GNOME Webhackers build and maintain the various GNOME websites .

GTK+

If you're a GNOME enthusiast, you should visit the GTK+ website ( http://www.gtk. org/ ) from time to time.

9.1.3 Mailing Lists

The most important channels for GNOME discussion are perhaps mailing lists. Go to http://mail.gnome.org/ and see if the lists there interest you.

Announcement Lists

These lists serve only to distribute information and are not meant as a means of discussion. Don't reply to mail that you may get from one of these lists, and don't try to send anything to the lists.

• gnome-announce-list: General GNOME announcements, such new package releases. GNOME summaries come across this list as well.

• foundation-announce: GNOME foundation announcements.

• cvs-commits-list: Alteration logs for everything in the GNOME CVS source tree.

Discussion Lists

• gnome-list: General GNOME discussion.

• gnome-love: General discussion for those who are interested in getting involved with GNOME.

• gtk-list: General GTK+ discussion.

• gtk-app- devel -list: GTK+ application development.

• desktop-devel-list: General discussion of desktop applications and related areas.

• gnome-accessibility-list: Discussion of accessibility issues (ATK, interface development, and so on).

• gnome-doc-list: Documentation issues.

• gnome-il8n: Internationaliztion discussion.

• garnome -list: Discussion for those who use the GARNOME (A GNOME distribution; see Appendix D).

9.1.4 IRC

There are Internet relay chat (IRC) channels for real-time GNOME discussion. The GIMPnet server at irc.gimp.org has discussions on GNOME, GTK+, and GIMP. The following channels are always available:

• #gnome: General GNOME topics.

• #gnome-help: Help with GNOME.

• #bugs: Interactive problem hunt. If you find a bug in GNOME and have some time, come here and see if the experts that hang out on this list can fix it. Sometimes there are Bug Days ” meetings where everyone is asked to report as many bugs as possible. Look on GNOME news pages for announcements.

• #gtk+: General GTK+ discussion.