Re: [Openembedded-architecture] RFC BuildAppliance future

[Mark Hatle <mark.hatle@windriver.com>]

On 12/5/16 12:04 PM, Brian Avery wrote:
>   Please note, this is going out to 3 lists in an attempt to insure that no one
> who would be impacted by this change misses it. Implied spam apology included.
> 
>   The Yocto Project currently provides a virtual machine image called the Build
> Appliance
> (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-appliance/).
> This image can be run using either VirtualBox or VMware. It enables you to build
> and boot a custom embedded Linux image with the Yocto Project on a non-Linux
> development system.  It is not intended for day to day development use, but
> instead, is intended to allow users to “try out” the tools even if they do not
> have access to a Linux system.

What are the requirements for a Windows user to use this, instead of the VM
approach.  (In the past it was easy for a Windows user to get the VM, and just
run it to test out things.)

--Mark

>   We are considering replacing the VM based Build Appliance with a set of
> containers (https://hub.docker.com/r/crops/poky/, or if you want a user
> interface (https://hub.docker.com/r/crops/toaster-master/ ).  These containers
> currently provide most of the functionality of the Build Appliance and should
> shortly be at feature parity with the Build Appliance.  We are actively adding
> to and supporting the containers as some of our developers are using them in
> their day to day development in order to benefit from the host isolation and
> ease with which other distributions can be tested. 
> 
>   This is an RFC to see what features in the Build Appliance are important to
> you but would not be provided by the container solutions.  If the community
> would be just as content using the container approach as using the VM based
> Build Appliance image, then we’d be better off deprecating the Build Appliance
> and applying those resources elsewhere.  If there are important features the
> Build Appliance provides which the container solution does not, or cannot
> provide, we’d love to hear what they are!
> 
> 
Thanks in advance for any feedback,
> 
> -Brian
> 
> an Intel Employee
> 
> 
> 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>