Date: Wed, 18 May 2011 08:46:38 +0200 From: Bernhard Froehlich <decke@bluelife.at> To: Cy Schubert <Cy.Schubert@komquats.com> Cc: freebsd-emulation@freebsd.org Subject: Re: Future direction of virtualbox-ose port on FreeBSD Message-ID: <b2827568fabe0d7db6b1ce4389f80165@bluelife.at> In-Reply-To: <201105171936.p4HJah1F053940@cwsys.cwsent.com> References: <201105171936.p4HJah1F053940@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 17 May 2011 12:36:43 -0700, Cy Schubert wrote: > In message <4DA6AD3D.7040607@mittelstaedt.us>, Ted Mittelstaedt writes: >> On 4/13/2011 4:38 AM, Bernhard Froehlich wrote: >> > Hi VirtualBox users. >> > >> > I'm sending this because there are a few problems in how we currently >> > maintain the emulators/virtualbox-ose ports on FreeBSD. I want to >> > outline my main concerns and propose a better way to solve that. >> > >> > The VirtualBox port is already very critical for many users and very >> > complex at the same time so it gets harder and harder to update the port >> > to new major versions without getting too much negative feedback from >> > users. In the past we did a call for testers when upstream released a >> > new major version (3.1.0, 3.2.0, 4.0.0) and got the update in the tree >> > after their first patch release (3.1.2, 3.2.2) but now for the 4.0 >> > release cycle we need at least to wait for 4.0.6 to get a useable state. >> > >> > Because of this long delay more and more people are using the cft and >> > our development ports. We do not want that average users use that ports >> > just to get to a newer version because they contain additional risks and >> > are usually unstable versions (no support, irregular updates, broken >> > ...). But we also do not want to make it harder for our testers to >> > provide feedback because your feedback is very valuable to us and we >> > need each tester we have. >> > >> > So we currently have these problems: >> > 1) we need a stable version around if you hit a problem at the new >> > version >> > 2) we need to get new major versions out earlier to testers >> > 3) we need to attract more testers >> > >> > >> > We could solve this problems with "unstable" ports and people can use >> > them if they care about it but we don't have that infrastructure in >> > FreeBSD yet. We could also create -devel ports but that only solves one >> > part of the problem and generates an huge amount of work on our side. >> > Our internal -devel ports are most of the time built with "trunk" code >> > so more or less alpha quality code. So that's not going to fly either. >> > >> > >> > Instead we came up with two improvements: >> > 1) Before a major version hits the tree we do a repocopy with the >> > current version. So in case you have a problem with the major version >> > you can fallback to the old version. It will be marked DEPRECATED with >> > the next major update and removed 2 months after that. Major updates for >> > vbox are 3.1.x, 3.2.x, 4.0.x >> > >> > 2) We provide binary packages and PBIs for virtualbox when we do a Call >> > for Testers and probably also on a regular basis to lower the burden to >> > test it. That only works for FreeBSD releases because the kernel module >> > needs to be build for a specific kernel. So if you use a STABLE kernel >> > you won't benefit from that. >> > >> > That means for us that we can bring in a new major version a bit >> > earlier than now but we will continue to do extensive testing first. So >> > you will still not see a .0 release in the ports. >> > >> > >> > What do you think about it? Any better ideas? >> > >> >> I vote for binary releases for the testers. From a test standpoint >> there is a huge benefit for you guys to have everyone running >> the same build, built the same way. Currently FreeBSD development >> snapshots are released binary, this isn't much different. >> >> Granted you may have some testers with weird systems setup that >> won't like it, but they can always keep the last RELEASE kernel around >> and boot their system on it temporarily for testing purposes only. >> >> Anyone running vbox in production is very likely NOT testing >> on their production servers. Ideally they are imaging their >> production boxes and booting the image on a spare box and testing >> on that - so worrying about fallback is kind of pointless - if the >> new version doesn't work, then they don't need to fall back >> to a prior one. > > Would it be possible install by default vbox 4.0.x into an alternate > LOCALBASE, allowing users to at least try the new vbox without having to > uninstall the old? No. You cannot load both kernel modules at the same time so installing both is a bad idea. Custom LOCALBASE should be possible (it works on PC-BSD after all) but it could cause some troubles because of their hardening (they check the path of the suid binaries). -- Bernhard Fröhlich http://www.bluelife.at/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b2827568fabe0d7db6b1ce4389f80165>