OEDVM 2021

==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 found below in the schedule.
==Format==
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.
==Topic Ideas==
* BSPs: best practice exemplars, cross-project issue tracker, linters, incentive loop design
** Moderator(s): Rich Persaud, Philip Balister
* Insight into the life of a Maintainer
** Moderator(s): Armin Kuster
*** The good, bad and ugly of Maintaining Poky, meta-openembedded, meta-security and a BSP.
* X11 is dead; long live X11! what's to become of core-image-sato?
** Moderator(s): Trevor Woerner, Alexander Kanavin, Joshua Watt, Ross Burton
** Premise:
*** 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
** Discussion:
*** 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)
** Premise:
*** 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
** Discussion:
*** 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?
* LTS (Long Term Support)
** Moderator(s): Trevor Woerner, Armin Kuster, Khem Raj
** Premise:
*** for the first time ever, the Yocto Project experimented with having an LTS as well as its regular releases
** Discussion:
*** did anyone notice?
*** did anyone use it?
*** what did people like about it?
*** what could be changed?
*** should we do it again?
*** what repercussions are there for the larger YP/OE community (layer maintainers)?
*** is 2 years too much? not enough? just right?
* Improving Layer quality: Layerindex combined with a layerchecker
** Moderator(s): Jan-Simon Möller (dl9pf@gmx.de)
** Premise:
*** Layers need to interop well. There is work to do. Let's chop some wood!
** Discussion:
*** Overview on the current state
*** Your own pain points ?
*** The good and the bad examples ?!
*** How can we improve collectively ?
*** How can we support that process ?
* Project Documentation
** Moderator(s): Michael Opdenacker, Nicolas Dechesne
** Premise:
*** the Yocto Project takes documentation very seriously and strives to have relevant, up-to-date documentation available for all users
*** feedback about the current state of the documentation
*** ongoing work
*** guidelines for contributing
** Discussion:
*** what's missing?
*** what should be fixed?
*** what's obsolete?
* Automation of CVE Verification
** Moderators: David Reyna, Shachar Menashe
** Premise:
*** Propose Sharing CVE information via Layer Index to assist automation
*** CVE checking by package version does not capture OE patches, so false positives
*** CVE management is expensive, automation makes it feasible, data must be programmatically available
** Discussion:
*** Proposal to contribute to the Layer Index to share CVE information
*** Proposal to validate this for internal tools (CVE Checker, SRTool)
*** Proposal to validate this for external tools (VDoo, ...)
*** Open discussion in ways to help CVE management
==Schedule==
All times are in UTC.
* 1530 - 1555: CVE
* 1555 - 1615: BSOM
* 1615 - 1640: Documentation
* 1650 - 1720: X11/sato
* 1730 - 1800: Layer Quality
* 1810 - 1840: BSP
* 1850 - 1920: Maintainer's Life
* 1930 - 2000: LTS
Category:OEDEM