OEDVM 2021: Difference between revisions

From Openembedded.org
Jump to navigation Jump to search
No edit summary
 
(26 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==Location and Time==
==Location and Time==


Co-located with the [https://pretalx.com/yocto-project-summit-2021/ Yocto Project Summit ] held on May 25-26, 2021. Exact times are TBD.  
Co-located with the [https://pretalx.com/yocto-project-summit-2021/ 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==
==Format==


Since this will be a virtual meeting we are going to change the format around to try and make it easier to get input from the global community and still maintain an in person portion.
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.


Running a virtual developer meeting presents a new set of challenges and
==Topic Ideas==
a chance to engage a larger audience. As always, we will collect topics on
* BSPs: best practice exemplars, cross-project issue tracker, linters, incentive loop design
the wiki at https://www.openembedded.org/OEDVM_2021. For each topic, we expect at
** Moderator(s): Rich Persaud, Philip Balister
least three people to agree to be moderators for the discussion. About two
weeks before the meeting (early May), the OpenEmbedded board and technical
steering committee will select 6 topics for discussion.


To increase global participation, we strongly encourage moderators to
<br>
prerecord 10-15 minutes opening statement describing the topic and current
* Insight into the life of a Maintainer
state of solutions. These will be posted to the OpenEmbedded youtube channel
** Moderator(s): Armin Kuster
so people can view them at a convenient time. We would like to collect
*** The good, bad and ugly of Maintaining Poky, meta-openembedded, meta-security and a BSP.
feedback as youtube comments (???) (maybe wiki?) We do not expect perfect
 
videos, this can be done by recording a zoom meeting of the moderators.
<br>
The idea is reach the global community across all time zones and allow
* X11 is dead; long live X11! what's to become of core-image-sato?
them to provide asynchronous input without losing sleep. The remaining 45
** Moderator(s): Trevor Woerner, Alexander Kanavin, Joshua Watt, Ross Burton
minutes are for reviewing comments and further discussion.
** 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?


For the actual developer meeting, there will be six one hour timeslots for
<br>
each topic. The moderators have the option of opening with the video or
* SBOM (Software Bill of Materials)
doing something else if the online discussions warrants a change. The
** Moderator(s): Trevor Woerner, Armin Kuster, Mikko Murto (meta-doubleopen)
moderators should summarize the online comments and then moderate a  
** Premise:
discussion with the online live audience. We hope that by presenting
*** the requirement to provide a software bill of materials when delivering software to a customer/user is becoming more and more common
the topic early, people have a chance to think out concrete solutions
*** e.g. a recent Executive Order in the United States requires an SBOM for security reasons
for discussion.
*** 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?


The topics discussed during the live meeting will be selected from the topics with the strongest
<br>
topic moderator support. For example, a topic that no one is willing to moderate will not be selected.
* LTS (Long Term Support)
If we have more topics with moderators than we can schedule, we will identify the selected topics before
** Moderator(s): Trevor Woerner, Armin Kuster, Khem Raj
moderators start preparing the topic introduction material.
** 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?


==Topic Ideas==
<br>
* Insight into the life of a Maintainer
* 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?
* Improving Layer quality: Layerindex combined with a layerchecker
* Improving Layer quality: Layerindex combined with a layerchecker
  * Moderator: Jan-Simon Möller (dl9pf@gmx.de)
** Moderator(s): Jan-Simon Möller (dl9pf@gmx.de)
==FAQ==
** 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.


The format is new, we will try and add clarifications here.


# Do I need to be present at the live meeting to moderate a topic? No, just make sure the topic has one or two people for the live session.
* 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.


  • 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
Retrieved from "https://www.openembedded.org/w/index.php?title=OEDVM_2021&oldid=10854"