From owner-freebsd-emulation@FreeBSD.ORG Tue May 17 19:51:46 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 E6DB91065674 for ; Tue, 17 May 2011 19:51:46 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id AD4E48FC08 for ; Tue, 17 May 2011 19:51:46 +0000 (UTC) Received: from pd6ml1no-ssvc.prod.shaw.ca ([10.0.153.160]) by pd6mo1no-svcs.prod.shaw.ca with ESMTP; 17 May 2011 13:36:44 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=sma64emKALigICJU+V2L7RL3kPAolu7RCFSKDgo279k= c=1 sm=1 a=Hw-BNroQwbAA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=xA7i7079zcQA:10 a=kj9zAlcOel0A:10 a=+J+gTUrb/Bhkr9chPx4Sww==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=hYUaj_N8uQndr9mj5bUA:9 a=v2NWVPW2SwDnD7KcN4MA:7 a=CjuIK1q_8ugA:10 a=0xsYWGtdrcAA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=OXNwmBisZzO9_RSo:21 a=8Mpswn-VUmuwYzGt:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([24.68.75.245]) by pd6ml1no-dmz.prod.shaw.ca with ESMTP; 17 May 2011 13:36:44 -0600 Received: from cwsys.cwsent.com (cwsys [10.1.1.1]) by spqr.komquats.com (Postfix) with ESMTP id 441C846C6A; Tue, 17 May 2011 12:36:44 -0700 (PDT) Received: from cwsys (localhost [127.0.0.1]) by cwsys.cwsent.com (8.14.4/8.14.4) with ESMTP id p4HJah1F053940; Tue, 17 May 2011 12:36:44 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201105171936.p4HJah1F053940@cwsys.cwsent.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Ted Mittelstaedt In-Reply-To: Message from Ted Mittelstaedt of "Thu, 14 Apr 2011 01:15:57 PDT." <4DA6AD3D.7040607@mittelstaedt.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 May 2011 12:36:43 -0700 Sender: Cy.Schubert@komquats.com 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 Reply-To: Cy Schubert List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 19:51:47 -0000 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? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org Q: How did the regular expression cross the road? A: ^.*$