[vbox-dev] VirtualBox LTS (was: "The number of bug reports with virtualbox loaded are truly astonishing")
klaus.espenlaub at oracle.com
Mon Feb 27 09:03:07 PST 2012
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
> 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.
More information about the vbox-dev