From owner-freebsd-emulation@FreeBSD.ORG Wed May 18 06:46:39 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A971106566B for ; Wed, 18 May 2011 06:46:39 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id AD0DB8FC08 for ; Wed, 18 May 2011 06:46:38 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 3BED13; Wed, 18 May 2011 08:46:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Wed, 18 May 2011 08:46:38 +0200 From: Bernhard Froehlich To: Cy Schubert In-Reply-To: <201105171936.p4HJah1F053940@cwsys.cwsent.com> References: <201105171936.p4HJah1F053940@cwsys.cwsent.com> Message-ID: X-Sender: decke@bluelife.at User-Agent: Roundcube Webmail/0.5.2 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A090205.4DD36B4D.0081,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: freebsd-emulation@freebsd.org Subject: Re: Future direction of virtualbox-ose port on FreeBSD X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 06:46:39 -0000 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/