How to become part of our Yocto Project® community

-
Joining the community is the best way to learn about the Yocto Project®, report bugs, stay up to date on the latest features, and learn from the excellent developers and testers within the Yocto Project®.




The Yocto Project® for mere m0rtals
How to become part of our Yocto Project® community
Robert Berger - Reliable Embedded Systems e.U
Consulting Training Engineering

©2018 by Robert Berger cc-by-sa
CC-Licence: http://creativecommons.org/licenses/by-sa/4.0/

First steps

If you did not already try something like this I suggest to get your hands dirty and go through the ”QuickStart Guide”. You might also want to browse ”What I Wish I’d Known”. Now you might have some more questions how to do certain things.

How to get in touch

The Yocto Project® is a very friendly community, with maintainers, ambassadors, and other community members ready to help. There are several ways to get in touch with the project - see here.

Mailing Lists & IRC

For community projects it’s quite usual to communicate via mailing lists and IRC. Get yourself a new e-mail address, maybe one for each mailing list you want to join, not to clutter your main e-mail address with potentially huge traffic coming in from your new lists. I’d recommend to start with the ”Yocto mailing list” for general questions and discussions. In order to send patches upstream (we’ll come to that later) use the ”Yocto mailing list” or OE mailing lists as appropriate. If you want some (compared to mailing lists) more immediate answers you might want to have a look at #yocto, #poky and #oe channels on freenode. Some people respond more helpful on the one than the other. (IRC Logs are available as well.)

Monthly Technical Call

The Yocto Project® hosts a technical call on the first Tuesday of each month. All community members are invited to join on both the call and in the IRC channel, which are used simultaneously. Join at 15:00 GMT. In the US, this is 11am ET , 10am CT, 9am MT, and 8am PT.

Community Guidelines

The Community Guidelines should give you some direction how to participate.

Contact Us

For technical questions you might first want to check out the Yocto Project® Wiki and the Documentation. I would recommend to browse the ”Yocto Project® Mega-Manual” and the ”BitBake User Manual”. I usually read the latest versions of these manuals every summer in my holidays - please don’t judge me. If, after reading the manuals, your questions are still not answered, ask on mailing lists and IRC. In case you found a bug feel free to send a patch for it on the relevant mailing list or post your findings to the "Yocto Project® Bugzilla" bug tracking system following the Bugzilla Guidelines For everything else contact us here.

Participate

Open source projects are built around participation. This is where you can access repositories, file a bug, read information on the wiki, or see the results of nightly builds.

Source Repositories

Various Source Repositories including ”Poky”, ”Poky Support”, ”Yocto Metadata Layers”, ”Yocto Tools”, ”IDE Plugins”, ”Matchbox”, ”Misc”, ”Sato”, ”User Contributions”, ”Yocto Linux Kernel”, ”Yocto Metadata Layer Archive” and ”Yocto Tools Archive” can be found here. If you need even more recipes check the ”OpenEmbedded Layer Index”.

Bugzilla

Unlike closed source projects we are happy about you reporting errors. We’ll have a look into each and every issue and try to resolve it. We might need your help to be able to reproduce the error. Please monitor e-mails to cases you reported or where you added your e-mail coming from the Yocto Project ”Bugzilla” error tracking system. Create an account here, follow the ”Bugzilla Guidelines” and post! Starting from the ”Releases” wiki page ”bugs” and their status can be tracked:

Wiki

We already saw before the ”Yocto Wiki”. Have a look at ”Technical FAQ”, ”TipsAndTricks” and ”Working Behind a Network Proxy” in case you need something like that.

Autobuilder

The ”Yocto Project® Autobuilder” is a project to automate build tests and Quality Assurance. One of the most neglected areas of open source development is testing and Quality Assurance. A goal of the Yocto Project® is to lead the industry in being the first open source project that targets embedded developers who
  • publish their QA and testing plans
  • demonstrate their testing and QA in public
  • and develop tools to automate test and QA procedures for the benefit of everyone

Contribute 

Thousands of people contribute to the Yocto Project® to make it a success. This is how you can contribute your own code or find other ways to contribute - see here.

Contribution Guidelines

Check out the ”Commit Patch Message Guidelines”.

Submit a Patch

Submit a Job Posting

We’d be happy to link to your job listing here.

Join the Project

To learn more about how to join [45] the Yocto Project, please contact the Linux Foundation directly [46].

Social media

Have a look at ”Stack Overflow”, ”Facebook”, ”Linkedin”, ”Twitter”, (shameless self promotion follows) ”Twitter - Yocto Training”, ”Blogspot”.

Events

We are living in a world where we work remotely and communicate on IRC, mailing lists and video chats, but it’s still important to meet from time to time in person. Meet many great people from our community at those events. Keep in mind that usually there is a ”Yocto Project Developer Day” right after the ELC(E).

Author

Since 1993, Robert Berger gathered practical and managerial experience in software design and development for embedded systems with and without hard real-time requirements. Since the beginning of the 21st century, he has used GNU/Linux on desktop and server class machines, but mainly for embedded practices (automotive, industrial control, robotics, telecoms, consumer electronics, etc.). Robert regularly attends international events such as ”Embedded World”, ”Embedded Software Engineering Congress”, ”Embedded Systems Conference”, and ”Embedded Linux Conference” as an expert and lecturer. His specialty is mainly training, but also consulting (in German or English) worldwide. Robert’s expertise ranges from the smallest real-time systems (FreeRTOS) to set-ups with multiple processors/cores and embedded GNU/Linux (user-, kernel-space, device drivers, hardware interfacing, debugging, multi-core, Yocto Project) with a focus on free and open source software. Robert is a globe-trotter. He is CEO & Embedded Software Specialist at Reliable Embedded Systems - Robert Berger e.U. which is based in St. Barbara, Austria, and when not traveling, lives with his family in Athens, Greece.

For comments/inquiries and suggestions
you can contact Robert here:
robert.berger@ReliableEmbeddedSystems.com




Comments

Post a Comment

Popular posts from this blog

Yocto: BitBake and Dependencies - e.g. One recipe to use output of another recipe

-
Image
It feels weird to help some get their working build to fail and then for them to be happy about it... (RP) Introduction This work is sponsored by Reliable Embedded Systems . You can find more information about our training/consulting services here . Objectives The goal of this blog post is to look into BitBake dependencies. As an example let's take recipe A ( u-boot-phytex-imx ) which needs the output of recipe B ( firmware-imx-8m ) for a successful compilation. (Please don't ask why.) To be more precise here is an excerpt of recipe A ( u-boot-phytex-imx ): # --> this funny u-boot from Phytec needs the ddr_firmware binaries in ${S} # Note: here we copy deployed stuff from another recipe # to the source dir of this recipe! # # DEPENDS deals with build-time depenencies # Read my blog post to find out why DEPENDS does not work here # # DEPENDS += " \ # firmware-imx-8m \ # " # RDEPENDS is wrong anyhow for what I want
Read more

Yocto: kernel modules not showing up in the rootfs

-
Image
Introduction This work is sponsored by Reliable Embedded Systems . You can find more information about our training/consulting services here . Objectives The goal of this blog post is to point out a well known and documented issue with kernel modules not ending up on the root file system which is likely overseen by people until they stumble over it.   Kernel module(s) So you created a brand new kernel module, or you just wanted to include all the kernel modules in the root file system, or just one of them. You reach out to the community mailing list or chat with something like this: I have MACHINE_EXTRA_RRECOMMENDS + = "kernel-modules" in my machine configuration. When I look into the rootfs I see no modules installed in /lib/modules/ $( uname -r ) . I get only a modules tarball in the deploy directory. I also tried MACHINE_EXTRA_RDEPENDS + = "kernel-modules" and it still does not work. What am I doing wrong? Check the Mega Manual If things d
Read more

Yocto/Qt5: hello-qt part2 - Licensing

-
Image
Introduction This work is sponsored by Reliable Embedded Systems . You can find more information about our training/consulting services here . Objectives The goal of this blog post is to show my journey trying to build a hello-qt application and reasons why I don't like Qt . As far as I can tell this is going to be a multi part blog post. You might want to have a look at part one as well. Disclaimer: I am not a lawyer, so I can not give legal advice. GPL and LGPL licenses LGPL v2.x Typically libraries are licensed with this license You need to provide the source code (including modifications) and instructions on how to build the LGPL v2.1 licensed code In case your application links statically against LGPL licensed code you need to provide the object files of your applications to be able to replace the LGPL'ed code with different versions In case your application links dynamically against LGPL licensed code you can replace the LGPL'ed libraries without the objec
Read more