[yocto-ab] Terminology - Some draft definitions

Cherry, John John_Cherry at mentor.com
Mon May 16 08:20:36 PDT 2011



> -----Original Message-----
> From: yocto-ab-bounces at yoctoproject.org [mailto:yocto-ab-
> bounces at yoctoproject.org] On Behalf Of Mark Orvek
> Sent: Monday, May 16, 2011 7:20 AM
> To: Richard Purdie; Ed Nash
> Cc: yocto-ab at yoctoproject.org
> Subject: Re: [yocto-ab] Terminology - Some draft definitions
> 
> >> "industry quality"? How does this differ from "commercial quality"?
> >
> >I suspect commercial quality would be better :)
> 
> I suggest we avoid terms that will cause conflict with the member
> companies.  How about "improved quality tools for embedded system
> developers"?
> 
> Mark

Totally agree with Mark here.  Yocto is about continuously integrated/tested tools, metadata, and core embedded SW definitions that serve as the foundation for industry wide development environments and product offerings.   As soon as Yocto becomes a "commercial" entity, broad member involvement will cease.

John
 

> 
> -----Original Message-----
> From: yocto-ab-bounces at yoctoproject.org
> [mailto:yocto-ab-bounces at yoctoproject.org] On Behalf Of Richard Purdie
> Sent: Monday, May 16, 2011 6:49 AM
> To: Ed Nash
> Cc: yocto-ab at yoctoproject.org
> Subject: Re: [yocto-ab] Terminology - Some draft definitions
> 
> On Mon, 2011-05-16 at 09:27 -0400, Ed Nash wrote:
> > On 05/16/2011 07:50 AM, Richard Purdie wrote:
> > > In the last steering group meeting I promised to write something
> down
> about what
> > > some of the words we use mean, particularly what OE, Poky and Yocto
> all
> > > mean. What follows is a first draft style start at this:
> >
> > Thanks Richard for getting this started.
> >
> > > Yocto Project - The overall project aiming to make Linux on
> "embedded"
> > > platforms succeed by providing industry-quality tooling for
> developers
> >
> > "industry quality"? How does this differ from "commercial quality"?
> 
> I suspect commercial quality would be better :)
> 
> > > and making Linux easier to use in "embedded" products. It's scope
> > > includes anything that can further that objective.
> >
> > cool.
> >
> > > OpenEmbedded - An architecture and build system technology in the
> form
> > > of an open source project.
> >
> > What does "architecture" apply to? What software components are
> > compliant with this architecture? Does this represent choices I have
> to
> > make in my product design? Oh wait, reading below "OpenEmbedded
> Core",
> > it sounds like architecture means "how you write a recipe" - correct?
> 
> Yes, the architecture refers to the metadata format and the process by
> which the system takes than and produces the end result.
> 
> > > Bitbake - The tool used by OpenEmbedded to parse the metadata and
> > > execute tasks
> >
> > Crystal clear! :)
> >
> > > OpenEmbedded Core - A core set of metadata which most embedded
> style
> > > systems commonly need and conforms to the OpenEmbedded
> architecture.
> > > Shared by Yocto and OpenEmbedded and has an aim of achieving the
> highest
> > > metadata quality at the expense of some additional process.
> >
> > "process"? Can you give an example.
> 
> We're using a pull model with a clear submission process and that
> changes need to be of a certain quality (e.g. changes shouldn't break
> QA
> tests or they ultimately would get backed out).
> 
> > > Meta-OpenEmbedded - Metadata for less commonly used software
> components
> > > of embedded systems. Has different submission and quality
> objectives.
> >
> > I follow, though it begs the question what are the submission and
> > quality objectives?
> 
> Ensuring recent versions are used, that they build/run for all core CPU
> architectures, that the recipes are cleanly and clearly written,
> patches
> clearly documented and so on. The submission part of this is because
> meta-oe might be under a different less stringent process to that of
> OE-Core.
> 
> > > Poky - A vetted and QA'd combination of bitbake, OpenEmbedded-Core,
> > > documentation, some reference board support and any needed glue to
> > > provide support for a defined architecture list. It is supplied in
> a
> > > pre-integrated package which has known QA tests and results for its
> > > releases which provide a stable base people can build upon. Its
> provided
> > > and maintained by the Yocto project.
> >
> > Frankly, this sounds like a great definition for the yocto project!
> 
> There is more to the yocto project than this. There are several other
> components such as:
> 
> * Kernel Tooling
> * Pseudo
> * Swabber
> * ADT IDE plugins (Eclipse)
> * Image Creator UI
> 
> and Poky is just one component part of this list, albeit a significant
> one. How we better communicate this I don't know but I still believe we
> need a name for the "build system" component of Yocto. As soon as we
> think otherwise we limit ourselves just to being about a build system
> and miss a key part of what we're trying to do which is develop a *set*
> of embedded tools, not just the build system.
> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> yocto-ab mailing list
> yocto-ab at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto-ab
> _______________________________________________
> yocto-ab mailing list
> yocto-ab at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto-ab



More information about the yocto-ab mailing list