<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Verdana">I have been reading this for some time now.
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. So either my logic is flawed or someone else's is.<br>
<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, & .rpm are
there. If you need to add special patches just use the tarballs.<br>
<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. 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>
<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. I leave it at the
3.2.14 version because it just works.<br>
<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?
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.<br>
<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>
<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>
</font><br>
<br>
<br>
<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:
</pre>
<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"><admin@mypocketxp.com></a> wrote:
</pre>
<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>
</blockquote>
<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
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, ...)
</pre>
</blockquote>
<pre wrap="">
From today's perspective I consider symlink support in vbox SF to be
the regression, not the other way round ;)
</pre>
<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>
</blockquote>
<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...
</pre>
<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>
</blockquote>
<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.
</pre>
<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>
</blockquote>
<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.
</pre>
<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>
</blockquote>
<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.
</pre>
<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>
</blockquote>
<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.
</pre>
<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>
</blockquote>
<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>
</blockquote>
<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.
Klaus
_______________________________________________
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>
</pre>
</blockquote>
</body>
</html>