Difference between revisions of "OEDVM 2021"

From Openembedded.org
Jump to: navigation, search
(→‎Schedule)
 
(25 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.
  
−
Running a virtual developer meeting presents a new set of challenges and
+
For the actual developer meeting, there will be pre-assigned timeslots for
−
a chance to engage a larger audience. As always, we will collect topics on
+
each topic. The moderator(s) have the option of opening with 
−
the wiki at https://www.openembedded.org/OEDVM_2021. For each topic, we expect at
+
a short introduction/presentation to introduce the topic.
−
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
+
==Topic Ideas==
−
prerecord 10-15 minutes opening statement describing the topic and current
+
* BSPs: best practice exemplars, cross-project issue tracker, linters, incentive loop design
−
state of solutions. These will be posted to the OpenEmbedded youtube channel
+
** Moderator(s): Rich Persaud, Philip Balister
−
so people can view them at a convenient time. We would like to collect
 
−
feedback as youtube comments (???) (maybe wiki?) We do not expect perfect
 
−
videos, this can be done by recording a zoom meeting of the moderators.
 
−
The idea is reach the global community across all time zones and allow
 
−
them to provide asynchronous input without losing sleep. The remaining 45
 
−
minutes are for reviewing comments and further discussion.
 
  
−
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
+
* Insight into the life of a Maintainer
−
doing something else if the online discussions warrants a change. The
+
** Moderator(s): Armin Kuster
−
moderators should summarize the online comments and then moderate a
+
*** The good, bad and ugly of Maintaining Poky, meta-openembedded, meta-security and a BSP.
−
discussion with the online live audience. We hope that by presenting
 
−
the topic early, people have a chance to think out concrete solutions
 
−
for discussion.
 
  
−
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.
+
* X11 is dead; long live X11! what's to become of core-image-sato?
−
If we have more topics with moderators than we can schedule, we will identify the selected topics before
+
** Moderator(s): Trevor Woerner, Alexander Kanavin, Joshua Watt, Ross Burton
−
moderators start preparing the topic introduction material.
+
** 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?
  
−
==Topic Ideas==
+
<br>
−
* Insight into the life of a Maintainer
+
* SBOM (Software Bill of Materials)
−
* BSPs: best practice exemplars, cross-project issue tracker, linters, incentive loop design
+
** Moderator(s): Trevor Woerner, Armin Kuster, Mikko Murto (meta-doubleopen)
−
* OE Resourcing: gaps, role naming, work metadata, bridging OSS/commercial
+
** Premise:
−
* X11 is dead; long live X11! what's to become of core-image-sato?
+
*** 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: 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
  
−
==FAQ==
+
==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/index.php?title=OEDVM_2021&oldid=10854"