Location and Time
Co-located with the Yocto Project Summit held on May 25-26, 2021.
The Developers Meeting is scheduled for May 25th between 15:30 and 20:00 UTC. The exact times for each individual topic are TBD.
As always, we will collect topics on the wiki at https://www.openembedded.org/OEDVM_2021.
For the actual developer meeting, there will be pre-assigned timeslots for each topic. The moderator(s) have the option of opening with a short introduction/presentation to introduce the topic.
- Insight into the life of a Maintainer
- Moderator(s): Armpit
- The good, bad and ugly of Maintaining Poky, meta-openembedded, meta-security and a BSP.
- Moderator(s): Armpit
- BSPs: best practice exemplars, cross-project issue tracker, linters, incentive loop design
- OE Resourcing: gaps, role naming, work metadata, bridging OSS/commercial
- X11 is dead; long live X11! what's to become of core-image-sato?
- Moderator(s): Trevor Woerner, Alexander Kanavin, Joshua Watt, Ross Burton
- the Yocto Project provides a sample distribution (poky) and images (core-image-minimal, core-image-base, core-image-full-cmdline…) to give users examples to follow and provide a basis for testing purposes
- core-image-sato was created to fill the GUI niche as an example and for testing
- core-image-sato is based on gtk+ 3.x and x11
- both gtk+ 3 and x11 are EOL/unmaintained
- do we need a GUI image going forward (as an example, for testing purposes)?
- how much testing does core-image-sato receive?
- how many teams have based their work on core-image-sato?
- if a GUI image is still needed, upon which toolkit and compositor should it be based?
- what's to become of core-image-sato?
- what's to become of x11 support in oecore?
- SBOM (Software Bill of Materials)
- Moderator(s): Trevor Woerner, Armin Kuster, Mikko Murto (meta-doubleopen)
- the requirement to provide a software bill of materials when delivering software to a customer/user is becoming more and more common
- e.g. a recent Executive Order in the United States requires an SBOM for security reasons
- as a project that creates images from sources, YP/OE is perfectly positioned to generate SBOMs for its artifacts
- we already generate similar information for software licence compliance via SPDX
- meta-doubleopen seems to be moving in this direction
- what information is required for an SBOM, what are the requirements to create a legally compliant SBOM?
- SPDX seems to be the best format for us to use, any objections?
- in our builds when/where do we generate the SBOM? do_package/do_packagedata? archiver/do_populate_lic?
- we already generate various manifests (e.g. buildhistory) should we replace this information with proper SBOMs?
- Improving Layer quality: Layerindex combined with a layerchecker
- Moderator(s): Jan-Simon Möller (firstname.lastname@example.org)