[vbox-dev] VirtualBox LTS (was: "The number of bug reports with virtualbox loaded are truly astonishing")

[Klaus Espenlaub]

On 25.02.2012 12:20, Alexey Eromenko wrote:
> On Sat, Feb 25, 2012 at 7:20 AM, Arend Dittmer<admin at mypocketxp.com>  wrote:
>> Agree. Ranting is pointless.
>>
>> What surprises me though is the relatively high number of regressions that
>> keep popping up. A simple search on the latest changelog for 4.0.18 yields
>> 23 hits from 4.0.18 back to 4.0.
>
> ...This is simple Watson. There is no 4.0.18. There are 4.0.16 and
> 4.1.8. :) ... so searching for 4.0.18 on Google is like searching for
> aliens...
> ========
> A bit more serious note:
>
> As for regressions, they do pop-up. (4.1.2 broken guest exec, 4.1.4
> broken RHEL4 goodies, 4.1.8 broken symlink in vbox SF, ...)

 From today's perspective I consider symlink support in vbox SF to be 
the regression, not the other way round ;)

> One idea is to maintain a community-led VirtualBox LTS (Long-Term
> Support edition; It must be done together with the Debian project,
> which has the need for a 3-year support).

The fact right now is that the Debian project doesn't seem to pick up 
any bugfixes which we provide. The users get whatever Debian picked up 
for their release. Yes, security issues do get fixed, but nothing else. 
So Debian users unnecessarily suffer already from long fixed bugs, this 
should be solved before going further. Oracle does already provide 
branch bug fixes for a long time. See the 3.2.14 maintenance version in 
December, over 14 months after Debian picked up 3.2.10 for Debian 
Squeeze, or approx. 20 months after 3.2.0 was released.

So you're proposing to do step 2 before step 1. I'd first like to see 
that the bugfixes are reaching the Debian community...

> One big obstacle is that the public SVN tree of "stable" series does
> not exist, and the individual patches are obfuscated. (similar to
> RHEL6 kernel tree)

Only the former issue really exists, and it's a side effect (which is 
now hard to fix) of how we create the public subversion repository, 
which is a subset of the internal repository. We use a modified version 
of svnsync (see the VirtualBox repository, the source code is publicly 
visible for quite a while). It works using directory and file markers, 
telling what to export and what not. The "branches" subdirectory isn't 
exported (but the contents of the branches already have the right 
markers), and the tool has a known and hard to fix deficiency, namely 
when changing the export status of a parent directory when the 
subdirectory/files already have the markers.

The "obfuscation" of patches is an unintentional consequence of the 
difficulty to include the branches in the public repository. Getting the 
export problem solved would automatically resolve this issue, too.

> Why is this a problem ?
>
> Out of curiosity, I have made a diff between 4.1.6 and 4.1.8 official
> source tarballs, and the result was 1.3 MB patch ! yay !
> Also I consider this amount of change inappropriate for a point release.

There were certainly unusually large changes in 4.1.8, but the majority 
was limited to the graphics area, and in particular 3D. If you look at 
the diffstats the rest is 1.5 months of bug fixing, with a few lines 
changed per file, which means that the context lines adds significantly 
to your statistics.

> Needless to say that maintaining a community 'LTS' version becomes
> very difficult
> under those circumstances, due to impossibility to backport patches
> from Oracle's stable tree.
> Anyway: if the community is big enough, then the 'LTS' might be
> possible anyway, without Oracle's babysitting.

See above - first step would be to actually make use of the bug fixes 
which are there already, and then as a second step build on this.

> If Oracle wants to help: I'd be glad to see a public SVN tree for
> Stable series. (4.1.x)

I think I mentioned quite some time ago that this is a todo item, 
unfortunately it has to be low priority due to the shortage of manpower.

>> My understanding of regressions is that they are bug fixes that 'dropped
>> out' over time reintroducing the original problem. I am curious to
>> understand why this happens relatively often.
>
> "regression" is when a new release breaks functionality, that worked
> in a previous release. (either major release: 4.1.x vs. 4.0.x or a
> point release: 4.1.x vs. 4.1.y)

Correct. In modern branch-based release schemes it's practically 
impossible to have the same bug several times. Often it's a different 
bug with superficially similar symptoms.

Klaus