The Introduction of this book discussed what the Fedora Project is all about and how it is different than a typical Linux distribution. If you have forgotten, Fedora is a Red Hat “sponsored, community-supported, open source project. In fact, the motto of the project is, Openness. Participation. Quality. Change. Disagreement. Opportunity. Community. That is wonderful, but how exactly does this impact you? Quite simply, you have the power to help improve the Project on many fronts, from finding and reporting bugs to contributing new code and patches to writing tutorials and documentation. And that is the type of power and flexibility that you don t have with most other Linux distributions.
This chapter examines the development, testing, and release process for the Fedora Project and how you can possibly make contributions. The chapter begins with a look at the available mailing lists to learn about and find potential issues and then moves on to using the Fedora bug tracking system to submit bug reports . Then, you learn how to submit patches, bug fixes, and documentation to the Project. Unfortunately, at this time, the public- facing Fedora development infrastructure, most notably the source code repository, is still in its infancy and is not available. As a compromise, however, we will play around with the GNOME source code repository, so you can get a feel for interacting with a repository. You can use this knowledge to contribute to the Fedora Project when the necessary infrastructure becomes a reality.
For a project the size of Fedora to be a success, there needs to be a large number of casual users, testers, and developers all working in parallel, communicating with each other, and reporting their experiences. Fortunately, the Project coordinators, which include Red Hat staff and management, set up a number of avenues that allow for this type of interaction, ranging from mailing lists and Internet Relay Chat (IRC) channels to publicly available bug tracking mechanisms.
Mailing lists are a wonderful medium for communicating with a wide variety of people, from the casual new user to the core developer, all from the comfort of your favorite e-mail client. Using the mailing lists, you can do the following:
Follow discussions of Fedora users and testers
Learn of possible problems with Fedora releases
Pick up tips on how to solve certain issues
Receive announcements of new software
Contribute your knowledge and solicit suggestions from other users about your specific obstacles
A number of Fedora- related mailing lists are available, and you can find more information at www.redhat.com/mailman/listinfo .
The following table lists a number of Fedora-related mailing lists.
List Name | Description |
---|---|
fedora-announce-list | Announcements of Fedora Core changes and events |
fedora-list | For users of Fedora Core releases |
fedora-test-list | For testers of Fedora Core test releases |
fedora- devel -list | For developers |
fedora-docs-list | For participants of the docs project |
fedora-desktop-list | For discussions about desktop issues, such as user interfaces, artwork, and usability |
fedora-config-list | For discussions about the development of configuration tools |
If you want to subscribe to a specific mailing list shown in the preceding table, you can send an e-mail to < listname > -request@redhat.com , where < listname > is the name of the list, with the word subscribe in the subject. You should be aware that most of these lists generate a tremendous amount of traffic, which might fill up your mailbox rather quickly. If you are not quite ready for this type of barrage, you can always peruse the list archives via a Web interface at the URL mentioned. Unfortunately, the Web interface will not allow you to post messages to the list.
Now that you know how to get involved with the mailing lists, you should spend some time reading through the recently archived messages. You will not only gain a much deeper insight into the Fedora releases, but might also find solutions to any problems or issues you are experiencing.
As you can see, Fedora users are discussing a wide number of issues; this is pretty typical for the Fedora lists. If you are interested in posts on a specific problem that you may be experiencing, you can use the search form to see whether other users have run into something similar. If you cannot find any relevant posts, you can post a new message to the list. With the number of people reading the lists, including Fedora developers, you will most likely receive a response indicating a possible solution or workaround. And if you don t receive a response, at the very least, your post will be archived for other users to find at a later time.
The next step is to check whether someone has filed a formal bug report with the Project that is similar in nature to the problem you are experiencing. You can do this using the Fedora bug tracker.
As you may have guessed, a bug tracker (also known as an issue or defect tracker ) is an application that allows project staff to keep track of not only bugs, but also requests , enhancements, and whatever else circulates throughout the project. In this respect, a bug tracker is very different than a mailing list; every issue is typically tracked from submission to resolution.
Here is an overview of the typical defect tracking process. When a defect is found, a tester records the bug into the tracker, along with any necessary steps to reproduce the problem. At this point, a project manager gets involved to determine whether the defect is valid and, if so, assigns responsibility to a single developer or a staff of developers. The developer is then responsible for fixing the problem and notifying the project manager, who will then certify the resolution and close out the issue.
A plethora of commercial and open source bug tracking applications are available, most of which have very similar functionality and interfaces. This section looks at one system, Bugzilla, which is used by Fedora, as well as the KDE and GNOME projects. Go ahead and look at a random bug submitted against the Fedora Core 2 test 2 release, so you have a better understanding of what a typical bug report looks like. Go to the following:
https://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=119854
As you can see, a typical bug report contains a lot of valuable information, including the hardware platform and the product, version, and component where the user experienced the problem, as well as all of the problem details.
Perhaps you are experiencing crashes when exiting from the Evolution e-mail client on Fedora Core 2 release. Before you file a new bug report, go to https://bugzilla.redhat.com/bugzilla/easy_enter_bug.cgi .
Use the form you find at this URL to search for possible bug reports that are similar in scope to the problem you are experiencing.
Because you cannot find any bugs that are similar in scope to your problem, continue on to the next step to create a Bugzilla account, from which you can file a bug report.
Create a Bugzilla account by going to https://bugzilla.redhat.com/bugzilla/createaccount.cgi .
All you need to do is enter your name and a legitimate e-mail address. Bugzilla creates an account and sends a randomly generated password via e-mail.
After you have the necessary Bugzilla authentication credentials, you can log in to the bug tracker. Once there, proceed to the product selection page to start the bug submission process: https://bugzilla.redhat.com/bugzilla/easy_enter_bug.cgi?action=second .
Select Fedora Core from the component menu on the left-hand side, and then click the Submit button at the bottom of the page to continue to the next step.
You need to select a component. Luckily, the evolution component is easily found. However, in cases where you cannot find the component that matches your application, you can use the rpm command, with the -qif switches, to determine the associated component, like so:
# rpm -qif /usr/bin/evolution grep 'Source RPM' Group: Applications/Productivity Source RPM: evolution-1.5.3-1.src.rpm
The component name is the string noted by Source RPM without the version information.
Now, choose the version and platform. Go ahead and select test1 as the Fedora version and your hardware as the architecture ”typically i386 , i586 , i686 , or athlon . Then, press the Submit button to enter the bug description.
Enter the summary, version release, description, reproducibility , steps to reproduce, and the severity level for the bug. The following table provides an example.
Field | Value |
---|---|
Summary | Evolution client crashes on exit |
Version Release | 1.5.3-1 |
Description | Evolution client crashes every time on exit with error 2 |
Reproducibility | Every time |
Steps to Reproduce | 1) Launch the evolution client, and 2) try to exit from the application |
Severity Level | High: crashes, loss of data, severe memory leak |
Click the Open Bugzilla Entry Form button and then the Commit button on the ensuing page to submit the bug report. As the Fedora developers investigate your bug and change the status of the bug from NEW to VERIFIED to ASSIGNED, and then, one hopes, to RESOLVED and CLOSED, you will receive e-mail messages from Bugzilla. You can then log in and see more information about the progress of the bug.
To recap, bug tracking applications allow project staff to quickly understand and analyze the state of the development process because they can track the issues that have been raised, the components or subsystems that are involved, the severity level of the issues, and how the issues have been resolved. If you are interested in setting up your very own bug tracker, take a look at the Request Tracker application, which is covered in Chapter 15.
Now that you know a bit about the Fedora development process, the next section covers source code control and the concept of code repositories, so you can actually take a look at the code behind the Fedora Core operating system.