Introduction to Free Software - SELF | Sharing Knowledge about ...

© FUOC • P07/M2101/02709 124 Free Software
confirm the request, it will automatically find out the version of the package
and those on which it depends, in addition to the kernel's version and archi-
tecture. Obviously, it knows the e-mail address, so it sends to the correct site
a similar report to the following:
Package: w3m-ssl Version: 0.2.1-4 Severity: important After reloading a page containing complex tables sever
This message generates a bug number which is returned to us, sent to the
maintainer and saved in the database. When the bug is solved, we will also
receive a notification. Every bug has an e-mail address assigned to it that can
be used to provide additional information, for example. We can consult the
bug database http://bugs.debian.org at any time.
Sometimes bug monitoring systems have mechanisms for assigning someo-
ne to solve them and setting a deadline. There are also other issues, such as
pending jobs, requested improvements, translations, etc., that require similar
management mechanisms. With free software we cannot generally use very
rigid mechanisms for managing the tasks that each developer has to do. After
all, many collaborators are volunteers and cannot be obliged to do anything.
Nonetheless, tasks can be defined and we can wait for somebody to subscribe
to the system and to take them on within a declared period. Whether there is
control over what certain people can do or not, it is always advisable to con-
trol all the tasks that need to be done, who and what they depend on, their
level of importance, and who is working on them. Many important projects
manage these aspects using Bugzilla (The Bugzilla guide) [89] or its derivatives.
Sometimes someone working on a project may discover a bug on a different
project on which his work depends, but that has a different bug management
system to the one to which he is accustomed. This is particularly true for users
of distributions who wish to use a single tool for reporting and monitoring
bug solving. To facilitate reporting and monitoring of those bugs, it may be
advisable to federate different systems, as done by Malone (The Malone Bug
Tracker) [47].
8.8. Support for other architectures
The minimum support required for working with a portable program is access
to compilation farms , which allow the program to be compiled on different arc-
hitectures and operating systems. For example, SourceForge (vid. section 8.9.1)
offered for a time Debian GNU/Linux environments for Intel x86, DEC Alpha,
PowerPC and SPARC, in addition to Solaris and Mac OS/X environments.
It is also useful to be able to test (not just compile) the program in tho-
se environments. But this service requires more resources and more of the
administrator's time. The compilation service can already be problematic, be-
cause normally we need to provide compilation environments for several lan-
guages, with a large number of libraries. If what we want to do is to test any