Andrea,
Thanks for the detailed feedback on the YP documentation. Agree that it is
difficult to meet the needs of the wide group of users and that it is difficult
to have the released documentation match that of the latest from the website.
The latest documentation is always under development and I fear will never
match the released documentation. One radical scheme to consider is releasing
a separate tarball for documentation that a user could download and then insert
into their poky repository on the local system. This would in a sense
de-couple the docs and the released poky tarball. Probably not a popular idea
among the team but an out-of-the-box one nonetheless.
We will continue to try and improve specific workflows based on specific target
audience needs. Feedback such as this helps.
Scott
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Andrea Galbusera
Sent: Friday, October 05, 2012 8:43 AM
To: yocto@yoctoproject.org
Subject: [yocto] Yocto Project 1.3 beta feedback
Below you can find my answers to the Yocto Project 1.3 beta testing survey.
Regards,
Andrea
Experience survey of using Yocto 1.3
Q: Which architecture did you choose to build?
A: qemuppc, beagleboard
Q: How easily were you able to build an image and boot an image?
A: Quite easily. I also took some time for reviewing the QS guide
which looks adequate to me either for newbies or users coming from
different build systems.
Q: Is there any surprise to you in the process of doing this Beta
testing? If so, would you please describe
it and tell us how you expected it to work?
A: Not really a surprise (already knew about that), but a very
pleasant experience was knotty2. It results cleaner than its
forever-scrolling parent.
Q: How do you like our HOB interface? Please provide us with your
thoughts and suggestions on HOB
interface and functionality.
A: I like the hob design. It actually does not support yet a few
workflows that I consider much important for my work: i.e. adding new
recipes, supporting kernel development (mainly configuration,
patching). I understand not every user does require them and hence I
don't consider myself as the actual hob's average target user. Anyway
I appreciate the project is working on more intuitive tools like HOB
and I look forward to see if similar effort will also bring us webhob
experience in the future. People doing mainly package integration
would benefit the best from HOB, since they need not to dig into the
build system's details.
Q: Was it easy to find the support you needed to build and boot an image?
A: Procedures for the official emulated target are well documented and
clear enough for the task required by this beta testing. Support for
deploying and booting on reference real-hardware target is a little
bit lacking but a lot of resources and documentation are already
available online and I agree on not duplicating reference material.
Q: Which Bugzilla reports did you submit?
A: None till now. Still investigating on some oddities and discussing
with the team on IRC. Also hit bug #3135, which is already fixed in
master now.
Q: Did you try anything else with Yocto 1.3?
A: Building an SDK and investigating procedures to deploy toolchains,
SDKs and ADTs is one of my primary goals. I built toolchains for the
arm architecture and tested the environment to build a simple C
source. Relocatable SDK is a good improvement in term of flexibility
when deploying for application developers. The beta snapshot does
bring bug #3135, but it's already fixed in master.
Q: What would you like to have in Yocto Project for future releases?
A: Documentation as a whole IMHO should and must improve a bit to make
it more useful for reference. At the design level, I see the team is
working very well, by keeping the documentation in a single place:
this grants us consistency and its really a good point. I still see
some confusion between online documentation, documentation source you
can build from master and the latest online documentation which is
often referenced on the mailing list. However I know that keeping all
the docs up-to-date and consistent is not an easy job.
Needs with respect to documentation do largely depend on the user's
perspective. For instance, if your goal is writing new recipes for
your own layers, you'll ask for a good variables reference and, maybe,
a reasonable checklist with best conventions for keeping metadata
consistent. This is also required if you want to contribute back with
high degree of confidence that your patches will be considered and
reviewed. If, on the other hand, your are more involved in kernel
configuration and customization, your hope is to keep your work as
much as possible integrated with the build system: this will grant you
a closer develop-deploy-test flow by using the same tools will be used
for production. Such a workflow does have documentation but I
personally believe
