{"id":204,"date":"2011-10-27T15:45:03","date_gmt":"2011-10-27T22:45:03","guid":{"rendered":"http:\/\/www.skierpage.com\/blog\/?p=204"},"modified":"2011-10-27T15:45:03","modified_gmt":"2011-10-27T22:45:03","slug":"computers_reporting_bugs","status":"publish","type":"post","link":"https:\/\/www.skierpage.com\/blog\/2011\/10\/computers_reporting_bugs\/","title":{"rendered":"computers: reporting bugs in a sea of versions and projects"},"content":{"rendered":"

Someone’s post When is a bug report useful?<\/a> inspired me to comment<\/a>. I have two great ideas in here<\/p>\n

    \n
  1. bug systems should be aware of my distribution, version, and related packages<\/li>\n
  2. software projects should provide a way to test drive the latest version<\/li>\n<\/ol>\n
    \n

    Good points. But everything breaks down with “It should be about the most recent version available”. (K)ubuntu doesn’t ship the most recent version available!<\/p>\n

    For reporting, what would be great is if the bug ecosystem was both version- and distribution- aware. I should be able to search for a bug, and even if it’s fixed<\/em> find relevant bug reports because it still applies to my version and\/or distro. Ubuntu’s Launchpad tries to handle this with its “(+) Also affects project (+) Also affects distribution” and upstream linking, but in my limited understanding their implementation creates another fjord in which tens of thousands of bugs languish underwater. The problem also goes in the other direction: these days if you Google for problems with any<\/em> Linux feature or program, the top search results are invariably cluttered with detailed bug reports and forum threads about Ubuntu 8.04 and Fedora 9… from 2008.<\/p>\n

    Another issue with reporting is the interconnected layers in any modern Linux distro. My problem “KDE System Settings picks the wrong sound card” turned out to be PulseAudio providing identical description strings for them (“Internal Audio Analog Stereo”) because the kernel’s PCI probing is messed up on my hardware, with a workaround that requires Alsa config file changes. Likewise my problem “Firefox prints blank images” turned out to be bugs in the interaction of Ghostscript and libpoppler exposed by Ubuntu’s configuration of CUPS to still use a PostScript workflow even when apps generate PDFs for printing. Both involved four or more web sites, four bug systems, four wikis, and four forums to wander around in after<\/em> looking in my distro’s bug system. Many people would call this the typical Linux clusterf*** and give up in despair, but it shows that bug systems have to become smarter about relationships.<\/p>\n

    In order to reproduce a bug with latest version, if I’m lucky I can download a standalone nightly binary from the project, unpack it into a test directory and retest with that. If I can’t, then sometimes I can switch my package manager to install unstable packages, but often that has cascading dependencies that require updating half a dozen other packages to unsupported latest. I’ve had problems with VLC and Wine and Pulseaudio and no easy way to try the latest short of compiling from source or installing a rolling bleeding-edge distro in a VM.<\/p>\n

    Here’s an idea: what if projects provided a runnable version of their nightly build? Each could have a test server with compiled code and you could either use X’s DISPLAY<\/code> to have the remote binary display on your screen, or you could use a remote desktop protocol, some of which can even run in a browser. This “Try the latest” facility could take screenshots and link to bug reports. And imagine how many more people would use your cool program if they could test-drive it!<\/p>\n

    I really appreciate anyone who triages bug reports in the current situation, it’s a tough mission.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Someone’s post When is a bug report useful? inspired me to comment. I have two great ideas in here bug systems should be aware of my distribution, version, and related packages software projects should provide a way to test drive … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14,18],"tags":[],"class_list":["post-204","post","type-post","status-publish","format-standard","hentry","category-open-source","category-software"],"_links":{"self":[{"href":"https:\/\/www.skierpage.com\/blog\/wp-json\/wp\/v2\/posts\/204","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.skierpage.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.skierpage.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.skierpage.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.skierpage.com\/blog\/wp-json\/wp\/v2\/comments?post=204"}],"version-history":[{"count":0,"href":"https:\/\/www.skierpage.com\/blog\/wp-json\/wp\/v2\/posts\/204\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.skierpage.com\/blog\/wp-json\/wp\/v2\/media?parent=204"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.skierpage.com\/blog\/wp-json\/wp\/v2\/categories?post=204"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.skierpage.com\/blog\/wp-json\/wp\/v2\/tags?post=204"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}