<meta content="text/html; charset=ISO-8859-1"
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Verdana">I have been reading this for some time now.&nbsp;
      Here, the forums, and IRC, even on external links.<br>
      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.&nbsp; So either my logic is flawed or someone else's is.<br>
      Facts: <br>
      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, &amp; .rpm are
      there. If you need to add special patches just use the tarballs.<br>
      Now since VirtualBox is a type 2 hypervisor and not a type 1, and
      all of the releases are available what is the issue.&nbsp; 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.<br>
      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.&nbsp; I leave it at the
      3.2.14 version because it just works.<br>
      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?&nbsp;
      It isn't going to work (although I personally have not had any
      real issues in a long time building from SVN).&nbsp; Same with
      everything I use.&nbsp; 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.&nbsp; 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.<br>
      So just like the "LTS" version of Debian 6(stable) there is
      7(testing) and SID, VirtualBox there is </font><font
      face="Verdana">3.2.14, 4.0.16 and 4.1.*<br>
      Any help in clearing this up for me is welcome but the way I see
      it we already have what is being sought.<br>
    </font><font face="Verdana"><br>
      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.<br>
    On 02/27/2012 11:03 AM, Klaus Espenlaub wrote:
    <blockquote cite="mid:4F4BB74B.3050703@oracle.com" type="cite">
      <pre wrap="">On 25.02.2012 12:20, Alexey Eromenko wrote:
      <blockquote type="cite">
        <pre wrap="">On Sat, Feb 25, 2012 at 7:20 AM, Arend Dittmer<a class="moz-txt-link-rfc2396E" href="mailto:admin@mypocketxp.com">&lt;admin@mypocketxp.com&gt;</a>  wrote:
        <blockquote type="cite">
          <pre wrap="">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.
        <pre wrap="">
...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, ...)
      <pre wrap="">
 From today's perspective I consider symlink support in vbox SF to be 
the regression, not the other way round ;)

      <blockquote type="cite">
        <pre wrap="">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).
      <pre wrap="">
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...

      <blockquote type="cite">
        <pre wrap="">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)
      <pre wrap="">
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.

      <blockquote type="cite">
        <pre wrap="">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.
      <pre wrap="">
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.

      <blockquote type="cite">
        <pre wrap="">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.
      <pre wrap="">
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.

      <blockquote type="cite">
        <pre wrap="">If Oracle wants to help: I'd be glad to see a public SVN tree for
Stable series. (4.1.x)
      <pre wrap="">
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.

      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">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.
        <pre wrap="">
"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)
      <pre wrap="">
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.


vbox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:vbox-dev@virtualbox.org">vbox-dev@virtualbox.org</a>
<a class="moz-txt-link-freetext" href="https://www.virtualbox.org/mailman/listinfo/vbox-dev">https://www.virtualbox.org/mailman/listinfo/vbox-dev</a>