LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsWhich bug tracker?It is something of a recurring question in the Linux world: where should users file bug reports, with the distribution or the upstream project? There are pros and cons to each side, but there are some subtleties. Generally, the first bug report will come to the distribution, but how it should be handled from there, and who is in the best position to work with the upstream project on a bug, is sometimes contentious. The topic came up again in a thread on the fedora-devel mailing list started by Florian Weimer, who asked about the preferred place to file bugs, enhancement requests in particular. Requests for enhancement are something of a special case, really, because they typically represent a personal preference that may or not be shared by others—the package maintainer, for example. As Rex Dieter put it, it should be up to the maintainer's discretion:
Obviously, if
it's something they are interested in or is important, it likely is in their
best interest to help move feature requests upstream. If not, well, then
that burden is probably best left to you (or some other interested party).
That dispensed with the feature request question for the most part, and the thread moved on to the larger question of bug reports and the responsibilities of a package maintainer. Jóhann B. Guðmundsson took a hard line on what maintainers should do:
Yes it's the distribution maintainers responsibility to forward that
request upstream if that is the case followed by notifying the reporter
they have done so with a link to the upstream report in the relevant bug
report in bugzilla.redhat.com.
But others were not so absolute. Many of Fedora's packagers are volunteers, so it is difficult to expect them to devote their time to working with upstream projects on bugs they may not even be able to reproduce. In those cases, it makes more sense to refer the reporter to the upstream bug tracker so that they can work with the project on solving the bug. Jeffrey Ollie outlined some of those reasons packagers may not be able, or sometimes willing, to be the go-between for the bug reporter and the project. He notes that it is not part of his regular job to maintain packages. In addition, many of the bugs reported are not those he can track down himself, but, when he can, he does try to look into the problem: "For most bug reports, I'm willing to take a little bit of time and see if there's a new release I've missed or if the bug has been already identified upstream and there's a patch that can be applied." Guðmundsson replied with an unbending view: "Then you should not be maintaining that component". Others saw things differently, finding a bit more room for divergent opinions. Richard Shaw noted that a programming background isn't required to be a packager for Fedora, while others took umbrage at the tone. Ollie said that there is no one right answer, as it depends on a number of factors:
The tl;dr summary is that there shouldn't be a single
standard for what we expect of packagers, especially in the context of
what to expect when bugs are filed against their packages on Red Hat's
bugzilla. My view is that expectations are going to depend on the
criticality of the package to Fedora (kernel, installer, default
desktop stack) and the packager (are they being paid to maintain the
package in Fedora or are they volunteering their time).
Package maintainers are not necessarily intimately familiar with the code for the project—or projects—they maintain. Building the code and pulling it into an RPM file is all that is really required. Having maintainers that are knowledgeable about the code is certainly desirable, but may not be all that realistic. Given that, it probably makes sense not to have a rigid policy. Eric Smith put it this way:
For some of the packages I maintain, I am able to do some
bug fixing myself, and forward the patches upstream. For other
packages, I have done the packaging because I use the software, but I
am not at all knowledgeable about the innards, and get lost quickly
trying to fix any bugs. I think it's reasonable in those cases to
advise that the user report the bugs upstream.
But, as Ian Pilcher pointed out, bugs filed upstream by a package maintainer may carry more weight than a user's bug would. It is not a malicious act by the project, he said, more of a "social triage" to try to separate the wheat from the chaff. "In many cases, the Fedora packager has built up a level of credibility with the development community that could get a bug report the attention that it deserves." The Fedora package maintainer responsibilities document contains a lot of suggestions for how packagers should work with upstreams, but doesn't actually require all that much. For example, it is recommended that packagers "forward severe bugs upstream when possible for assistance". It also suggests that bugs reported be dealt with in a timely manner, possibly with the assistance of co-maintainers or others more familiar with the code (including the upstream project). Bug reports vary widely in their quality, but those generated from distributions are often not very applicable upstream as well. Distributions tend to lag project releases, so the version that the distribution user is reporting a bug against may well be one or more releases behind the project's version. Many projects aren't terribly interested in bugs in older versions, and would rather see whether the bug exists in the latest release. Other projects are only interested in bugs that are reproducible in the latest code in their source code repository. In either of those cases it may be difficult for a user (or even a packager) to determine whether the bug is still present, which just throws up one more barrier to bug reporting. Systems like Ubuntu's Launchpad, where upstream bugs can be linked to the distribution bug report may help, but don't solve some of the underlying problems inherent in bug reporting. Bug handling is not primarily a technical problem, though some technical measures may help. Getting better bug reports from users, with reproducible test cases and all the required information is, to a large extent, a social problem. Back in early 2011, we looked at a similar discussion in the Debian community, which touched on earlier Fedora struggles with the problem as well. Handling bugs is tricky for any number of reasons, and it is hard to imagine that there is "one true policy" out there that would alleviate most or all of the problems. Proper bug handling just depends on too many variables to make any kind of rational, hard-and-fast rules about it. Discussions like these can only help devising guidelines and best practices, though, and we will undoubtedly see them pop up again.
Brief items Xen4CentOS releasedThe Xen4CentOS project has been announced with the aim of helping CentOS 5 Xen users migrate to CentOS 6 while also updating to Xen 4. Since RHEL 6 did not ship with Xen (it switched to KVM), CentOS and Xen users have not had an upgrade path, but that has changed with this announcement. The project is a collaboration between CentOS, Xen, Citrix, GoDaddy, and Rackspace; it intends to maintain the Xen hypervisor and its tools for CentOS 6. More information can be found in the release notes, quick start guide, and an article at Linux.com.
Distribution News Fedora Election Results for Fedora Board, FAmSCo, and FESCo seatsThe Fedora election results have been announced. Kevin Fenzi, Bill Nottingham, Tomáš Mráz, Matthew Miller, and Peter Jones have been elected to FESCo. Jiri Eischmann, Christoph Wickert, Luis Enrique Bazán De León, and Robert Mayr have been elected to FAmSCo. Matthew Garrett, Josh Boyer, and Eric Christensen have been elected to the Advisory Board.
Newsletters and articles of interest Distribution newsletters
CyanogenMod 10.1 released, monthly release series begins (The H)The H looks at the CyanogenMod 10.1.0 release. It is the first in six months for the alternative firmware for Android devices. 10.1.0 is the second release based on Android 4.2 ("Jelly Bean"). "With the next few releases, which are planned to arrive monthly (hence their labelling as "M-series"), the developers plan to build on the AOSP Jelly Bean foundations and deliver new features of their own making, such as the new privacy mode that has already been merged into the code base and will be tested in upcoming nightly releases."
SolydXK: New Kid on the Linux Block Delivers Rock-Solid Performance (LinuxInsider)LinuxInsider reviews SolydXK. "SolydXK surpasses the typical new Linux distro in a number of ways. It is polished and fast, despite its otherwise young and lightweight nature. The Xfce and KDE choices provide solid computing power and convenience without being clones of other distros. I particularly like its emphasis on no-nonsense computing without bogging down users in mundane setup and tinkering. I constantly look for Linux distros that do not try to reinvent the wheel. SolydXK will not discourage newcomers but will not turn off seasoned Linux users either."
Page editor: Rebecca Sobol |
|||||||||||||