Distributions

Which 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:

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:

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:

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:

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.

Comments (23 posted)

Xen4CentOS released

The 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.

Full Story (comments: 12)

Election Results for Fedora Board, FAmSCo, and FESCo seats

The 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.

Full Story (comments: none)

Distribution newsletters

• Debian Project News (June 24)
• DistroWatch Weekly, Issue 513 (June 24)
• Ubuntu Weekly Newsletter, Issue 322 (June 23)

Comments (none posted)

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."

Comments (9 posted)

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."

Comments (none posted)