Date: Tue, 17 May 2011 12:36:43 -0700 From: Cy Schubert <Cy.Schubert@komquats.com> To: Ted Mittelstaedt <tedm@mittelstaedt.us> Cc: freebsd-emulation@freebsd.org Subject: Re: Future direction of virtualbox-ose port on FreeBSD Message-ID: <201105171936.p4HJah1F053940@cwsys.cwsent.com> In-Reply-To: Message from Ted Mittelstaedt <tedm@mittelstaedt.us> of "Thu, 14 Apr 2011 01:15:57 PDT." <4DA6AD3D.7040607@mittelstaedt.us>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <Cy.Schubert@komquats.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org Q: How did the regular expression cross the road? A: ^.*$
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201105171936.p4HJah1F053940>