Difference between revisions of "OEDVM 2021"
From Openembedded.org
(→Topic Ideas: add BSOM topic) |
(→Schedule) |
||
(16 intermediate revisions by 3 users not shown) | |||
Line 4: | Line 4: | ||
The Developers Meeting is scheduled for May 25th between 15:30 and 20:00 UTC. | The Developers Meeting is scheduled for May 25th between 15:30 and 20:00 UTC. | ||
− | The exact times for each individual topic are | + | The exact times for each individual topic are found below in the schedule. |
==Format== | ==Format== | ||
Line 16: | Line 16: | ||
==Topic Ideas== | ==Topic Ideas== | ||
+ | * BSPs: best practice exemplars, cross-project issue tracker, linters, incentive loop design | ||
+ | ** Moderator(s): Rich Persaud, Philip Balister | ||
+ | |||
+ | <br> | ||
* Insight into the life of a Maintainer | * Insight into the life of a Maintainer | ||
− | + | ** Moderator(s): Armin Kuster | |
− | ** Moderator(s): | + | *** The good, bad and ugly of Maintaining Poky, meta-openembedded, meta-security and a BSP. |
− | * | ||
− | |||
+ | <br> | ||
* X11 is dead; long live X11! what's to become of core-image-sato? | * X11 is dead; long live X11! what's to become of core-image-sato? | ||
− | ** Moderator(s): Trevor Woerner | + | ** Moderator(s): Trevor Woerner, Alexander Kanavin, Joshua Watt, Ross Burton |
** Premise: | ** 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 | *** 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 | ||
Line 37: | Line 40: | ||
*** what's to become of x11 support in oecore? | *** what's to become of x11 support in oecore? | ||
− | * | + | <br> |
− | ** Moderator(s): Trevor Woerner | + | * 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? | ||
+ | |||
+ | <br> | ||
+ | * 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? | ||
+ | <br> | ||
* Improving Layer quality: Layerindex combined with a layerchecker | * Improving Layer quality: Layerindex combined with a layerchecker | ||
** Moderator(s): Jan-Simon Möller (dl9pf@gmx.de) | ** 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 ? | ||
+ | |||
+ | <br> | ||
+ | * 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? | ||
+ | |||
+ | <br> | ||
+ | * 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]] | [[Category:OEDEM]] |
Latest revision as of 15:51, 25 May 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.
- Moderator(s): Armin Kuster
- 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