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

Tue Feb 28 00:17:33 GMT 2012

I have been reading this for some time now.  Here, the forums, and IRC, 
even on external links.
I didn't understand what all the fuss was about and for the most part 
the whole talk about needing an LTS Build just didn't make sense.  So 
either my logic is flawed or someone else's is.

Facts:
You can and did install a minimal Debian and compile or install 
pre-compiled of any of the versions of VirtualBox that have been 
released to date. I looked and the tarballs,.deb, & .rpm are there. If 
you need to add special patches just use the tarballs.

Now since VirtualBox is a type 2 hypervisor and not a type 1, and all of 
the releases are available what is the issue.  We have 3.2.14, 4.0.16 
and 4.1.* to chose from and they are all being upgraded (backported) 
with the appropriate fixes when applicable.

Now if you want the latest and greatest (bleeding edge) you install from 
SVN which I do for all of my machines with the exception of one server 
that is critical.  I leave it at the 3.2.14 version because it just works.

The flaw in logic as I see it is that some want to have the bleeding 
edge (SVN) work as a stable environment and guess what?  It isn't going 
to work (although I personally have not had any real issues in a long 
time building from SVN).  Same with everything I use.  If I want the new 
feature from any distro or VirtualBox I must be willing to put up with 
issues and regressions, and I have installed just about every distro 
that has been made. If however you want stability you must stay with 
what works until you see that the issues or regressions have been 
fixed.  Some of the new features will never be backported because some 
of the changes do not fit the older version and can create more issues 
than they fix.

So just like the "LTS" version of Debian 6(stable) there is 7(testing) 
and SID, VirtualBox there is 3.2.14, 4.0.16 and 4.1.*

Any help in clearing this up for me is welcome but the way I see it we 
already have what is being sought.

As an ending note: opening up SVN to anyone, everyone, even special 
selected individuals is the worst of all bad ideas, period. The control 
of quality will be gone. Please don't do it.

On 02/27/2012 11:03 AM, Klaus Espenlaub wrote:
> 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
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20120227/d8312d33/attachment.html>