Distributions
Fedora and bug tracking
Bug reports are a blessing and a curse: not enough and the software project misses out on vital feedback; too many and the project is overwhelmed or loses the signal to the noise. Recently, a peculiar discussion in the Fedora community highlighted the difficulty of wrangling bug reports for distributions, which are often the final "downstream" project in the free software deployment hierarchy.
Jóhann Guðmundsson proposed that Fedora move away from the
Red Hat Bugzilla (on which Fedora has relied since the project's
inception). But he did not propose setting up a standalone Fedora bug
tracker; rather, he suggested adopting " He cited three
reasons. First, many package maintainers feel that their bug reports
go ignored by the upstream project if they are reported downstream.
Second, the Fedora package maintainer frequently is not a developer,
so he or she cannot fix the bug, which must eventually find its way
upstream in order to get the proper attention (at the cost of
increased latency). Third, neither of the aforementioned problems
would solved by Fedora running its own issue tracker.
Guðmundsson's proposal was met with near-universal
disagreement; Fedora contributors do not need to worry that their
bug tracker will be going away any time soon. But the debate in the
list thread is an interesting read for what it reveals about the
hassle of cultivating and managing bug reports.
The primary objections to Guðmundsson's proposal were of a
distribution-development nature, pointing out (for example) that there
are always a significant number of bugs in Fedora which do not
belong upstream. User nonamedotc pointed out that there are
always bugs caused by Fedora-specific combinations of libraries or the
particulars of the distribution's builds. Jan Wildeboer said
that Fedora itself develops its own components (starting with the
installer) which have no upstream project, and that the
distribution needs a place to track
blockers and critical bugs that are part of preparing each Fedora release.
Tracking release status mandates having one centralized place to view
all of the outstanding bugs in the distribution.
On those technical grounds alone, there would seem to be no chance
that Fedora would do away with its bug tracker. But Guðmundsson replied that Fedora
already has an incomplete picture of all of the outstanding bugs
because there are always bugs that are only reported upstream.
Indeed, one of the points of agreement was that having separate bug
trackers for the distribution and the upstream project is an ongoing
challenge that needs addressing. Fedora tries to maintain good
relationships with its upstream projects; staying in sync as much as
possible while not inundating them with Fedora-specific bugs.
Wildeboer argued that sending Fedora
bug reporters directly to upstream projects would have a damaging
effect on Fedora's relationship with those other projects:
Along the same lines, Michael Schwendt said that there are upstream developers
who make use of the reports in Fedora's Bugzilla, both for the big
picture" and to examine specific details like stack traces. If, as
Guðmundsson had suggested, there is a breakdown in communication with
the upstream project, then that is a problem that needs fixing by
package maintainers, triagers, and testers.
Dan Horák suggested that Fedora
needs a tool that can clone a bug report from Fedora's Bugzilla to an
upstream repository. Right now, developers and package maintainers
can copy a bug manually over to the upstream project's issue tracker,
but it is a time-consuming ordeal. That suggestion met with some
approval, although it was quickly pointed out that auto-populating an
upstream project's bug tracker would certainly not be a good idea.
The goal should be to reduce the amount of work for the packager, not
to automate the cloning. As Jakub Jelinek pointed out, an automated clone of a bug
can propagate excess information—in particular, he criticized
the bug reports pushed upstream by Debian, which frequently include
mail headers and list discussions from that distribution's email-based
issue tracking system.
The other difficulty with establishing links from Fedora bugs to
upstream bug trackers is, as Bill Nottingham observed, that not every upstream project has
a bug tracker—or, at least, a bug tracker that is accessible to
those outside the project. Furthermore, if the bug tracker exists, it
may not be easy to find. Mateusz Marzantowicz asked Guðmundsson how a bug reporter
would even know the canonical location of a bug tracker for any
particular application; without a centralized list or database, the
location of the bug tracker would need to be stored
somewhere—perhaps inside of the RPM package itself. But this is
a problem that faces package maintainers already, even without
Guðmundsson's upstream-first idea. Some projects have no bug tracker,
new package maintainers may have to familiarize themselves with a new
system for each package, and so on.
Similarly, Felix Miata noted that,
in the absence of a Fedora-specific bug tracker, users would often not
know where to report a bug that could have multiple causes:
Yet this, too, is already a problem that confronts bug reporters,
as Adam Williamson of Fedora's QA team said. It may be unclear where the source
of a particular bug lies (if it is possible to determine the source
from one user's system), but bugs in Fedora itself will always be one
of those possibilities. Ultimately, Nottingham concluded that the root
problem is one of personnel:
The personnel issue is also at the heart of another major criticism
of Guðmundsson's proposal: if bugs must be reported upstream, then bug
reporters must seek out the upstream project's bug tracker and create
an account for every package that they report issues against. That
could easily be dozens or hundreds of accounts for active
participants, and the more active a bug reporter is, the worse the
problem would be. Several list participants raised this objection,
with Michal Jaegermann going so far as to say that he would stop reporting bugs
altogether under such circumstances.
No doubt Fedora (like any free software project) would love to have
excess people-power to throw at the challenges of bug reporting and
triage. But the shortage that Fedora currently feels is not likely
to resolve itself, so the QA and testing community will probably
continue to find a significant amount of its time occupied by managing bug reports. The
last factor in the equation, perhaps, is determining which people
ought to be responsible for wrangling bug reports: in particular,
deciding when pushing them upstream is the correct solution.
Guðmundsson argued in his proposal that Fedora package maintainers
are usually not developers and are often not even familiar with the
codebase of the package itself—that was one reason he advocated
reporting bugs directly to the upstream project. But several on the list
disagreed with that argument. Schwendt pointed to the guidelines
for package maintainers laid out in the Fedora wiki, which
state (but do not mandate) that maintainers should create an account on
upstream bug trackers and forward bugs upstream.
Ralf Corsepius said that pushing
bug reports upstream
was a maintainer's duty, as was implementing patches in some
situations. Of course, the trouble is that package maintainers come
and go; when important packages are orphaned, it is not uncommon for a
new volunteer to take up the mantle of maintainership even if he or
she is less-than-fully familiar with the package in question. No
doubt it is the new maintainer's responsibility to get up to speed,
but at any given time there are liable to be numerous packages whose
maintainers are not prepared to send in a patch. Schwendt, however, argued that not every package maintainer
needs to be a developer, too:
The difficulty, of course, is that package maintainership sits in
the gray zone that lies somewhere between "user" and
"developer." The free software community often talks about
itself as if these two camps are the only categories, which is an
oversimplification. Guðmundsson's frustration with how bug reports
are currently handled in Fedora illustrates how that oversimplification
plays out: there are package maintainers who cannot process and route
bug reports quickly enough to keep the bug queue clear and the end
users happy.
But Guðmundsson's upstream-only proposal would essentially have
addressed that problem by relieving package maintainers of the
responsibility for routing bug reports altogether. That might have
come as a relief to some overworked packagers, but the work would not
simply disappear: it would end up being pushed to some other segment
of the community, either to the Fedora
QA team, to the upstream project, or all the way to the end user.
For that and the other issues pointed out, Fedora is clearly not
going to discontinue the use of its bug tracker. That means, however,
that managing bug reports will remain a tricky process for some time
to come. Perhaps the changes to Bugzilla proposed by Horák will
ameliorate the headaches to some degree, but in the long run it is
likely to remain (as so many software-development hurdles are) a human problem.
pure upstream
reporting
", in which the Fedora community would file bugs
directly with the upstream projects themselves.
Upstream/downstream
Role-playing
Brief items
Distribution quotes of the week
Debian Edu / Skolelinux Wheezy
Debian Edu aka Skolelinux has released Debian Edu 7.1 "Wheezy". "Debian Edu is a complete operating system for schools. Through its various installation profiles you can install servers, workstations and laptops which will work together on the school network. With Debian Edu, the teachers themselves or their technical support can roll out a complete multi-user multi-machine study environment within hours or a few days. Debian Edu comes with hundreds of applications pre-installed, but you can always add more packages from Debian."
New GNU Hurd, Mach, and MIG releases
The GNU project is celebrating its 30th anniversary with the releases of GNU Mach 1.4 ("This new release bundles bug fixes and enhancements done since the release of version 1.3, eleven years ago; really too many (both years and improvements) to list them individually"), GNU MIG 1.4 (MIG being the Mach interface generator), and version 0.5 of the GNU Hurd kernel ("
This new release bundles bug fixes and enhancements done since the release of version 0.2, 16 years ago"). The Hurd is still 32-bit on x86 only, but a 64-bit port is said to be in the works.
FreeBSD 9.2 released
The FreeBSD Release Engineering Team has announced the availability of FreeBSD 9.2. This release features some ZFS filesystem enhancements along with various updated packages. The release notes contain the details.NetBSD 6.1.2 and NetBSD 6.0.3 released
The NetBSD Project has announced NetBSD 6.1.2 and NetBSD 6.0.3. Both releases contain fixes deemed important for security or stability reasons. More information can be found in the release notes.Red Hat Enterprise Linux 5.10 released
Red Hat has announced the release of Red Hat Enterprise Linux 5.10. See the release notes for more information.Ubuntu 13.10 (Saucy Salamander) Final Beta released
A final beta is available for Ubuntu 13.10 Desktop, Server, Cloud, and Core products, along with Edubuntu, Kubuntu, Lubuntu, Ubuntu GNOME, UbuntuKylin, Ubuntu Studio and Xubuntu flavors. This is also the first beta release of Ubuntu for Phones. "The beta images are known to be reasonably free of showstopper CD build or installer bugs, while representing a very recent snapshot of 13.10 that should be representative of the features intended to ship with the final release expected on October 17th, 2013."
Distribution News
Red Hat Enterprise Linux
Red Hat Enterprise Linux 5.3 Advanced Mission Critical 6-month Notice
Red Hat Enterprise Linux 5.3 Advanced Mission Critical (AMC) will be retired in six months. "In accordance with the Red Hat Enterprise Linux Errata Support Policy, Advanced Mission Critical for Red Hat Enterprise Linux 5.3 will be retired as of March 31, 2014, and support will no longer be provided. Accordingly, Red Hat will no longer provide updated packages, including critical impact security patches or urgent priority bug fixes, for Red Hat Enterprise Linux 5.3 AMC after that date. In addition, technical support through Red Hat's Global Support Services will no longer be provided after March 31, 2014."
Red Hat Enterprise MRG for Red Hat Enterprise Linux 5 6-month Notice
Red Hat Enterprise MRG Version 1 and Version 2 for Red Hat Enterprise Linux 5 will be retired in six months. "In accordance with the Red Hat Enterprise MRG Life Cycle policy, the Red Hat Enterprise MRG products, which include the MRG-Messaging, MRG-Realtime, and MRG-Grid, Version 1 and Version 2 offerings for Red Hat Enterprise Linux 5 will be retired as of March 31, 2014, and support will no longer be provided."
Ubuntu family
No Mir by default in Ubuntu 13.10
Developers at Canonical have concluded that the Mir desktop server (or, more specifically, the XMir layer) will not be ready in time to be shipped as the default configuration in the 13.10 release — though they do still plan to go with Mir for Ubuntu Touch. "More specifically, the multi-monitor support in XMir is working, but not to the extent we'd like to see it for all of our users. The core of Mir is working reliable, but with XMir being a key component for our 13.10 goals, we didn't want to compromise overall Ubuntu quality by shipping it."
Newsletters and articles of interest
Distribution newsletters
- This Week in CyanogenMod (September 28)
- Debian Project News (September 30)
- DistroWatch Weekly, Issue 527 (September 30)
- Ubuntu Weekly Newsletter, Issue 336 (September 29)
Patrick d'Emmabuntüs: Emmabuntüs is more than a Linux distribution (DarkDuck)
DarkDuck talks with Patrick d'Emmabuntüs, creator of the Emmabuntüs distribution. "This distribution was designed to facilitate the refurbishing of computers given to humanitarian organizations, especially Emmaüs communities, where the name comes from, and to promote the discovery of Linux by beginners, but also to extend the life of the equipment and to reduce waste caused by over-consumption of raw materials, as I have mentioned earlier."
Page editor: Rebecca Sobol
Next page:
Development>>