Yocto Project Quick Start Feedback


Darren Hart <dvhart@...>
 

Scott,

I received from first-time-user feedback regarding the quick start page.
I thought it was good stuff that you should here and consider
incorporating into the document.

1) There is too much introduction, education, and Note blocks before
we get the user going. The quick start is really about getting them
going as quickly as possible:

o Package install
o Download
o Build

There are four "pages" of detail before we get to installing
packages. 6 before we run any Yocto specific commands.

2) It can be confusing about what to download, since we mention the
Yocto Project Download page (which has a ton of stuff on it) before
we tell them to download edison with wget.

3) The Note blocks are huge and distracting for the content. Notes
should probably be light gray on white in a smaller font, rather
than white on dark gray. They distract from the primary content.

4) There probably is no need to separate "The Linux Distribution" from
"The Packages". These convey similar information, and consume a lot
of space doing so.

5) All the information is good, but it would be good to rearrange things
such that a new user can actually get a "Quick Start". The Notes
could be real footnotes, and things like the Development Environment
section should be "Further Reading" rather than "Required Reading"
for the "Quick Start".

6) As "Further Reading" we should include something like a "Bitbake
Flashcard" that outlines the common commands:
-c listtasks
-c compile -f
-c cleansstate (so people don't just start off with
"rm -rf tmp sstate-cache")
-e
-g depexp -u

I think a good goal would be that a user can run the qemu command
without having to scroll passed the initial screen on the Quick Start guide!

Consider:

Yocto Project Quick Start
=========================
Ubuntu Dependencies
-------------------
$ sudo dpkg-reconfigure dash
Select "No"
$ sudo apt-get install sed wget cvs subversion git-core coreutils \
unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
python-pysqlite2 diffstat help2man make gcc build-essential \
g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
mercurial autoconf automake groff libtool xterm

Fedora Dependencies
-------------------
$ sudo yum groupinstall "development tools"
$ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
unzip python-psyco perl texinfo texi2html diffstat openjade \
docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
autoconf automake libtool xterm

openSUSE Dependencies
---------------------
$ sudo zypper install python gcc gcc-c++ libtool \
subversion git chrpath automake make wget help2man \
diffstat texinfo mercurial freeglut-devel libSDL-devel

Download and Build
------------------
$ wget
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2
$ tar xjf poky-edison-6.0.tar.bz2
$ source poky-edison-6.0/oe-init-build-env edison-6.0-build
$ bitbake -k core-image-sato
$ runqemu qemux86

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Rifenbark, Scott M <scott.m.rifenbark@...>
 

Darren and all,

Good feedback on the YP QS. Here are my thoughts...

It seems that both Inaky and Mohamed are experienced embedded developers. From reading the thread "New User feedback from Inaky and Mohamed" it was obvious that you two know what you are doing in the embedded world. You guys represent one type of user YP needs to address. Your feedback points out that you are probably finding it tedious to wade through a bunch of introductory stuff before getting to a point where you actually use something. That is good feedback.

Other users that the YP QS must address consist of people investigating embedded development for the first time, non-Linux people, people unfamiliar with open source development in general, etc. Because the target audience of the YP QS is broad, it needs to fundamentally flow to satisfy the lowest common denominator - thus, its current flow and level of information. To date, yours is the first feedback that has indicated the QS needed to "cut to the chase" so to speak. This type of feedback is valid and would be expected from advanced users such as you.

I can make some changes to the QS structure to better address the advanced user. I can disrupt the advanced user's reading right up front and point them off to a section in the QS that essentially does what Darren is proposing as a flow here. The section can be a single page targeted for the advanced user that is not interested in introductory material but just wants the nuts and bolts.

I will also play around with the color scheme for the Notes and Tips in the QS. This type of feedback is highly subjective. What one person feels is distracting might not be distracting for another. That said, however, it is valid feedback and I will see about toning down the note boxes. I don't like footnotes for the type of information I am using for Notes and Tips. Footnotes tend to get lost and are best suited for anecdotal information that a reader could do without but for which might be curious.

Thanks for great feedback on the YP documentation. It is input like this that will continue to make YP and its documentation better.

Best,
Scott

-----Original Message-----
From: Darren Hart [mailto:dvhart@...]
Sent: Thursday, February 23, 2012 6:41 PM
To: Yocto Project
Cc: Rifenbark, Scott M; Perez-Gonzalez, Inaky; Abbas, Mohamed
Subject: Yocto Project Quick Start Feedback

Scott,

I received from first-time-user feedback regarding the quick start page.
I thought it was good stuff that you should here and consider
incorporating into the document.

1) There is too much introduction, education, and Note blocks before
we get the user going. The quick start is really about getting them
going as quickly as possible:

o Package install
o Download
o Build

There are four "pages" of detail before we get to installing
packages. 6 before we run any Yocto specific commands.

2) It can be confusing about what to download, since we mention the
Yocto Project Download page (which has a ton of stuff on it) before
we tell them to download edison with wget.

3) The Note blocks are huge and distracting for the content. Notes
should probably be light gray on white in a smaller font, rather
than white on dark gray. They distract from the primary content.

4) There probably is no need to separate "The Linux Distribution" from
"The Packages". These convey similar information, and consume a lot
of space doing so.

5) All the information is good, but it would be good to rearrange things
such that a new user can actually get a "Quick Start". The Notes
could be real footnotes, and things like the Development Environment
section should be "Further Reading" rather than "Required Reading"
for the "Quick Start".

6) As "Further Reading" we should include something like a "Bitbake
Flashcard" that outlines the common commands:
-c listtasks
-c compile -f
-c cleansstate (so people don't just start off with
"rm -rf tmp sstate-cache")
-e
-g depexp -u

I think a good goal would be that a user can run the qemu command
without having to scroll passed the initial screen on the Quick Start guide!

Consider:

Yocto Project Quick Start
=========================
Ubuntu Dependencies
-------------------
$ sudo dpkg-reconfigure dash
Select "No"
$ sudo apt-get install sed wget cvs subversion git-core coreutils \
unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
python-pysqlite2 diffstat help2man make gcc build-essential \
g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
mercurial autoconf automake groff libtool xterm

Fedora Dependencies
-------------------
$ sudo yum groupinstall "development tools"
$ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
unzip python-psyco perl texinfo texi2html diffstat openjade \
docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
autoconf automake libtool xterm

openSUSE Dependencies
---------------------
$ sudo zypper install python gcc gcc-c++ libtool \
subversion git chrpath automake make wget help2man \
diffstat texinfo mercurial freeglut-devel libSDL-devel

Download and Build
------------------
$ wget
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2
$ tar xjf poky-edison-6.0.tar.bz2
$ source poky-edison-6.0/oe-init-build-env edison-6.0-build
$ bitbake -k core-image-sato
$ runqemu qemux86

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


James Abernathy <mlabernathy80@...>
 

On Feb 24, 2012, at 10:43 AM, Rifenbark, Scott M wrote:

Darren and all,

Good feedback on the YP QS. Here are my thoughts...

It seems that both Inaky and Mohamed are experienced embedded developers. From reading the thread "New User feedback from Inaky and Mohamed" it was obvious that you two know what you are doing in the embedded world. You guys represent one type of user YP needs to address. Your feedback points out that you are probably finding it tedious to wade through a bunch of introductory stuff before getting to a point where you actually use something. That is good feedback.

Other users that the YP QS must address consist of people investigating embedded development for the first time, non-Linux people, people unfamiliar with open source development in general, etc. Because the target audience of the YP QS is broad, it needs to fundamentally flow to satisfy the lowest common denominator - thus, its current flow and level of information. To date, yours is the first feedback that has indicated the QS needed to "cut to the chase" so to speak. This type of feedback is valid and would be expected from advanced users such as you.

I can make some changes to the QS structure to better address the advanced user. I can disrupt the advanced user's reading right up front and point them off to a section in the QS that essentially does what Darren is proposing as a flow here. The section can be a single page targeted for the advanced user that is not interested in introductory material but just wants the nuts and bolts.

I will also play around with the color scheme for the Notes and Tips in the QS. This type of feedback is highly subjective. What one person feels is distracting might not be distracting for another. That said, however, it is valid feedback and I will see about toning down the note boxes. I don't like footnotes for the type of information I am using for Notes and Tips. Footnotes tend to get lost and are best suited for anecdotal information that a reader could do without but for which might be curious.
Scott,

Maybe borrowing from the idea that the Dummies guides have. They mark the sections for beginning, and for those who want/need more detail. They use icons in the margins for: Technical stuff, Tip, Remember, Warning, etc. Maybe something like that? All of my programming knowledge since Kernighan & Ritchie comes from Duummies guides. That's why I'm an expert dummy :-)

Jim A


Thanks for great feedback on the YP documentation. It is input like this that will continue to make YP and its documentation better.

Best,
Scott



-----Original Message-----
From: Darren Hart [mailto:dvhart@...]
Sent: Thursday, February 23, 2012 6:41 PM
To: Yocto Project
Cc: Rifenbark, Scott M; Perez-Gonzalez, Inaky; Abbas, Mohamed
Subject: Yocto Project Quick Start Feedback

Scott,

I received from first-time-user feedback regarding the quick start page.
I thought it was good stuff that you should here and consider
incorporating into the document.

1) There is too much introduction, education, and Note blocks before
we get the user going. The quick start is really about getting them
going as quickly as possible:

o Package install
o Download
o Build

There are four "pages" of detail before we get to installing
packages. 6 before we run any Yocto specific commands.

2) It can be confusing about what to download, since we mention the
Yocto Project Download page (which has a ton of stuff on it) before
we tell them to download edison with wget.

3) The Note blocks are huge and distracting for the content. Notes
should probably be light gray on white in a smaller font, rather
than white on dark gray. They distract from the primary content.

4) There probably is no need to separate "The Linux Distribution" from
"The Packages". These convey similar information, and consume a lot
of space doing so.

5) All the information is good, but it would be good to rearrange things
such that a new user can actually get a "Quick Start". The Notes
could be real footnotes, and things like the Development Environment
section should be "Further Reading" rather than "Required Reading"
for the "Quick Start".

6) As "Further Reading" we should include something like a "Bitbake
Flashcard" that outlines the common commands:
-c listtasks
-c compile -f
-c cleansstate (so people don't just start off with
"rm -rf tmp sstate-cache")
-e
-g depexp -u

I think a good goal would be that a user can run the qemu command
without having to scroll passed the initial screen on the Quick Start guide!

Consider:

Yocto Project Quick Start
=========================
Ubuntu Dependencies
-------------------
$ sudo dpkg-reconfigure dash
Select "No"
$ sudo apt-get install sed wget cvs subversion git-core coreutils \
unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
python-pysqlite2 diffstat help2man make gcc build-essential \
g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
mercurial autoconf automake groff libtool xterm

Fedora Dependencies
-------------------
$ sudo yum groupinstall "development tools"
$ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
unzip python-psyco perl texinfo texi2html diffstat openjade \
docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
autoconf automake libtool xterm

openSUSE Dependencies
---------------------
$ sudo zypper install python gcc gcc-c++ libtool \
subversion git chrpath automake make wget help2man \
diffstat texinfo mercurial freeglut-devel libSDL-devel

Download and Build
------------------
$ wget
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2
$ tar xjf poky-edison-6.0.tar.bz2
$ source poky-edison-6.0/oe-init-build-env edison-6.0-build
$ bitbake -k core-image-sato
$ runqemu qemux86

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


William Mills <wmills@...>
 

Scott, Darren & All,

First I want to say I am very excited to see this deep and targeted discussion on the docs. I think it says very good things about where yocto is as a project.

Just a thought: Something that often works well in both teaching and movies is to start the story right at some action and then go and explain how you got there. (No I am not talking about Memento.)

That said, when I first tried Yocto/Poky I was not new to embedded or OE and just wanted the meat of how poky expected me to do this. I really did not have an issue skimming and finding what I was looking for and the background information aclimated me to some "Yocto-speak" and customs.

I read through the notes & tips. I thought they were all important and I have seen a number of people get caught on each of them.

The only exception I found was the tip of rm_work. I think this should be removed. We have seen rm_work interfere with sstate and I have not seen it decrease the peak disk space needed, just the end state. Perhaps this is better than when I last tested. At any rate I don't think we run any automated builds with rm_work enabled so should we really be encouraging the new user to try this out?

I don't think we should delete a lot from the QS and any reorder is probably fine tunning.

Bill

On 02/24/2012 10:43 AM, Rifenbark, Scott M wrote:
Darren and all,

Good feedback on the YP QS. Here are my thoughts...

It seems that both Inaky and Mohamed are experienced embedded developers. From reading the thread "New User feedback from Inaky and Mohamed" it was obvious that you two know what you are doing in the embedded world. You guys represent one type of user YP needs to address. Your feedback points out that you are probably finding it tedious to wade through a bunch of introductory stuff before getting to a point where you actually use something. That is good feedback.

Other users that the YP QS must address consist of people investigating embedded development for the first time, non-Linux people, people unfamiliar with open source development in general, etc. Because the target audience of the YP QS is broad, it needs to fundamentally flow to satisfy the lowest common denominator - thus, its current flow and level of information. To date, yours is the first feedback that has indicated the QS needed to "cut to the chase" so to speak. This type of feedback is valid and would be expected from advanced users such as you.

I can make some changes to the QS structure to better address the advanced user. I can disrupt the advanced user's reading right up front and point them off to a section in the QS that essentially does what Darren is proposing as a flow here. The section can be a single page targeted for the advanced user that is not interested in introductory material but just wants the nuts and bolts.

I will also play around with the color scheme for the Notes and Tips in the QS. This type of feedback is highly subjective. What one person feels is distracting might not be distracting for another. That said, however, it is valid feedback and I will see about toning down the note boxes. I don't like footnotes for the type of information I am using for Notes and Tips. Footnotes tend to get lost and are best suited for anecdotal information that a reader could do without but for which might be curious.

Thanks for great feedback on the YP documentation. It is input like this that will continue to make YP and its documentation better.

Best,
Scott



-----Original Message-----
From: Darren Hart [mailto:dvhart@...]
Sent: Thursday, February 23, 2012 6:41 PM
To: Yocto Project
Cc: Rifenbark, Scott M; Perez-Gonzalez, Inaky; Abbas, Mohamed
Subject: Yocto Project Quick Start Feedback

Scott,

I received from first-time-user feedback regarding the quick start page.
I thought it was good stuff that you should here and consider
incorporating into the document.

1) There is too much introduction, education, and Note blocks before
we get the user going. The quick start is really about getting them
going as quickly as possible:

o Package install
o Download
o Build

There are four "pages" of detail before we get to installing
packages. 6 before we run any Yocto specific commands.

2) It can be confusing about what to download, since we mention the
Yocto Project Download page (which has a ton of stuff on it) before
we tell them to download edison with wget.

3) The Note blocks are huge and distracting for the content. Notes
should probably be light gray on white in a smaller font, rather
than white on dark gray. They distract from the primary content.

4) There probably is no need to separate "The Linux Distribution" from
"The Packages". These convey similar information, and consume a lot
of space doing so.

5) All the information is good, but it would be good to rearrange things
such that a new user can actually get a "Quick Start". The Notes
could be real footnotes, and things like the Development Environment
section should be "Further Reading" rather than "Required Reading"
for the "Quick Start".

6) As "Further Reading" we should include something like a "Bitbake
Flashcard" that outlines the common commands:
-c listtasks
-c compile -f
-c cleansstate (so people don't just start off with
"rm -rf tmp sstate-cache")
-e
-g depexp -u

I think a good goal would be that a user can run the qemu command
without having to scroll passed the initial screen on the Quick Start guide!

Consider:

Yocto Project Quick Start
=========================
Ubuntu Dependencies
-------------------
$ sudo dpkg-reconfigure dash
Select "No"
$ sudo apt-get install sed wget cvs subversion git-core coreutils \
unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
python-pysqlite2 diffstat help2man make gcc build-essential \
g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
mercurial autoconf automake groff libtool xterm

Fedora Dependencies
-------------------
$ sudo yum groupinstall "development tools"
$ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
unzip python-psyco perl texinfo texi2html diffstat openjade \
docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
autoconf automake libtool xterm

openSUSE Dependencies
---------------------
$ sudo zypper install python gcc gcc-c++ libtool \
subversion git chrpath automake make wget help2man \
diffstat texinfo mercurial freeglut-devel libSDL-devel

Download and Build
------------------
$ wget
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2
$ tar xjf poky-edison-6.0.tar.bz2
$ source poky-edison-6.0/oe-init-build-env edison-6.0-build
$ bitbake -k core-image-sato
$ runqemu qemux86


Rifenbark, Scott M <scott.m.rifenbark@...>
 

Bill,

Thanks for this level of feedback. I'm especially encouraged to hear that the QS seemed to work for your level of expertise, which also seems to be in the expert area. I think fact that you were not bothered by skimming for essential information reinforces the subjectivity of it all.

The "movie" angle is interesting. Picture this... the opening 1/2 page sets up the packages for Ubuntu, downloads files, builds core-image-sata, and runs qemu. All this done without even telling anyone what YP is. Follow that by "what just happened... we just built and ran an image using the Yocto Project. Then the QS launches into the "Welcome" stuff and flows on as normal. That would be a unique beginning for a technical manual.

The rm_work comment is concerning. It sounds like that should just be removed.

Scott

-----Original Message-----
From: William Mills [mailto:wmills@...]
Sent: Friday, February 24, 2012 11:47 AM
To: Rifenbark, Scott M
Cc: Darren Hart; Yocto Project; Abbas, Mohamed; Purdie, Richard; Perez-Gonzalez, Inaky
Subject: Re: [yocto] Yocto Project Quick Start Feedback

Scott, Darren & All,

First I want to say I am very excited to see this deep and targeted
discussion on the docs. I think it says very good things about where
yocto is as a project.

Just a thought: Something that often works well in both teaching and
movies is to start the story right at some action and then go and
explain how you got there. (No I am not talking about Memento.)

That said, when I first tried Yocto/Poky I was not new to embedded or OE
and just wanted the meat of how poky expected me to do this. I really
did not have an issue skimming and finding what I was looking for and
the background information aclimated me to some "Yocto-speak" and customs.

I read through the notes & tips. I thought they were all important and
I have seen a number of people get caught on each of them.

The only exception I found was the tip of rm_work. I think this should
be removed. We have seen rm_work interfere with sstate and I have not
seen it decrease the peak disk space needed, just the end state.
Perhaps this is better than when I last tested. At any rate I don't
think we run any automated builds with rm_work enabled so should we
really be encouraging the new user to try this out?

I don't think we should delete a lot from the QS and any reorder is
probably fine tunning.

Bill

On 02/24/2012 10:43 AM, Rifenbark, Scott M wrote:
Darren and all,

Good feedback on the YP QS. Here are my thoughts...

It seems that both Inaky and Mohamed are experienced embedded developers. From reading the thread "New User feedback from Inaky and Mohamed" it was obvious that you two know what you are doing in the embedded world. You guys represent one type of user YP needs to address. Your feedback points out that you are probably finding it tedious to wade through a bunch of introductory stuff before getting to a point where you actually use something. That is good feedback.

Other users that the YP QS must address consist of people investigating embedded development for the first time, non-Linux people, people unfamiliar with open source development in general, etc. Because the target audience of the YP QS is broad, it needs to fundamentally flow to satisfy the lowest common denominator - thus, its current flow and level of information. To date, yours is the first feedback that has indicated the QS needed to "cut to the chase" so to speak. This type of feedback is valid and would be expected from advanced users such as you.

I can make some changes to the QS structure to better address the advanced user. I can disrupt the advanced user's reading right up front and point them off to a section in the QS that essentially does what Darren is proposing as a flow here. The section can be a single page targeted for the advanced user that is not interested in introductory material but just wants the nuts and bolts.

I will also play around with the color scheme for the Notes and Tips in the QS. This type of feedback is highly subjective. What one person feels is distracting might not be distracting for another. That said, however, it is valid feedback and I will see about toning down the note boxes. I don't like footnotes for the type of information I am using for Notes and Tips. Footnotes tend to get lost and are best suited for anecdotal information that a reader could do without but for which might be curious.

Thanks for great feedback on the YP documentation. It is input like this that will continue to make YP and its documentation better.

Best,
Scott



-----Original Message-----
From: Darren Hart [mailto:dvhart@...]
Sent: Thursday, February 23, 2012 6:41 PM
To: Yocto Project
Cc: Rifenbark, Scott M; Perez-Gonzalez, Inaky; Abbas, Mohamed
Subject: Yocto Project Quick Start Feedback

Scott,

I received from first-time-user feedback regarding the quick start page.
I thought it was good stuff that you should here and consider
incorporating into the document.

1) There is too much introduction, education, and Note blocks before
we get the user going. The quick start is really about getting them
going as quickly as possible:

o Package install
o Download
o Build

There are four "pages" of detail before we get to installing
packages. 6 before we run any Yocto specific commands.

2) It can be confusing about what to download, since we mention the
Yocto Project Download page (which has a ton of stuff on it) before
we tell them to download edison with wget.

3) The Note blocks are huge and distracting for the content. Notes
should probably be light gray on white in a smaller font, rather
than white on dark gray. They distract from the primary content.

4) There probably is no need to separate "The Linux Distribution" from
"The Packages". These convey similar information, and consume a lot
of space doing so.

5) All the information is good, but it would be good to rearrange things
such that a new user can actually get a "Quick Start". The Notes
could be real footnotes, and things like the Development Environment
section should be "Further Reading" rather than "Required Reading"
for the "Quick Start".

6) As "Further Reading" we should include something like a "Bitbake
Flashcard" that outlines the common commands:
-c listtasks
-c compile -f
-c cleansstate (so people don't just start off with
"rm -rf tmp sstate-cache")
-e
-g depexp -u

I think a good goal would be that a user can run the qemu command
without having to scroll passed the initial screen on the Quick Start guide!

Consider:

Yocto Project Quick Start
=========================
Ubuntu Dependencies
-------------------
$ sudo dpkg-reconfigure dash
Select "No"
$ sudo apt-get install sed wget cvs subversion git-core coreutils \
unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
python-pysqlite2 diffstat help2man make gcc build-essential \
g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
mercurial autoconf automake groff libtool xterm

Fedora Dependencies
-------------------
$ sudo yum groupinstall "development tools"
$ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
unzip python-psyco perl texinfo texi2html diffstat openjade \
docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
autoconf automake libtool xterm

openSUSE Dependencies
---------------------
$ sudo zypper install python gcc gcc-c++ libtool \
subversion git chrpath automake make wget help2man \
diffstat texinfo mercurial freeglut-devel libSDL-devel

Download and Build
------------------
$ wget
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2
$ tar xjf poky-edison-6.0.tar.bz2
$ source poky-edison-6.0/oe-init-build-env edison-6.0-build
$ bitbake -k core-image-sato
$ runqemu qemux86


William Mills <wmills@...>
 

On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:
The "movie" angle is interesting. Picture this... the opening 1/2 page sets up the packages for Ubuntu, downloads files, builds core-image-sata, and runs qemu. All this done without even telling anyone what YP is. Follow that by "what just happened... we just built and ran an image using the Yocto Project. Then the QS launches into the "Welcome" stuff and flows on as normal. That would be a unique beginning for a technical manual.
I sense some derision in your word "unique"? Thats fine, your doing most of the work and you have to be happy with it.

However I don't think it is unique. Yes it would be a bad approuch to use in a reference manual but I have found a number of intros/tutorials start this way and I always enjoy the approuch. Perhaps the QS at only 9 printed pages is too short to be structured this way. The QS guide itself is just this "taste of the bigger picture" for the full doc set.

As I said, just some thoughts.

Bill


Rifenbark, Scott M <scott.m.rifenbark@...>
 

Bill,

You are reading me wrong. I actually like the idea. It fits a Quick Start. I was going to divert the expert reader anyway. The reason I tried to paint the picture here was to see what others thought of the idea.

Scott

-----Original Message-----
From: William Mills [mailto:wmills@...]
Sent: Friday, February 24, 2012 1:07 PM
To: Rifenbark, Scott M
Cc: Darren Hart; Yocto Project; Abbas, Mohamed; Purdie, Richard; Perez-Gonzalez, Inaky
Subject: Re: [yocto] Yocto Project Quick Start Feedback

On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:
The "movie" angle is interesting. Picture this... the opening 1/2 page sets up the packages for Ubuntu, downloads files, builds core-image-sata, and runs qemu. All this done without even telling anyone what YP is. Follow that by "what just happened... we just built and ran an image using the Yocto Project. Then the QS launches into the "Welcome" stuff and flows on as normal. That would be a unique beginning for a technical manual.
I sense some derision in your word "unique"? Thats fine, your doing
most of the work and you have to be happy with it.

However I don't think it is unique. Yes it would be a bad approuch to
use in a reference manual but I have found a number of intros/tutorials
start this way and I always enjoy the approuch. Perhaps the QS at only
9 printed pages is too short to be structured this way. The QS guide
itself is just this "taste of the bigger picture" for the full doc set.

As I said, just some thoughts.

Bill


Barros Pena, Belen <belen.barros.pena@...>
 

Hi all,

Sorry to jump in. After reading the discussion I went to check the web
traffic data for the Quick Start page, thinking that it might give us some
useful information about how people are using the content and how to
improve it.

Unfortunately, it looks like the Google Analytics script is missing from
http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.
html, so no web traffic information is available.

Before making changes to the content, maybe we could add the Google
Analytics tracking script to the page and see what comes out of it. By
providing volume, the data could help us break the 'personal opinion
deadlock'.

What do you think?

Belen


On 24/02/2012 22:19, "Rifenbark, Scott M" <scott.m.rifenbark@...>
wrote:

Bill,

You are reading me wrong. I actually like the idea. It fits a Quick
Start. I was going to divert the expert reader anyway. The reason I
tried to paint the picture here was to see what others thought of the
idea.

Scott

-----Original Message-----
From: William Mills [mailto:wmills@...]
Sent: Friday, February 24, 2012 1:07 PM
To: Rifenbark, Scott M
Cc: Darren Hart; Yocto Project; Abbas, Mohamed; Purdie, Richard;
Perez-Gonzalez, Inaky
Subject: Re: [yocto] Yocto Project Quick Start Feedback

On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:
The "movie" angle is interesting. Picture this... the opening 1/2 page
sets up the packages for Ubuntu, downloads files, builds
core-image-sata, and runs qemu. All this done without even telling
anyone what YP is. Follow that by "what just happened... we just built
and ran an image using the Yocto Project. Then the QS launches into the
"Welcome" stuff and flows on as normal. That would be a unique
beginning for a technical manual.
I sense some derision in your word "unique"? Thats fine, your doing
most of the work and you have to be happy with it.

However I don't think it is unique. Yes it would be a bad approuch to
use in a reference manual but I have found a number of intros/tutorials
start this way and I always enjoy the approuch. Perhaps the QS at only
9 printed pages is too short to be structured this way. The QS guide
itself is just this "taste of the bigger picture" for the full doc set.

As I said, just some thoughts.

Bill
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Rifenbark, Scott M <scott.m.rifenbark@...>
 

Good suggestion.

-----Original Message-----
From: Barros Pena, Belen
Sent: Monday, February 27, 2012 6:02 AM
To: Rifenbark, Scott M; William Mills
Cc: Abbas, Mohamed; Yocto Project; Darren Hart; Perez-Gonzalez, Inaky; Purdie, Richard
Subject: Re: [yocto] Yocto Project Quick Start Feedback

Hi all,

Sorry to jump in. After reading the discussion I went to check the web
traffic data for the Quick Start page, thinking that it might give us some
useful information about how people are using the content and how to
improve it.

Unfortunately, it looks like the Google Analytics script is missing from
http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.
html, so no web traffic information is available.

Before making changes to the content, maybe we could add the Google
Analytics tracking script to the page and see what comes out of it. By
providing volume, the data could help us break the 'personal opinion
deadlock'.

What do you think?

Belen


On 24/02/2012 22:19, "Rifenbark, Scott M" <scott.m.rifenbark@...>
wrote:

Bill,

You are reading me wrong. I actually like the idea. It fits a Quick
Start. I was going to divert the expert reader anyway. The reason I
tried to paint the picture here was to see what others thought of the
idea.

Scott

-----Original Message-----
From: William Mills [mailto:wmills@...]
Sent: Friday, February 24, 2012 1:07 PM
To: Rifenbark, Scott M
Cc: Darren Hart; Yocto Project; Abbas, Mohamed; Purdie, Richard;
Perez-Gonzalez, Inaky
Subject: Re: [yocto] Yocto Project Quick Start Feedback

On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:
The "movie" angle is interesting. Picture this... the opening 1/2 page
sets up the packages for Ubuntu, downloads files, builds
core-image-sata, and runs qemu. All this done without even telling
anyone what YP is. Follow that by "what just happened... we just built
and ran an image using the Yocto Project. Then the QS launches into the
"Welcome" stuff and flows on as normal. That would be a unique
beginning for a technical manual.
I sense some derision in your word "unique"? Thats fine, your doing
most of the work and you have to be happy with it.

However I don't think it is unique. Yes it would be a bad approuch to
use in a reference manual but I have found a number of intros/tutorials
start this way and I always enjoy the approuch. Perhaps the QS at only
9 printed pages is too short to be structured this way. The QS guide
itself is just this "taste of the bigger picture" for the full doc set.

As I said, just some thoughts.

Bill
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Barros Pena, Belen <belen.barros.pena@...>
 

Thanks, Scott. Do you know who manages the CMS? I guess that's the person
who could add the GA script to the page.

Cheers

Belen

On 27/02/2012 15:00, "Rifenbark, Scott M" <scott.m.rifenbark@...>
wrote:

Good suggestion.

-----Original Message-----
From: Barros Pena, Belen
Sent: Monday, February 27, 2012 6:02 AM
To: Rifenbark, Scott M; William Mills
Cc: Abbas, Mohamed; Yocto Project; Darren Hart; Perez-Gonzalez, Inaky;
Purdie, Richard
Subject: Re: [yocto] Yocto Project Quick Start Feedback

Hi all,

Sorry to jump in. After reading the discussion I went to check the web
traffic data for the Quick Start page, thinking that it might give us some
useful information about how people are using the content and how to
improve it.

Unfortunately, it looks like the Google Analytics script is missing from
http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs
.
html, so no web traffic information is available.

Before making changes to the content, maybe we could add the Google
Analytics tracking script to the page and see what comes out of it. By
providing volume, the data could help us break the 'personal opinion
deadlock'.

What do you think?

Belen


On 24/02/2012 22:19, "Rifenbark, Scott M" <scott.m.rifenbark@...>
wrote:

Bill,

You are reading me wrong. I actually like the idea. It fits a Quick
Start. I was going to divert the expert reader anyway. The reason I
tried to paint the picture here was to see what others thought of the
idea.

Scott

-----Original Message-----
From: William Mills [mailto:wmills@...]
Sent: Friday, February 24, 2012 1:07 PM
To: Rifenbark, Scott M
Cc: Darren Hart; Yocto Project; Abbas, Mohamed; Purdie, Richard;
Perez-Gonzalez, Inaky
Subject: Re: [yocto] Yocto Project Quick Start Feedback

On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:
The "movie" angle is interesting. Picture this... the opening 1/2 page
sets up the packages for Ubuntu, downloads files, builds
core-image-sata, and runs qemu. All this done without even telling
anyone what YP is. Follow that by "what just happened... we just built
and ran an image using the Yocto Project. Then the QS launches into the
"Welcome" stuff and flows on as normal. That would be a unique
beginning for a technical manual.
I sense some derision in your word "unique"? Thats fine, your doing
most of the work and you have to be happy with it.

However I don't think it is unique. Yes it would be a bad approuch to
use in a reference manual but I have found a number of intros/tutorials
start this way and I always enjoy the approuch. Perhaps the QS at only
9 printed pages is too short to be structured this way. The QS guide
itself is just this "taste of the bigger picture" for the full doc set.

As I said, just some thoughts.

Bill
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Rifenbark, Scott M <scott.m.rifenbark@...>
 

I notified the person here that should know how to do that stuff.

Thanks,
Scott

-----Original Message-----
From: Barros Pena, Belen
Sent: Monday, February 27, 2012 9:23 AM
To: Rifenbark, Scott M; William Mills
Cc: Abbas, Mohamed; Yocto Project; Darren Hart; Perez-Gonzalez, Inaky; Purdie, Richard
Subject: Re: [yocto] Yocto Project Quick Start Feedback

Thanks, Scott. Do you know who manages the CMS? I guess that's the person
who could add the GA script to the page.

Cheers

Belen

On 27/02/2012 15:00, "Rifenbark, Scott M" <scott.m.rifenbark@...>
wrote:

Good suggestion.

-----Original Message-----
From: Barros Pena, Belen
Sent: Monday, February 27, 2012 6:02 AM
To: Rifenbark, Scott M; William Mills
Cc: Abbas, Mohamed; Yocto Project; Darren Hart; Perez-Gonzalez, Inaky;
Purdie, Richard
Subject: Re: [yocto] Yocto Project Quick Start Feedback

Hi all,

Sorry to jump in. After reading the discussion I went to check the web
traffic data for the Quick Start page, thinking that it might give us some
useful information about how people are using the content and how to
improve it.

Unfortunately, it looks like the Google Analytics script is missing from
http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs
.
html, so no web traffic information is available.

Before making changes to the content, maybe we could add the Google
Analytics tracking script to the page and see what comes out of it. By
providing volume, the data could help us break the 'personal opinion
deadlock'.

What do you think?

Belen


On 24/02/2012 22:19, "Rifenbark, Scott M" <scott.m.rifenbark@...>
wrote:

Bill,

You are reading me wrong. I actually like the idea. It fits a Quick
Start. I was going to divert the expert reader anyway. The reason I
tried to paint the picture here was to see what others thought of the
idea.

Scott

-----Original Message-----
From: William Mills [mailto:wmills@...]
Sent: Friday, February 24, 2012 1:07 PM
To: Rifenbark, Scott M
Cc: Darren Hart; Yocto Project; Abbas, Mohamed; Purdie, Richard;
Perez-Gonzalez, Inaky
Subject: Re: [yocto] Yocto Project Quick Start Feedback

On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:
The "movie" angle is interesting. Picture this... the opening 1/2 page
sets up the packages for Ubuntu, downloads files, builds
core-image-sata, and runs qemu. All this done without even telling
anyone what YP is. Follow that by "what just happened... we just built
and ran an image using the Yocto Project. Then the QS launches into the
"Welcome" stuff and flows on as normal. That would be a unique
beginning for a technical manual.
I sense some derision in your word "unique"? Thats fine, your doing
most of the work and you have to be happy with it.

However I don't think it is unique. Yes it would be a bad approuch to
use in a reference manual but I have found a number of intros/tutorials
start this way and I always enjoy the approuch. Perhaps the QS at only
9 printed pages is too short to be structured this way. The QS guide
itself is just this "taste of the bigger picture" for the full doc set.

As I said, just some thoughts.

Bill
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Osier-mixon, Jeffrey <jeffrey.osier-mixon@...>
 

As this page is regenerated each time the document changes, we'll need to find a way to add the script to the source so it isn't simply overwritten. Scott, I'll ping you separately to describe how to do this.

On Mon, Feb 27, 2012 at 7:27 AM, Rifenbark, Scott M <scott.m.rifenbark@...> wrote:
I notified the person here that should know how to do that stuff.

Thanks,
Scott

-----Original Message-----
From: Barros Pena, Belen
Sent: Monday, February 27, 2012 9:23 AM
To: Rifenbark, Scott M; William Mills
Cc: Abbas, Mohamed; Yocto Project; Darren Hart; Perez-Gonzalez, Inaky; Purdie, Richard
Subject: Re: [yocto] Yocto Project Quick Start Feedback

Thanks, Scott. Do you know who manages the CMS? I guess that's the person
who could add the GA script to the page.

Cheers

Belen

On 27/02/2012 15:00, "Rifenbark, Scott M" <scott.m.rifenbark@...>
wrote:

>Good suggestion.
>
>-----Original Message-----
>From: Barros Pena, Belen
>Sent: Monday, February 27, 2012 6:02 AM
>To: Rifenbark, Scott M; William Mills
>Cc: Abbas, Mohamed; Yocto Project; Darren Hart; Perez-Gonzalez, Inaky;
>Purdie, Richard
>Subject: Re: [yocto] Yocto Project Quick Start Feedback
>
>Hi all,
>
>Sorry to jump in. After reading the discussion I went to check the web
>traffic data for the Quick Start page, thinking that it might give us some
>useful information about how people are using the content and how to
>improve it.
>
>Unfortunately, it looks like the Google Analytics script is missing from
>http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs
>.
>html, so no web traffic information is available.
>
>Before making changes to the content, maybe we could add the Google
>Analytics tracking script to the page and see what comes out of it. By
>providing volume, the data could help us break the 'personal opinion
>deadlock'.
>
>What do you think?
>
>Belen
>
>
>On 24/02/2012 22:19, "Rifenbark, Scott M" <scott.m.rifenbark@...>
>wrote:
>
>>Bill,
>>
>>You are reading me wrong.  I actually like the idea.  It fits a Quick
>>Start.  I was going to divert the expert reader anyway.  The reason I
>>tried to paint the picture here was to see what others thought of the
>>idea.
>>
>>Scott
>>
>>-----Original Message-----
>>From: William Mills [mailto:wmills@...]
>>Sent: Friday, February 24, 2012 1:07 PM
>>To: Rifenbark, Scott M
>>Cc: Darren Hart; Yocto Project; Abbas, Mohamed; Purdie, Richard;
>>Perez-Gonzalez, Inaky
>>Subject: Re: [yocto] Yocto Project Quick Start Feedback
>>
>>On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:
>>> The "movie" angle is interesting.  Picture this... the opening 1/2 page
>>>sets up the packages for Ubuntu, downloads files, builds
>>>core-image-sata, and runs qemu.  All this done without even telling
>>>anyone what YP is.  Follow that by "what just happened... we just built
>>>and ran an image using the Yocto Project.  Then the QS launches into the
>>>"Welcome" stuff and flows on as normal.  That would be a unique
>>>beginning for a technical manual.
>>
>>I sense some derision in your word "unique"?  Thats fine, your doing
>>most of the work and you have to be happy with it.
>>
>>However I don't think it is unique.  Yes it would be a bad approuch to
>>use in a reference manual but I have found a number of  intros/tutorials
>>start this way and I always enjoy the approuch.  Perhaps the QS at only
>>9 printed pages is too short to be structured this way.  The QS guide
>>itself is just this "taste of the bigger picture" for the full doc set.
>>
>>As I said, just some thoughts.
>>
>>Bill
>>_______________________________________________
>>yocto mailing list
>>yocto@...
>>https://lists.yoctoproject.org/listinfo/yocto
>

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto



--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org


Rifenbark, Scott M <scott.m.rifenbark@...>
 

Jeff,

 

Sounds good.

 

From: Osier-mixon, Jeffrey [mailto:jeffrey.osier-mixon@...]
Sent: Monday, February 27, 2012 12:01 PM
To: Rifenbark, Scott M
Cc: Barros Pena, Belen; William Mills; Abbas, Mohamed; Yocto Project; Darren Hart; Perez-Gonzalez, Inaky; Purdie, Richard
Subject: Re: [yocto] Yocto Project Quick Start Feedback

 

As this page is regenerated each time the document changes, we'll need to find a way to add the script to the source so it isn't simply overwritten. Scott, I'll ping you separately to describe how to do this.

On Mon, Feb 27, 2012 at 7:27 AM, Rifenbark, Scott M <scott.m.rifenbark@...> wrote:

I notified the person here that should know how to do that stuff.

Thanks,
Scott


-----Original Message-----
From: Barros Pena, Belen

Sent: Monday, February 27, 2012 9:23 AM
To: Rifenbark, Scott M; William Mills
Cc: Abbas, Mohamed; Yocto Project; Darren Hart; Perez-Gonzalez, Inaky; Purdie, Richard
Subject: Re: [yocto] Yocto Project Quick Start Feedback

Thanks, Scott. Do you know who manages the CMS? I guess that's the person
who could add the GA script to the page.

Cheers

Belen

On 27/02/2012 15:00, "Rifenbark, Scott M" <scott.m.rifenbark@...>
wrote:

>Good suggestion.
>
>-----Original Message-----
>From: Barros Pena, Belen
>Sent: Monday, February 27, 2012 6:02 AM
>To: Rifenbark, Scott M; William Mills
>Cc: Abbas, Mohamed; Yocto Project; Darren Hart; Perez-Gonzalez, Inaky;
>Purdie, Richard
>Subject: Re: [yocto] Yocto Project Quick Start Feedback
>
>Hi all,
>
>Sorry to jump in. After reading the discussion I went to check the web
>traffic data for the Quick Start page, thinking that it might give us some
>useful information about how people are using the content and how to
>improve it.
>
>Unfortunately, it looks like the Google Analytics script is missing from
>http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs
>.
>html, so no web traffic information is available.
>
>Before making changes to the content, maybe we could add the Google
>Analytics tracking script to the page and see what comes out of it. By
>providing volume, the data could help us break the 'personal opinion
>deadlock'.
>
>What do you think?
>
>Belen
>
>
>On 24/02/2012 22:19, "Rifenbark, Scott M" <scott.m.rifenbark@...>
>wrote:
>
>>Bill,
>>
>>You are reading me wrong.  I actually like the idea.  It fits a Quick
>>Start.  I was going to divert the expert reader anyway.  The reason I
>>tried to paint the picture here was to see what others thought of the
>>idea.
>>
>>Scott
>>
>>-----Original Message-----
>>From: William Mills [mailto:wmills@...]
>>Sent: Friday, February 24, 2012 1:07 PM
>>To: Rifenbark, Scott M
>>Cc: Darren Hart; Yocto Project; Abbas, Mohamed; Purdie, Richard;
>>Perez-Gonzalez, Inaky
>>Subject: Re: [yocto] Yocto Project Quick Start Feedback
>>
>>On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:
>>> The "movie" angle is interesting.  Picture this... the opening 1/2 page
>>>sets up the packages for Ubuntu, downloads files, builds
>>>core-image-sata, and runs qemu.  All this done without even telling
>>>anyone what YP is.  Follow that by "what just happened... we just built
>>>and ran an image using the Yocto Project.  Then the QS launches into the
>>>"Welcome" stuff and flows on as normal.  That would be a unique
>>>beginning for a technical manual.
>>
>>I sense some derision in your word "unique"?  Thats fine, your doing
>>most of the work and you have to be happy with it.
>>
>>However I don't think it is unique.  Yes it would be a bad approuch to
>>use in a reference manual but I have found a number of  intros/tutorials
>>start this way and I always enjoy the approuch.  Perhaps the QS at only
>>9 printed pages is too short to be structured this way.  The QS guide
>>itself is just this "taste of the bigger picture" for the full doc set.
>>
>>As I said, just some thoughts.
>>
>>Bill
>>_______________________________________________
>>yocto mailing list
>>yocto@...
>>https://lists.yoctoproject.org/listinfo/yocto
>

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto



 

--
Jeff Osier-Mixon http://jefro.net/blog

Yocto Project Community Manager @Intel http://yoctoproject.org