As part of development workflow improvements. Source material available in this thread: https://lists.yoctoproject.org/pipermail/yocto/2014-June/020121.html
Hi, I checked out the thread and there are many suggestions that range from validation in general of what the original poster wanted to do up to well-documented methods that provide a pretty holistic solution. What I am wondering is for our YP doc section that would cover this what are the solutions and suggestions that we would want to recommend? Can someone suggest the best solution or combination of things that we would want to highlight in this section? There might even be other items that are not mentioned in the thread. Thanks, Scott
Assigned to person who should supply info.
(In reply to comment #2) > Assigned to person who should supply info. Heh, assigned to the wrong person, then :) I'm afraid I know nothing about this stuff. Paul Eggleton is probably the person who will end up working with Scott on this.
I set it to Paul.
So, I'm marking this as ACCEPTED rather than NEEDINFO since it is now assigned to me rather than Scott.
I have flagged similar problem where quick start documentation refers to branches with release names which will change on you. It seems that branch names are used to test poky, meta-intel (and other layers?) combinations. We need a tag(?) applied to a set of layers that are known to inter-operate at release. This seems like a release engineer task that is documented by a technical writer. Or am I missing the point?
Will create a tips and tricks article to address this. Last comment is not relevant to this bug is now addressed in bug 11731
No requests for this so moving to backlog. As we don't have a real backlog, setting to generic "2.4" milestone so it can be triaged appropriately.
Setting to NEEDINFO to trigger review.
Set to Undecided priority to trigger a re-triage.
Adding Kristi to the CC list so she gets information on this bug directly. Scott
What is going on with this bug? Are we addressing it in a tips and tricks wiki area? If so, this bug would not affect the YP docs. If not, knows this stuff? Joshua? Thanks, Scott
Hi Scott, this bug is on my list. I'm not sure if it makes sense to include this in the docs or not, the advantage of the docs over a tips and tricks article is that more people know where the docs are and to look for information there.
Hello Joshua, I talked with Scott and found out that there is a section in the 2.4 dev-manual that never got completed because he did not receive the info; http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#usingpoky-changes-collaborate This is where this type of info can go if we put it in the doc set. Since this bug is on your list and Scott agrees that it should go in the docs, I can update the section when we have the info. Thanks! Kristi
Please see the link in Comment 14 - we still need a review and a figure for typical system topology. Thanks!
Hi, As a temporary fix regarding the docs, I wrote this section to not use a figure. It would be nice to have something real-world though. Scott
Hi, This section needs reviewed. This is the section addressing how to set up a team environment for Yocto. Scott https://yoctoproject.org/docs/2.6/dev-manual/dev-manual.html#usingpoky-changes-collaborate
I took a look at the documentation, and it looks pretty good to me, with the caveat that I am looking at it from the build infrastructure side of things, as used with meta-intel. Be nice to have a developer perspective on it from someone who is using such an environment. That said, unless someone is looking for some very detailed, explicit instructions, my take is that this is good documentation. Just my two cents.
Scott, seems like this should maybe be assigned to you as King of Docs?
Awesome that someone actually reviewed this section... big +1 to the "King of Build Infrastructure" :) Thanks Tracy. I can take ownership of the bug. I will keep it in "IN PROGRESS REVIEW" in hopes of someone else looking at the section. Another idea is to throw it out on the Yocto mailing list and ask for feedback from the community. I will do that too. Scott
I read though the section linked in comment 14 as well. Other than the missing image, I didn't notice anything else that needs work. Add an image and ship it?
Who can give me a typical production environment layout?
Hi, Last call for a typical YP production layout topology that I can create into an image. I am asking for some rough idea of what to create an image with. I will even take a textual description of pieces and how they communicate. I will close this without the image if I cannot get this information with a month or so. Thanks, Scott
Is there anything left to do here? For example, we cover: Setting Up a Team Development Environment: https://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html#usingpoky-changes-collaborate Open Source License Compliance: https://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html#working-with-licenses Deployed (Production) On-target Package Management: https://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html#using-runtime-package-management Arichived Open Source Content (with archiver): https://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html#providing-the-source-code These all provide a pretty comprehensive picture of the tools we include for production. Also, there the WIC tool, which creates partitioned images for mass deployment. If there's nothing left to add, I'd like to mark this complete.
Some additional areas: - local source mirrors - strategies for handling the git cloned repos (use local branches and rebase vs bbappend ) There are likely other areas. Does anyone have additional requirements for this work?
A developer workflow for production should be mentioned: *) SDK for developer/bitbake for production build and Yocto/OE person *) devtool for developer/devtool for Yocto/OE person SW update solutions[1] should be mentioned for production, since people are reinventing all the time what's already there. The following can be used *) for "hardening" the production image *) to be able to see what meta-layers/branch/commit-id were used to build the image and whether something was modified without being checked in *) what packages are in the rootfs (without a package manager) - cve-check.bbclass - buildhistory.bbclass - image-buildinfo.bbclass - static code checks: https://github.com/priv-kweihmann/meta-sca - I use this[2] to write /etc/image-manifest (all packages) into my rootfs you can see here[3] how the output of image-buildinfo.bbclass and image-manifestinfo.bbclass looks like. Something like the oss-review toolkit[4] could be used to help with license compliance. I am not sure yet whether this should be outside of the YP or integrated with it. [1] https://wiki.yoctoproject.org/wiki/System_Update [2] https://gitlab.com/meta-layers/meta-resy/-/blob/dunfell/classes/image-manifestinfo.bbclass [3] https://hub.docker.com/r/yoctotrainer/app-container-tensorflow-oci [4] https://github.com/tsteenbe/ort
Created attachment 4793 [details] feeplane mindmap 2021-04-27 freeplane mindmap
Hi, Just added a freeplane[1] mindmap with some more ideas. In case you want to modify it, you will need to install freeplane. In case you just want to watch it, either look at the .svg or for some more interactive/clickable version the html. [1] https://www.freeplane.org/wiki/index.php/Home
This bug contains too much history, making it time consuming to get back to it. I'm closing it after creating a new one with just the relevant ideas that remain: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14482 *** This bug has been marked as a duplicate of bug 14482 ***