From owner-freebsd-ports@FreeBSD.ORG Wed Apr 13 11:53:46 2011 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EEEF106564A; Wed, 13 Apr 2011 11:53:46 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id EFAF58FC0A; Wed, 13 Apr 2011 11:53:45 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 37C7EA; Wed, 13 Apr 2011 13:38:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Wed, 13 Apr 2011 13:38:40 +0200 From: Bernhard Froehlich To: , Message-ID: X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.5.1 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0206.4DA58B3F.01CD,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: Subject: Future direction of virtualbox-ose port on FreeBSD X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:53:46 -0000 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? Your VirtualBox on FreeBSD Team, decke@, bapt@, (i. a. beat@) -- Bernhard Froehlich http://www.bluelife.at/