Ubuntu bugs accumulating https://bugs.launchpad.net/ubuntu/+source/virtualbox-ose

[grantbow]

​https://bugs.launchpad.net/ubuntu/+source/virtualbox-ose has a number of bugs that could really use some help. Both Karmic (current stable) and Lucid (stable April 29th, 2010) are in need.

[Sander van Leeuwen]

Could you be more specific? I see a lot of issues there that are obsolete or have nothing to do with us.

[grantbow]

Thank you very much for your question. Your observation is part of the reason I filed this bug. I should have filed this bug before the Ubuntu 10.04 LTS freeze when something could be done before the release coming up April 29th. I'll try to elaborate. Please ask about anything that you find unclear. I'll reiterate what some people may find obvious for the purpose of clarity.

A different version of virtualbox-ose is packaged for different versions of Debian and Ubuntu. A summary of each Ubuntu binary package version is found ​https://launchpad.net/ubuntu/+source/virtualbox-ose

The people doing the Ubuntu packaging (listed in the changelog.Debian.gz file) usually are the leads in handling bugs related to each version. Yet anyone who knows the answer can update the bug with new information. It seems the group of people that work on the virtualbox-ose bugs need some help. Understanding what version end users are using helps in understanding the bugs coming into launchpad for this binary package.

For example - I run Ubuntu 9.10 Karmic Koala. I am testing a ppa (personal package archive, specifically "deb ​http://ppa.launchpad.net/arand/virtualbox/ubuntu karmic main") that works around a bug where on my system I couldn't easily run Ubuntu 10.04 inside virtualbox (a big problem) so I am running version 3.0.8-dfsg-1ubuntu1.2~ppa4. If I have a problem I would file it against the binary package and if it applied to other versions people more knowledgeable than I would update the bug's information, tags, priority, etc. To decode that version number, it seems the upstream version 3.0.8 was used to begin. Then some changes were made to make it comply with the Debian Free Software Guidelines. The Debian version is -1. Then someone in the Ubuntu world (as outlined in changes.Debian.gz) modified the package to version 1.2 to make it work better on an Ubuntu system. Then someone used that source package and mad 4 revisions to it and posted it as ~ppa4 for people to test.

So, if a user has a problem with an installed virtualbox-ose binary package the first place they look for a bug is with the binary package which they use. It may be known already and the user can subscribe themselves to the bug to get email updates which can be helpful. End users often share tips about bugs with other end users in the comments, patches can be submitted, etc. Teams of people (exactly whom in the case of Virtualbox I'm not sure) then "triage" the bugs, answering simple questions, associating duplicates, etc. Ideally, after they are triaged and if real problems do indeed exist and are reproducible and clearly isolated compared other issues then the package maintainers research the issue and can respond in many ways, perhaps with information on an upstream bug.

One response is to alter the Debian package with configuration, notes or source code patches. If they develop a patch they should also file a bug upstream with their patch contribution for consideration to be included upstream. Once the source package is fixed, a new binary package can be deployed. If as in Ubuntu 9.10 Karmic the release is stable the binary package goes through a process and may or may not be deployed to end users immediately as an update. For Ubuntu 10.04 now in Beta freeze a different process is followed. In early development versions of Ubuntu fixes are deployed to end users immediately.

Of course much of this effort is duplicated from the upstream process, however if all processes along this chain are working correctly the load of bugs filed upstream is greatly reduced and work can be distributed from time-constrained packagers to skilled end users who can help less skilled end users in addressing issues particular to their version of software. The signal to noise ratio gets much much better if this process is working well. If an extraordinarily skilled individual is able to spend time responding to bugs, is active in upstream development and is a Debian Developer & Ubuntu MOTU then answers to technical questions are obvious to this individual and are responded to quickly. If a person such as this doesn't exist for virtualbox-ose or the package maintainers get busy, don't collaborate with backup package maintainers and/or don't have the time to respond to bugs then bug responses to end users are delayed or never come. However end users still file more bugs and they still accumulate.

Some upstream developers understand this whole chain of distribution. Others haven't yet dealt with the issues between end users and their source code releases as much yet. An understanding not only upstream development and end user issues but also the logistical Linux distribution issues helps to understand why this process even exists: to build scalable teams (often of volunteers) to ensure that when an apt-get install virtualbox-ose is run by an end user the software has all it's dependencies downloaded automatically, is installed correctly by dpkg and "just works" on their system as intended by the upstream developers.

My filing this bug with the virtualbox project was to try to raise the visibility of a problem in the Ubuntu packaging and bug processes to see if people upstream have the time and inclination to lend a hand in some way. Sometimes mail lists develop to support the Debian and Ubuntu package maintainers and bug triagers around some packages. I'm not aware of one for Virtualbox yet.