Date: Wed, 13 Apr 2011 13:38:40 +0200 From: Bernhard Froehlich <decke@FreeBSD.org> To: <emulation@FreeBSD.org>, <ports@FreeBSD.org> Subject: Future direction of virtualbox-ose port on FreeBSD Message-ID: <bf0bde98729c30ff9b3dedc121049354@bluelife.at>
next in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bf0bde98729c30ff9b3dedc121049354>