Openembedded.org - User contributions [en]

OEDVM 2022 05

2022-05-20T13:59:07Z

Twoerner: /* Topic Ideas */

==Location and Time==

Held after the [https://pretalx.com/yocto-project-summit-2022-05/ Yocto Project Summit ], The OE Developers Meeting is scheduled for Friday, 20 May 2022 between 12:00 and 20:00 UTC. Exact times for each individual topic are found below in the schedule.

The meeting is held on Zoom https://zoom.us/j/99151508871 (Meeting ID: 991 5150 8871). We thank [//www.automotivelinux.org/ Automotive Grade Linux] for providing!

==Format==

As always, we will collect topics on the wiki at
https://wiki.openembedded.org/OEDVM_2022_05.

For the actual developer meeting, there will be pre-assigned timeslots for each topic. The moderator(s) will open with a short introduction/presentation to introduce the topic.

==Topic Ideas==

These are topics that were suggested for previous OE developer meetings and have not been covered yet. They should be seen as starting ideas on things that can be discussed.

Actual schedule
::{|
! Topic
! Moderator(s)
! Time in UTC (Start is 1200 UTC/0800 EDT)
! Notes
|-
| Introduction
| OE Board
| 1200
|-
| Future of eSDK (inc. bblock/bbunlock commands)
| Richard Purdie
| 1215
| https://lists.openembedded.org/g/openembedded-architecture/topic/thoughts_on_the_esdk/90990557
|-
| Copyright in OE-Core files
| Richard Purdie
| 1300
| https://lists.openembedded.org/g/openembedded-architecture/topic/oe_core_copyright_notices/91159593
|-
| layer.conf changes
| Richard Purdie
| 1330
|-
| Kernel config RFC
| Trevor Woerner
| 1400
| https://docs.google.com/presentation/d/1EC6W_MH6OJ3uMxH2uWA1OWsxYlEVZAoT3z91g6SULqk/edit?usp=sharing
|-

| Layer Setup Configuration
| Joshua Watt
| 1430
|-

| Bitbake & OE "Core improvements"
| Joshua Watt
| 1500
|-

| Multiple SBOM formats, both in and out
| Peter Kjellerstedt
| 1530
|-

| Layerindex: quality, tooling, enhancements
| Jan-Simon Möller, Tim Orling
| 1550
|-

| Airing of Grievances
| OpenEmbedded Board
| 1610 (After all other topics covered)
|-

|}

List of grievances
* How do we increase people working on underlying system?

Unassigned ideas for next time
::{|
! Topic
! Moderator(s)
! Estimate of time
! Notes
|-

| Data store operation changes
| ?
| ?
|-

| Syntax removal
| ?
| ?
|-

| Data store internal rewrite
| ?
| ?
|-

| f-string in Python code (and more modern python in general)
| Ross Burton, Tim Orling
| ?
|-

| Merging optional functionality to make it mandatory
| ?
| ?
|-

| Dropping core features
| ?
| ?
|-

| Security (PSiRT)
| ?
| ?
|-

| QA Automation
| ?
| ?
|-

| Code submission process
| ?
| ?
|-

| Software updates
| Bruce Ashfield
| ?
|-

| AI/ML
| ?
| ?
|-
|}

Here are some new topic ideas:

::{|
! Topic
! Moderator(s)
! Estimate of time
|-

|}

==Notes==
===Social===
Meet up @ ELC?

==Minutes==

https://docs.google.com/document/d/12rtiKrLgtZl617I5aew0g-N3ZoIyJts3r-FKP2AGRgQ/edit?usp=sharing

OEDVM 2022 05

2022-05-05T15:48:17Z

Twoerner: /* Topic Ideas */

OEDVM 2022 05

2022-05-05T13:50:18Z

Twoerner: indent the tables to offset them from the text

Documentation

2022-05-05T13:36:23Z

Twoerner: /* Other */ change wording away from "dummy"; ignorance does not imply a lack of intelligence

Documentation that relates to OpenEmbedded.

== Yocto Project Manuals ==

The most up-to-date manuals relating to OpenEmbedded (in particular, the new [[OpenEmbedded-Core]]) is the Yocto Project documentation, in particular the Quick Start Guide, Development Manual and Reference Manual.

See '''[https://docs.yoctoproject.org/]''' for links to all the manuals.

== Solutions for common problems ==

* Set [[PREFERRED_PROVIDER for jpeg and jpeg-native]]

== Bitbake Manual ==

[https://docs.yoctoproject.org/bitbake/index.html Bitbake Manual]

== Other ==

Guides and HowTos:
* [https://bootlin.com/doc/training/yocto/ Bootlin's freely available Yocto Project and OpenEmbedded training materials]
* [http://bec-systems.com/site/456/capture-oe-source-changes How to Capture OE Source Code Changes to a Package]
* [[How to submit a patch to OpenEmbedded]]
* [[List of Executable tasks]] Usage: bitbake -c <task>

[[Category:User]]
[[Category:Dev]]

OEDVM 2022 05

2022-05-05T13:31:35Z

Twoerner: /* Topic Ideas */ make a separate table to separate old from new ideas

OEDVM 2022 05

2022-05-05T13:28:46Z

Twoerner: /* Topic Ideas */

OEDVM 2021

2021-05-25T11:11:32Z

Twoerner: /* Schedule */ added CVE to schedule

==Location and Time==

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==

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: BSP
* 1555 - 1615: CVE
* 1615 - 1640: BSOM
* 1650 - 1720: Documentation
* 1730 - 1800: X11/sato
* 1810 - 1840: Layer Quality
* 1850 - 1920: Maintainer's Life
* 1930 - 2000: LTS

[[Category:OEDEM]]

OEDVM 2021

2021-05-25T11:08:51Z

Twoerner: /* Topic Ideas */ add CVE topic

==Location and Time==

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==

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 - 1600: BSP
* 1610 - 1640: BSOM
* 1650 - 1720: Documentation
* 1730 - 1800: X11/sato
* 1810 - 1840: Layer Quality
* 1850 - 1920: Maintainer's Life
* 1930 - 2000: LTS

[[Category:OEDEM]]

OEDVM 2021

2021-05-24T19:07:56Z

Twoerner: /* Schedule */ Add schedule

==Location and Time==

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==

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)

 
* 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?

==Schedule==
All times are in UTC.

* 1530 - 1600: BSP
* 1610 - 1640: BSOM
* 1650 - 1720: Documentation
* 1730 - 1800: X11/sato
* 1810 - 1840: Layer Quality
* 1850 - 1920: Maintainer's Life
* 1930 - 2000: LTS

[[Category:OEDEM]]

OEDVM 2021

2021-05-24T18:54:03Z

Twoerner: /* Topic Ideas */ switch to Armin's name from his irc handle

==Location and Time==

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==

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)

 
* 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?

==Schedule==
The order of go is still being put together.
Please check back later.

[[Category:OEDEM]]

OEDVM 2021

2021-05-24T15:56:48Z

Twoerner: /* Topic Ideas */ add back BSP topic

==Location and Time==

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==

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): Armpit
*** 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)

 
* 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?

==Schedule==
The order of go is still being put together.
Please check back later.

[[Category:OEDEM]]

OEDVM 2021

2021-05-24T12:52:24Z

Twoerner:

==Location and Time==

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==

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==
* 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.

 
* 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)

 
* 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?

==Schedule==
The order of go is still being put together.
Please check back later.

[[Category:OEDEM]]

OEDVM 2021

2021-05-23T23:15:59Z

Twoerner: /* Topic Ideas */ add Nico as a moderator for the documentation discussion

==Location and Time==

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 TBD.

==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==
* 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.

 
* 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)

 
* 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?

[[Category:OEDEM]]

OEDVM 2021

2021-05-22T11:20:11Z

Twoerner: /* Topic Ideas */ remove topics with no moderators/ideas

==Location and Time==

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 TBD.

==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==
* 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.

 
* 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)

 
* Project Documentation
** Moderator(s): Michael Opdenacker
** 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?

[[Category:OEDEM]]

OEDVM 2021

2021-05-21T17:10:47Z

Twoerner: /* Topic Ideas */ add documentation proposal from MichaelO

==Location and Time==

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 TBD.

==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==
* 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.

 
* BSPs: best practice exemplars, cross-project issue tracker, linters, incentive loop design
** Moderator(s):

 
* OE Resourcing: gaps, role naming, work metadata, bridging OSS/commercial
** Moderator(s):

 
* 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)

 
* Project Documentation
** Moderator(s): Michael Opdenacker
** 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?

[[Category:OEDEM]]

OEDVM 2021

2021-05-20T17:21:40Z

Twoerner: /* Topic Ideas */ add LTS topic, update formatting

==Location and Time==

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 TBD.

==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==
* 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.

 
* BSPs: best practice exemplars, cross-project issue tracker, linters, incentive loop design
** Moderator(s):

 
* OE Resourcing: gaps, role naming, work metadata, bridging OSS/commercial
** Moderator(s):

 
* 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)

[[Category:OEDEM]]

OEDVM 2021

2021-05-20T13:48:52Z

Twoerner: /* Topic Ideas */ add Mikko to SBOM conversation

OEDVM 2021

2021-05-19T14:10:50Z

Twoerner:

OEDVM 2021

2021-05-19T13:41:17Z

Twoerner: /* Topic Ideas */

OEDVM 2021

2021-05-19T13:24:30Z

Twoerner: /* Topic Ideas */ add SBOM topic

OEDVM 2021

2021-05-19T12:56:01Z

Twoerner: /* Topic Ideas */ add BSOM topic

OEDVM 2021

2021-05-19T12:52:10Z

Twoerner: /* Format */

OEDVM 2021

2021-05-19T12:51:50Z

Twoerner: /* Format */ remove onerous requirements which are blocking people from participating

OEDVM 2021

2021-05-14T17:42:04Z

Twoerner: /* Topic Ideas */ add premise and discussion items for the x11 topic

==Location and Time==

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 TBD.

==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.

Running a virtual developer meeting presents a new set of challenges and
a chance to engage a larger audience. As always, we will collect topics on
the wiki at https://www.openembedded.org/OEDVM_2021. For each topic, we expect at
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
prerecord 10-15 minutes opening statement describing the topic and current
state of solutions. These will be posted to the OpenEmbedded youtube channel
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
each topic. The moderators have the option of opening with the video or
doing something else if the online discussions warrants a change. The
moderators should summarize the online comments and then moderate a
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
topic moderator support. For example, a topic that no one is willing to moderate will not be selected.
If we have more topics with moderators than we can schedule, we will identify the selected topics before
moderators start preparing the topic introduction material.

==Topic Ideas==
* Insight into the life of a Maintainer
** Moderator(s):
* BSPs: best practice exemplars, cross-project issue tracker, linters, incentive loop design
** Moderator(s):
* OE Resourcing: gaps, role naming, work metadata, bridging OSS/commercial
** Moderator(s):

* X11 is dead; long live X11! what's to become of core-image-sato?
** Moderator(s): Trevor Woerner
** 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?

* Improving Layer quality: Layerindex combined with a layerchecker
** Moderator(s): Jan-Simon Möller (dl9pf@gmx.de)

==FAQ==

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.

[[Category:OEDEM]]

OEDVM 2021

2021-05-13T15:56:16Z

Twoerner: /* Location and Time */ Updated to indicate the block of time set aside for the meeting.

OEDVM 2021

2021-05-13T15:53:32Z

Twoerner: /* Topic Ideas */ added myself as moderator for x11 discussion

==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.

==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.

Running a virtual developer meeting presents a new set of challenges and
a chance to engage a larger audience. As always, we will collect topics on
the wiki at https://www.openembedded.org/OEDVM_2021. For each topic, we expect at
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
prerecord 10-15 minutes opening statement describing the topic and current
state of solutions. These will be posted to the OpenEmbedded youtube channel
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
each topic. The moderators have the option of opening with the video or
doing something else if the online discussions warrants a change. The
moderators should summarize the online comments and then moderate a
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
topic moderator support. For example, a topic that no one is willing to moderate will not be selected.
If we have more topics with moderators than we can schedule, we will identify the selected topics before
moderators start preparing the topic introduction material.

==Topic Ideas==
* Insight into the life of a Maintainer
** Moderator(s):
* BSPs: best practice exemplars, cross-project issue tracker, linters, incentive loop design
** Moderator(s):
* OE Resourcing: gaps, role naming, work metadata, bridging OSS/commercial
** Moderator(s):
* X11 is dead; long live X11! what's to become of core-image-sato?
** Moderator(s): Trevor Woerner
* Improving Layer quality: Layerindex combined with a layerchecker
** Moderator(s): Jan-Simon Möller (dl9pf@gmx.de)

==FAQ==

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.

[[Category:OEDEM]]

OEDVM 2021

2021-05-06T03:52:24Z

Twoerner: /* Topic Ideas */ add x11/sato idea

==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.

==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.

Running a virtual developer meeting presents a new set of challenges and
a chance to engage a larger audience. As always, we will collect topics on
the wiki at https://www.openembedded.org/OEDVM_2021. For each topic, we expect at
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
prerecord 10-15 minutes opening statement describing the topic and current
state of solutions. These will be posted to the OpenEmbedded youtube channel
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
each topic. The moderators have the option of opening with the video or
doing something else if the online discussions warrants a change. The
moderators should summarize the online comments and then moderate a
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
topic moderator support. For example, a topic that no one is willing to moderate will not be selected.
If we have more topics with moderators than we can schedule, we will identify the selected topics before
moderators start preparing the topic introduction material.

==Topic Ideas==
* 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?

==FAQ==

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.

[[Category:OEDEM]]

OEDEM 2018

2018-09-06T15:37:49Z

Twoerner: add Beth

== Location and Time ==

Sunday, 21 October 2018 (before ELCE [October 22-24]) 

Expectation is to finish by 1800

Hilton Edinburgh Grosvenor
5-21 Grosvenor Street
EH12 5EF Edinburgh

SAT-NAV: EH12 5EF

5 minute walk to Haymarket Train Station

No onsite car park. Ask Crofton if you need local parking information.

== Logistics ==

Yes, we know it is Sunday. Best we could do this year.

Attendance is capped at 40. Armin is the bouncer.

== Remote conference link ==

== Planning to Attend ==

# Khem Raj (khem)
# Armpit (Akuster)
# Philip Balister (Crofton)
# Denys Dmytriyenko (denix)
# Marco Cavallini (mckoan)
# Jan Lübbe (shoragan)
# Peter Kjellerstedt (Saur)
# Jeff Osier-Mixon (Jefro)
# Scott Murray (smurray)
# Ruslan Bilovol
# Phil Blundell
# Ross Burton (rburton)
# Richard Purdie (RP)
# Richard Leitner
# Jan-Simon Möller (dl9pf)
# Koen Kooi
# Robert Berger (will join in afternoon approx. 14:00?)
# Ulrich Ölmann (OnkelUlla)
# Trevor Woerner (tlwoerner)
# Matt Porter (mdp)
# Nicolas Dechesne (ndec)
# Grygorii Tertychnyi
# Behan Webster (behanw)
# Phil Wise (cajun-rat)
# Martin Hundebøll (hundeboll)
# Tim Orling (moto-timo)
# Bill Mills
# Kate Stewart
# Jeff Morrison
# Alan Wang
# Andrea Galbusera (gizero)
# Ricardo Salveti (rsalveti)
# Christopher Clark (xtopher)
# Rich Persaud
# Michael Halstead (halstead)
# Changhyeok Bae (chbae)
# Kyungjik Min
# Earnest Son
# Mark Hatle (fray)
# Robert Yang

Wait List (Please add yourself at the bottom):

# Bruce Ashfield (zeddii)
# David Reyna
# Alexander Kanavin (kanavin)
# George McCollister (georgem)
# Beth Flanagan (pidge)

# Place Holder

== Agenda Items ==

=== OE Developers Meeting ===

* Board Member ballot
* OE Infrastructure
* 2.7 Features
* Next meeting? Normally in US at ELC in spring. But in 2019 event is in August. Skip? Arrange event in Spring? Where?

== Minutes ==

SHARED MINUTES AT

ACTIONS identified in meeting:

=== Prior minutes ===

Minutes from Portland, Mar 2018:
https://docs.google.com/document/d/1h_otwcH-6ej4URB5vER-7FpaPthrji3TpJWf5jAKRIk/edit?usp=sharing

Minutes from Prague, Oct 2017:
https://docs.google.com/document/d/1R_pV_PumhZ9a8_aRDTuW7wBjqNwIDuau7FGr6sYYRu0/edit?usp=sharing

Minutes from Portland, Feb 2017:
https://docs.google.com/document/d/1ECCfBwdLUaW3I23RATWCU3kGnSh04Kv0DkH1_KfiLVA/edit?usp=sharing

OEDEM 2018

2018-07-21T13:49:35Z

Twoerner:

== Location and Time ==

Sunday, 21 October 2018 (before ELCE [October 22-24]) 
Exact location TBA 
Expectation is to finish by 1800

== Logistics ==

Yes, we know it is Sunday. Best we could do this year.

Attendance is capped at 40. Armin is the bouncer.

== Remote conference link ==

== Planning to Attend ==

* Armpit (Akuster)
* Philip Balister (Crofton)
* Denys Dmytriyenko (denix)
* Marco Cavallini (mckoan)
* Jan Lübbe (shoragan)
* Peter Kjellerstedt (Saur)
* Jeff Osier-Mixon (Jefro)
* Scott Murray (smurray)
* Ruslan Bilovol
* Phil Blundell
* Ross Burton (rburton)
* Richard Purdie (RP)
* Richard Leitner
* Jan-Simon Möller (dl9pf)
* Koen Kooi
* Robert Berger (will join in afternoon approx. 14:00?)
* Ulrich Ölmann (OnkelUlla)
* Trevor Woerner (tlwoerner)

== Agenda Items ==

=== OE Developers Meeting ===

== Minutes ==

SHARED MINUTES AT

ACTIONS identified in meeting:

=== Prior minutes ===

Minutes from Portland, Mar 2018:
https://docs.google.com/document/d/1h_otwcH-6ej4URB5vER-7FpaPthrji3TpJWf5jAKRIk/edit?usp=sharing

Minutes from Prague, Oct 2017:
https://docs.google.com/document/d/1R_pV_PumhZ9a8_aRDTuW7wBjqNwIDuau7FGr6sYYRu0/edit?usp=sharing

Minutes from Portland, Feb 2017:
https://docs.google.com/document/d/1ECCfBwdLUaW3I23RATWCU3kGnSh04Kv0DkH1_KfiLVA/edit?usp=sharing

Styleguide

2018-05-24T18:02:25Z

Twoerner: add BUGTRACKER into the standard variable /function order list

= Motivation =

As with most style guides, the idea here is to have a consistent format and look so that when someone new comes to the scene they can learn quickly and get involved. This also helps reviewers and maintainers understand what changes are being made by contributors.

= Naming Conventions =

* Generally, name recipes <packagename>_<version>.bb
* See also [[Versioning Policy]]

= Format Guidelines =

<ul>
<li>The correct spacing for a variable assignment is FOO = "BAR".</li>
<li>Use quotes on the right hand side of assignments: FOO = "BAR"</li>
<li>No spaces are allowed behind the line continuation symbol (\)</li>
<li>Comments are allowed using the '#' character at the beginning of a line, but you cannot use a comment within a continuation.</li>
<li>Use spaces for indentation as developers tends to use different amount of spaces per one tab.</li>
<li>Python functions must be four space indented - no tabs.</li>
<li>Shell functions in OE-Core usually use tabs for indentation, but other layers usually use consistent indentation with 4 spaces (in shell functions, python functions and for indentation of multi-line variables)</li>
<li>Splitting of long list values (such as SRC_URI) over multiple lines, and indenting the second line onwards is desirable:<ul>
<li>For values split over multiple lines, indent successive lines up to the level of the start of the value on the first line, and have the final closing quote on its own line:<pre>
FOO = "\
bar \
done \
"</pre></li>
<li>Some layers prefer to use four-space indentation on sucessive lines and prefer the closing quote as the first character:<pre>
FOO = "\
bar \
done \
"</pre></li></ul>
</li>
</ul>

= Style Guidelines =

== Additional Metadata ==

All recipes should aim to specify the following fields where possible:

* '''SUMMARY''': should give an 80 character/one line maximum short summary of the description.
* '''DESCRIPTION''': should give an extended (possibly multi-line) description of what recipe provides. Note that by default, DESCRIPTION is set to the value of SUMMARY, so if you only have a short description to use, just set SUMMARY.
* '''HOMEPAGE''': upstream website
* '''BUGTRACKER''': upstream bug tracker URL if available
* '''LICENSE''': must be accurate and list all applicable licenses.
* '''LIC_FILES_CHKSUM''': should if at all possible point to one or more files within the upstream source in order to detect changes on upgrade

For details on how to set LICENSE and LIC_FILES_CHKSUM, see [[Recipe License Fields]].

== do_install ==

* Use <code>oe_runmake install</code> (which runs <code>make install</code>) where at all possible
* Don't use ''cp'' to put files into staging or destination directories, use ''install'' instead.
* Don't use ''mkdir'' to create destination directories, use ''install -d'' instead.
* Modify files after installing them, not before (to ensure do_install can be re-executed)
* Use rm -f to avoid failure in case do_install is re-executed

== Ordering and grouping ==

* Put the ''inherit'' declaration after the initial variables are set up and before any custom ''do_'' routines. This is flexible as ordering is often important.
* If you define custom ''do_'' routines, keep them in the order of the tasks being executed, that is:
** do_fetch
** do_unpack
** do_patch
** do_configure
** do_compile
** do_install
** do_populate_sysroot
** do_package

* Recipes should follow a roughly standard variable / function order, based on the logical order fields are needed and tasks are executed:
** SUMMARY
** DESCRIPTION
** AUTHOR
** HOMEPAGE
** BUGTRACKER
** SECTION
** LICENSE
** LIC_FILES_CHKSUM
** DEPENDS
** PROVIDES
** PV
** SRC_URI
** SRCREV
** S
** inherit ...
** PACKAGECONFIG
** build class specific variables, i.e. EXTRA_QMAKEVARS_POST, EXTRA_OECONF
** task overrides, i.e. do_configure
** PACKAGE_ARCH
** PACKAGES
** FILES
** RDEPENDS
** RRECOMMENDS
** RSUGGESTS
** RPROVIDES
** RCONFLICTS
** BBCLASSEXTEND

* Package related variables for a given package are often grouped together for clarity.

== Version fields ==

* Handling PR (revision):
** Remove PR when PV (i.e. the recipe version) increases
** Preserve existing PR values otherwise (or the overall version will decrease which is not desirable)
** Do not specify PR in new recipes
** No need to increase existing values of PR unless there is a change that would not otherwise trigger the appropriate rebuild/re-execution (very rare)
* If the PV changes in such a way that it does not increase with respect to the previous value, you need to increase PE (or set it to "1" if not already set) to ensure package managers will upgrade it correctly

See also [[Versioning Policy]]

== Patches ==

Patches (i.e. patch files which are referred to in SRC_URI within recipes) should have a header containing information about where they came from and why they are required. This makes examining patches in future and sending appropriate ones upstream much easier.

For further information on patch header formatting, see [[Commit Patch Message Guidelines]].

== Misc ==

* Use BBCLASSEXTEND where possible instead of separate -native and -nativesdk recipes
* Avoid custom do_configure for autotooled projects - the default provided by autotools.bbclass should work for almost all cases
* pkgconfig .pc files should be correct and not need manual mangling

= Style Checking tools =

You can run contrib/oe-stylize.py from meta-oe on your recipes before submitting them; however it is not necessarily up-to-date with all current style conventions. This page should be considered the canonical reference.

= Example Recipe =

<pre>
SUMMARY = "X11 Code Viewer"
DESCRIPTION = "Allow viewing of X11 code in a fancy way which allows easier \
and more productive X11 programming"
AUTHOR = "John Bazz <john.bazz@example.org>"
HOMEPAGE = "http://www.example.org/xcv/"
SECTION = "x11/applications"
LICENSE = "GPL-2.0"
DEPENDS = "libsm libx11 libxext libxaw"
PV = "0.9+git${SRCPV}"

# upstream does not yet publish any release so we have to fetch last working version from GIT
SRCREV = "6a5e79ae8a0f4a273a603b2df1742972510d3d8f"
SRC_URI = "git://xcv.example.org/xcv;protocol=http \
file://toolbar-resize-fix.patch"

S = "${WORKDIR}/xcv/"

inherit autotools

do_configure_prepend() {
rm ${S}/aclocal.m4
}

do_install() {
install -d ${D}${bindir}
install -d ${D}${mandir}/man1

install -m 0755 xcv ${D}${bindir}/
install -m 0644 xcv.1.gz ${D}${mandir}/man1/
}

RDEPENDS_${PN} = "shared-mime-info"
RRECOMMENDS_${PN} = "ctags"
RCONFLICTS_${PN} = "xcv2"
</pre>

[[Category:Policy]]

Styleguide

2018-05-24T17:22:54Z

Twoerner: add PACKAGECONFIG and BBCLASSEXTEND to variable layout section. add EXTRA_OECONF as an additional example of "build class specific variables"

= Motivation =

As with most style guides, the idea here is to have a consistent format and look so that when someone new comes to the scene they can learn quickly and get involved. This also helps reviewers and maintainers understand what changes are being made by contributors.

= Naming Conventions =

* Generally, name recipes <packagename>_<version>.bb
* See also [[Versioning Policy]]

= Format Guidelines =

<ul>
<li>The correct spacing for a variable assignment is FOO = "BAR".</li>
<li>Use quotes on the right hand side of assignments: FOO = "BAR"</li>
<li>No spaces are allowed behind the line continuation symbol (\)</li>
<li>Comments are allowed using the '#' character at the beginning of a line, but you cannot use a comment within a continuation.</li>
<li>Use spaces for indentation as developers tends to use different amount of spaces per one tab.</li>
<li>Python functions must be four space indented - no tabs.</li>
<li>Shell functions in OE-Core usually use tabs for indentation, but other layers usually use consistent indentation with 4 spaces (in shell functions, python functions and for indentation of multi-line variables)</li>
<li>Splitting of long list values (such as SRC_URI) over multiple lines, and indenting the second line onwards is desirable:<ul>
<li>For values split over multiple lines, indent successive lines up to the level of the start of the value on the first line, and have the final closing quote on its own line:<pre>
FOO = "\
bar \
done \
"</pre></li>
<li>Some layers prefer to use four-space indentation on sucessive lines and prefer the closing quote as the first character:<pre>
FOO = "\
bar \
done \
"</pre></li></ul>
</li>
</ul>

= Style Guidelines =

== Additional Metadata ==

All recipes should aim to specify the following fields where possible:

* '''SUMMARY''': should give an 80 character/one line maximum short summary of the description.
* '''DESCRIPTION''': should give an extended (possibly multi-line) description of what recipe provides. Note that by default, DESCRIPTION is set to the value of SUMMARY, so if you only have a short description to use, just set SUMMARY.
* '''HOMEPAGE''': upstream website
* '''BUGTRACKER''': upstream bug tracker URL if available
* '''LICENSE''': must be accurate and list all applicable licenses.
* '''LIC_FILES_CHKSUM''': should if at all possible point to one or more files within the upstream source in order to detect changes on upgrade

For details on how to set LICENSE and LIC_FILES_CHKSUM, see [[Recipe License Fields]].

== do_install ==

* Use <code>oe_runmake install</code> (which runs <code>make install</code>) where at all possible
* Don't use ''cp'' to put files into staging or destination directories, use ''install'' instead.
* Don't use ''mkdir'' to create destination directories, use ''install -d'' instead.
* Modify files after installing them, not before (to ensure do_install can be re-executed)
* Use rm -f to avoid failure in case do_install is re-executed

== Ordering and grouping ==

* Put the ''inherit'' declaration after the initial variables are set up and before any custom ''do_'' routines. This is flexible as ordering is often important.
* If you define custom ''do_'' routines, keep them in the order of the tasks being executed, that is:
** do_fetch
** do_unpack
** do_patch
** do_configure
** do_compile
** do_install
** do_populate_sysroot
** do_package

* Recipes should follow a roughly standard variable / function order, based on the logical order fields are needed and tasks are executed:
** SUMMARY
** DESCRIPTION
** AUTHOR
** HOMEPAGE
** SECTION
** LICENSE
** LIC_FILES_CHKSUM
** DEPENDS
** PROVIDES
** PV
** SRC_URI
** SRCREV
** S
** inherit ...
** PACKAGECONFIG
** build class specific variables, i.e. EXTRA_QMAKEVARS_POST, EXTRA_OECONF
** task overrides, i.e. do_configure
** PACKAGE_ARCH
** PACKAGES
** FILES
** RDEPENDS
** RRECOMMENDS
** RSUGGESTS
** RPROVIDES
** RCONFLICTS
** BBCLASSEXTEND

* Package related variables for a given package are often grouped together for clarity.

== Version fields ==

* Handling PR (revision):
** Remove PR when PV (i.e. the recipe version) increases
** Preserve existing PR values otherwise (or the overall version will decrease which is not desirable)
** Do not specify PR in new recipes
** No need to increase existing values of PR unless there is a change that would not otherwise trigger the appropriate rebuild/re-execution (very rare)
* If the PV changes in such a way that it does not increase with respect to the previous value, you need to increase PE (or set it to "1" if not already set) to ensure package managers will upgrade it correctly

See also [[Versioning Policy]]

== Patches ==

Patches (i.e. patch files which are referred to in SRC_URI within recipes) should have a header containing information about where they came from and why they are required. This makes examining patches in future and sending appropriate ones upstream much easier.

For further information on patch header formatting, see [[Commit Patch Message Guidelines]].

== Misc ==

* Use BBCLASSEXTEND where possible instead of separate -native and -nativesdk recipes
* Avoid custom do_configure for autotooled projects - the default provided by autotools.bbclass should work for almost all cases
* pkgconfig .pc files should be correct and not need manual mangling

= Style Checking tools =

You can run contrib/oe-stylize.py from meta-oe on your recipes before submitting them; however it is not necessarily up-to-date with all current style conventions. This page should be considered the canonical reference.

= Example Recipe =

<pre>
SUMMARY = "X11 Code Viewer"
DESCRIPTION = "Allow viewing of X11 code in a fancy way which allows easier \
and more productive X11 programming"
AUTHOR = "John Bazz <john.bazz@example.org>"
HOMEPAGE = "http://www.example.org/xcv/"
SECTION = "x11/applications"
LICENSE = "GPL-2.0"
DEPENDS = "libsm libx11 libxext libxaw"
PV = "0.9+git${SRCPV}"

# upstream does not yet publish any release so we have to fetch last working version from GIT
SRCREV = "6a5e79ae8a0f4a273a603b2df1742972510d3d8f"
SRC_URI = "git://xcv.example.org/xcv;protocol=http \
file://toolbar-resize-fix.patch"

S = "${WORKDIR}/xcv/"

inherit autotools

do_configure_prepend() {
rm ${S}/aclocal.m4
}

do_install() {
install -d ${D}${bindir}
install -d ${D}${mandir}/man1

install -m 0755 xcv ${D}${bindir}/
install -m 0644 xcv.1.gz ${D}${mandir}/man1/
}

RDEPENDS_${PN} = "shared-mime-info"
RRECOMMENDS_${PN} = "ctags"
RCONFLICTS_${PN} = "xcv2"
</pre>

[[Category:Policy]]

2018 05 General Meeting

2018-05-21T12:53:39Z

Twoerner: /* Planning to attend */

== Purpose ==
The board would like to have another general meeting among OpenEmbedded members to discuss current events and hear any concerns.

== Date and Time ==
2017-05-21 @ 6am US-PDT(-0700) / 8am US-CDT(-0500) / 9am US-EDT(-0400) / 3pm CEST(+0200) / 1pm UTC

[https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180521T1300 get the date/time in your timezone]

[https://www.timeanddate.com/countdown/generic?p0=1440&iso=20180521T13 countdown]

== Shared Minutes/Notes ==
TBD

== Teleconference Information ==

Meeting will be held as a teleconference with a IRC channel to allow for background discussion and trouble shooting of audio.

IRC: #oe-meeting on freenode

'''Dial-in Conference'''

WebEx

https://montavista.webex.com/montavista/j.php?MTID=m0e22cedefc81fb61717657aaf9311c7b

'''Monday, May 21, 2018'''

6:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 1 hr

'''Meeting number (access code):''' 809 423 572

'''Meeting password''': bgiaq292

'''Audio connection:'''

1-866-469-3239 Call-in toll-free number (US/Canada)

1-650-429-3300 Call-in toll number (US/Canada)

Global call-in numbers: [https://montavista.webex.com/cmp3300/webcomponents/widget/globalcallin/globalcallin.do?siteurl=montavista&serviceType=MC&eventID=686011287&tollFree=1]
Show toll-free dialing restrictions: [https://www.webex.com/pdf/tollfree_restrictions.pdf]

== Tentative Agenda ==
# Current events
# Concerns
# General discussion

== Planning to attend ==
* Denys Dmytriyenko (denix)
* Sean Hudson (darknighte)
* Paul Barker (paulbarker)
* Ross Burton (rburton)
* Richard Purdie (RP)
* Armin Kuster (armpit)
* Jeff Osier-Mixon (jefro)
* Trevor Woerner (tlwoerner)

2018 02 General Meeting

2018-01-24T19:56:27Z

Twoerner: /* Date and Time */

== Purpose ==
The board would like to have another general meeting before [[OEDAM 2018]].
In addition to general discussion and sharing of technical topics, it will be used to collect items for deeper discussion at [[OEDAM 2018]].

== Date and Time ==
2017-02-21 @ 8am US-CDT(UTC-06:00)/3pm CET(UTC+01:00)

[https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180221T1400 get the date/time in your timezone]

[https://www.timeanddate.com/countdown/generic?p0=1440&iso=20180221T14 countdown]

== Shared Minutes/Notes ==
https://docs.google.com/document/d/1CcYx4llC0MXOm3QYjiB7L59pMIt0gYZgHpx-B8Yshqc/edit

== Teleconference Information ==

Meeting will be held as a teleconference with a IRC channel to allow for background discussion and trouble shooting of audio.

IRC: #oe-meeting on freenode

'''Dial-in Conference'''

WebEx

URL: https://montavista.webex.com/montavista/j.php?MTID=m52131dab2389b280928d4ee131aeddec

Meeting number: 804 189 799

Meeting password: DB4E3Kj3

== Tentative Agenda ==
# Topics for deeper discussion at OEDAM
# General discussion
# Knowledge Sharing/Q&A

== Planning to attend ==
* Sean Hudson (irc:darknighte)
* Tom Rini (irc:Tartarus)
* Trevor Woerner (irc:tlwoerner)
* Denys Dmytriyenko (denix)

2018 02 General Meeting

2018-01-23T03:27:35Z

Twoerner: /* Planning to attend */

== Purpose ==
The board would like to have another general meeting before [[OEDAM 2018]].
In addition to general discussion and sharing of technical topics, it will be used to collect items for deeper discussion at [[OEDAM 2018]].

== Date and Time ==
2017-02-21 @ 8am US-CDT(UTC-06:00)/3pm CET(UTC+01:00)

== Shared Minutes/Notes ==
https://docs.google.com/document/d/1CcYx4llC0MXOm3QYjiB7L59pMIt0gYZgHpx-B8Yshqc/edit

== Teleconference Information ==

Meeting will be held as a teleconference with a IRC channel to allow for background discussion and trouble shooting of audio.

IRC: #oe-meeting on freenode

'''Dial-in Conference'''

WebEx

URL: https://montavista.webex.com/montavista/j.php?MTID=m52131dab2389b280928d4ee131aeddec

Meeting number: 804 189 799

Meeting password: DB4E3Kj3

== Tentative Agenda ==
# Topics for deeper discussion at OEDAM
# General discussion
# Knowledge Sharing/Q&A

== Planning to attend ==
* Sean Hudson (irc:darknighte)
* Tom Rini (irc:Tartarus)
* Trevor Woerner (irc:tlwoerner)

OEDEM 2017

2017-09-21T09:57:24Z

Twoerner:

== Location and Time ==

Sunday, 22 October 2017 
Start at 0900

(before ELC-E [Oct 23-25])

Yes, we know it is Sunday. Best we could do this year.

NOTE: venue has changed, we are now at:

JURY'S INN Prague
Sokolovská 204/11, 186 00
Praha 8-Florenc, Czechia

This hotel is across the street from the Hilton (ELCE venue). If you have any difficulty please let [mailto:jefro@jefro.net jefro] know.

== Attendees ==

* Jeff Osier-Mixon "Jefro"
* Behan Webster (behanw)
* Philip Balister (Crofton)
* Martin Jansa (JaMa)
* Scott Murray (smurray)
* Peter Kjellerstedt (Saur)
* Armin Kuster (Armpit)
* Paul Barker (paulbarker)
* Myunghun Chun
* Changhyeok Bae (chbae)
* Adrian Ratiu (aratiu)
* Josef Holzmayr (LetoThe2nd)
* Jan Leupold
* Anders Darander
* Sean Hudson (darknighte)
* Tim Orling (moto-timo)
* Ricardo Ribalda (ribalda)
* Nicolas Dechesne (ndec)
* Richard Purdie (RP)
* Andrei Gherzan (agherzan)
* Denys Dmytriyenko (denix)
* Anton Gerasimov
* Rich Persaud
* Koen Kooi
* Marek Vasut (marex)
* Ruslan Bilovol
* Grygorii Tertychnyi
* Bruce Ashfield (zeddii)
* Mark Hatle (fray)
* Jan-Simon Möller (dl9pf)
* Mike Looijmans ''flight landing at 8:15''
* Mario Domenech Goulart (mario-goulart)
* Andrea Galbusera (gizero)
* Michael Ho

Attending in the afternoon or not sure because landing too late

* Marco Cavallini (mckoan)

NOTE: we will make every effort to provide a web/phone link for remote attendees

== Agenda Items ==

# Stack Overflow report (From someone who regularly watches stackoverflow)
# Demos for FOSDEM and other events. Good chance to (discretely) show your company's work. (Philip)
# Long-term releases support (more than one year)
# Automated CVE checking, issues with cve-check-tool, alternative tools
# MvTest - Test Automation framework

== Minutes ==

=== OEDEM: ===

2017 General Meeting

2017-04-20T00:26:20Z

Twoerner: /* Planning to attend */

== Purpose ==
The new bylaws of the organization require '''at least''' one general meeting per year. This will fulfill that requirement. Also, we plan to discuss topics of interest to the community and the project.

== Date and Time ==
'''!!!Tentative!!!''' 2017-05-03 @ 8am US-CDT(UTC-06:00)/3pm CET(UTC+01:00)

Here's a link to the time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+2017+General+Meeting&iso=20170503T08&p1=24&ah=1

Countdown link:
https://www.timeanddate.com/countdown/generic?p0=24&iso=20170503T08&msg=OpenEmbedded%202017%20General%20Meeting

== Conference Information ==

Meeting will be held as a teleconference with a IRC channel to allow for background discussion and trouble shooting of audio.

IRC: #oe-meeting on freenode

'''Dial-in Conference # 8964521'''

{| class="wikitable"
!colspan="2"|Dial-in Information
|-
| United States (USA)
|917-210-2607
|-
|DENMARK (DNK)
|36910500
|-
|FINLAND (FIN)
|923194205
|-
|GERMANY (DEU)
|69710448206
|-
|IRELAND (IRL)
|14360203
|-
|MEXICO
|52-5547772297
|-
|NETHERLANDS (NLD)
|207940366
|-
|PAKISTAN
|4238108701
|-
|ROMANIA
|215291724
|-
|RUSSIA
|7 4959952645
|-
|SPAIN (ESP)
|917911851
|-
|SWEDEN (SWE)
|114501530
|-
|UNITED KINGDOM (GBR)
|2070840301
|-
|}

== Tentative Agenda ==
# Meeting Schedule
## The board would like to propose a quarterly meeting schedule with alternating online and face-to-face meetings.
# Membership
## Grandfathered all existing members in good standing
## New members
# TSC
## Grandfathered from old organization
# Online voting
# Elections
# Future plans/purpose for the organization
# Technical topics

== Planning to attend ==
* Sean Hudson (irc:darknighte)
* Denys Dmytriyenko (denix)
* Bruce Ashfield (zeddii*)
* Armin Kuster (armpit)
* Mark Hatle (fray)
* Tom Rini (Tartarus)
* Trevor Woerner (tlwoerner)

OEDAM 2017

2017-01-09T22:26:49Z

Twoerner: /* Attendees */

== Location and Time ==

Monday February 20 2017

Location TBA

(Before ELC [Feb 21-23] and Yocto Project Developer Day [Feb 24])

== Attendees ==

* Armin Kuster (armpit)
* Philip Balister (Crofton)
* Trevor Woerner (tlwoerner)

== Agenda Items ==

* Review items from last meeting in Berlin (Please add remarks)

== Minutes ==

OEDAM 2017

2017-01-09T22:25:45Z

Twoerner: /* Attendees */

== Location and Time ==

Monday February 20 2017

Location TBA

(Before ELC [Feb 21-23] and Yocto Project Developer Day [Feb 24])

== Attendees ==

- Armin Kuster (armpit)
- Philip Balister (Crofton)
- Trevor Woerner (tlwoerner)

== Agenda Items ==

* Review items from last meeting in Berlin (Please add remarks)

== Minutes ==

OEDAM 2017

2017-01-09T22:25:20Z

Twoerner: /* Attendees */

== Location and Time ==

Monday February 20 2017

Location TBA

(Before ELC [Feb 21-23] and Yocto Project Developer Day [Feb 24])

== Attendees ==

Armin Kuster (armpit)
Philip Balister (Crofton)
Trevor Woerner (tlwoerner)

== Agenda Items ==

* Review items from last meeting in Berlin (Please add remarks)

== Minutes ==

OEDAM 2016

2016-02-25T05:32:43Z

Twoerner: /* Location and Time */

== Location and Time ==

Friday April 8 2016 (after ELC [Aug 4-6] and Yocto Project Developer Day [Aug 7])

== Attendees ==
Armin Kuster (Armpit) 
Trevor Woerner 

== Agenda Items ==

== Minutes ==

OEDAM 2016

2016-02-24T22:48:06Z

Twoerner: /* Location and Time */

== Location and Time ==

Friday April 8 2016 (after ELC and Yocto Project Developer Day)

== Attendees ==
Armin Kuster (Armpit) 
Trevor Woerner 

== Agenda Items ==

== Minutes ==

OEDAM 2016

2016-02-24T22:46:51Z

Twoerner: /* Attendees */

== Location and Time ==

April 8 (after ELC and Yocto Project Developer Day)

== Attendees ==
Armin Kuster (Armpit) 
Trevor Woerner 

== Agenda Items ==

== Minutes ==

OEDAM 2016

2016-02-24T22:45:04Z

Twoerner: /* Attendees */

== Location and Time ==

April 8 (after ELC and Yocto Project Developer Day)

== Attendees ==
Armin Kuster (Armpit)
Trevor Woerner

== Agenda Items ==

== Minutes ==

OEDEM 2015

2015-10-09T15:50:20Z

Twoerner: /* Agenda */

The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland. Part of this meeting will also constitute the annual OE General Assembly, and some corporation/eV matters will be discussed.

== Location and Time ==

[http://www.thegibsonhotel.ie/ The Gibson Hotel] 
Point Village 
Dublin 1, Ireland 
+353 1 681 5000

9am - 5pm (note: times may change)

Gibson Hotel is at the end of the red LUAS line, adjacent to the stadium. Come up to the 3rd floor and follow the signs for the Cordoba room. (the sign says "Mtg", that's us) There is coffee here. See you all soon

== OpenEmbedded eV General Assembly ==

We have a short administrative meeting before starting the Developer meeting. All are welcome for this.

* Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project.
* Define a method for identifying lapsed memberships.
* Proxy form [[File:Proxy_instructions-oe.pdf]]
* [http://www.openembedded.org/wiki/Dublin,_2015 Meeting Minutes]

== Agenda ==

* <s>Metadata</s>
** <s>OVERRIDE syntax: is it time to reconsider _?</s>
** <s>meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)</s>
** <s>variable expand = True by default</s>

* <s>BSPs (tlwoerner)</s>
** <s>Standards for BSP behavior. (Crofton)</s>
** <s>feedback on layerindex to indicate BSP:
*** last successful compile (feedback from outside builders?)
*** last successful boot
*** master branch parsability (perhaps ties into bugzilla 7792?)</s>
** <s>several BSP layers to choose from for some boards, none for others (linux.com SBC survey)</s>
** <s>guidelines/requirements for setting up a new BSP on layerindex
*** bugzilla
*** mailing list (use general mailing list(s) for patches?)
*** git.yoctoproject.org/<yourbsplayer></s>
** <s>making sure BSP layers only touch the variables/settings they should touch
*** should a BSP layer ever use = ?</s>
** <s>does/should a BSP produce artifacts that are easy to install to SD cards? (Crofton)</s>

*<s>Processes</s>
** <s>LayerIndex feature requests (tlwoerner)
** build feedback (autobuilders and off-site)
** Build and test failures on the public Autobuilder (Bluelightening)</s>

*<s>Systemd
** Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info)
** Can we get systemd's first-boot support to work? It is currently disabled in the systemd recipe by touching /etc/machine-id. (Saur)</s>
** <s>How to make it easy to setup a system "the systemd way"? New DISTRO_FEATURE or IMAGE_FEATURE? (Saur)</s>
*** <s>Link /bin -> /usr/bin, /lib -> /usr/lib, etc.</s>
*** <s>Change ${systemd_unitdir} to /usr/lib.</s>
*** <s>Make the systemctl wrapper install in ${systemd_unitdir} rather than ${systemconf}/systemd.
**** This should also happen when installing a package in runtime.</s>

*<s>Advocacy
** There are still a lot of projects (too many?) not using OE (tlwoerner)
** why aren't more projects using OE?
** how can we get more people using OE?
** who should we be targeting? (build people (obviously), kernel devs? user-space devs?)</s>

== Attendees ==

If you plan to attend, please list your name below.

# Jeff Osier-Mixon (jefro)
# Philip Balister (Crofton)
# Trevor Woerner (tlwoerner)
# Anders Darander (andersd)
# Marco Cavallini (mckoan)
# Koen Kooi (koen)
# Alexandre Belloni (abelloni)
# Armin Kuster (armpit)
# Belén Barros Pena (belen)
# Peter Kjellerstedt (Saur)
# Alejandro del Castillo (adelcast)
# Denys Dmytriyenko (denix)
# Sean Hudson (darknighte)
# Nathan Rossi (nrossi)
# Mark Hatle (fray)
# Nicolas Dechesne (ndec)
# Paul Eggleton (bluelightning)
# Andrei Gherzan (agherzan)
# Felipe F. Tonello (ftonello)
# Changhyeok Bae (chbae)
# Saul Wold (sgw)
# Ashish Shrivastava
# Pascal Bach (bachp)
# Richard Purdie (RP)
# Michael Halstead (halstead)

== Proceedings ==

RAW notes shown in boxes like this
=> this is an action item
-> this is a desired thing

Introduce TSC

* Martin Jansa (jama)
* Mark Hatle (fray)
* Paul Eggleton (bluelightning)
* Richard Purdie (RP)
* Khem Raj (khem)

go over agenda
BSP topic first to accommodate member travel

=== BSPs & Layer Index ===

Paul described layer index process & how it works
BBP layers also come into toaster, expose to people, dependency list very important - snapshot when setting up toaster
module branches - will look in repo for branches
some layers don't have a master branch, don't show content - need way to present in UI
REST API
DD automatically parse layer to check for required content? PE do want, necessitates background queuing process
parse w/dependencies
also affects YP Compatible, RP's proposed layer validation tool
error reporting system - tie together with info in layer index, intention there
JH ability to register layer & specify quality
------------------------------------------
not getting resources to work on core BSPs
people working on own BSPs - not really a complaint, but an observation
SH would love to see REST APIs
PE would love some help with the layer index
RP love ideas, but people need to resource, step up & drive
------------------------------------------
=> oe driving toward machine readable files, can also drive from layer test (yp compat) side - KK
------------------------------------------
oe-core or oe-devel? oe-core
------------------------------------------
=> publicize defs of each list? discuss on members list - where to overall architecture discussions belong
discussion: decided on oe-core
oe needs its own goals, interact with the yocto project
------------------------------------------
status email to oe-core list, useful? to most people. cross-postd to yocto list
KK should be about oe-core, not about poky
=> TSC to add new mailing list specifically about project architecture, no patches, and determine list name
------------------------------------------
KK realize that OE has no project vision
RP is there any vision that needs to be represented to YP, and are there resources
KK as a project take an active role to work with YP
marketing/visibility standpoint, wear OE hat
if list of oe bugs that should be raised, bring to philip
-> KK bring discussion to new mailing list
------------------------------------------
TW can new layers use bugzilla
PE struggle with volume of bugs currently in triage process
RP triage process - yp has taken on oe-core eg. don't want many bugs from idle layers, YP judged on metrics from that system
SW some layers already in that state
DD attended call regularly
RP maintainers must be willing to come to triage process
some issues don't have a clear maintainer
------------------------------------------
BSP standards - standards exist,coming soon are methods for comparing a given layer with the standard
"oe has no rules, only half-documented best practices" - Koen
=> need wiki documentation for TSC to ratify
-> document distro vs. machine policies, other best practices
------------------------------------------
BSP layer availability
-> encourage board vendors to provide a BSP, make it easier to do so
people problem, not technical problem
add questionnaire about why people don't
ask LF to include a list of BSPs that are supported
=> ask yp ab to talk to linux.com [PB] - community issue
build for qemu, with limited resources
-> look at digi manual (i.e. "just add bsp changes in local.conf")
best practices : should be easy to use, instructions/tools to put it on a card, etc
wic incomplete but promising
------------------------------------------
touching variables - discuss on new arch list
------------------------------------------

=== Metadata ===

meta-yocto to meta-poky:

=> RP to take action on the YP side, possibly not for 2.0

override syntax

underscore character to designate overrides, underscore is overloaded
need better method
KK maybe _OVERRIDE_
dot character?
require all lowercase overrides? benefits for bitbake speed
=> formalize lowercase as mandatory requirement for overrides, look for other options in the future

=== Processes ===

Layer Index feature requests discussed with layer index
build feedback>>

Build/test failures on public autobuilder

problems:
RP
different failures "random" - actually is a pattern, but initially looks random
build poky and poky-lsb, lsb turns on different distro features
boots a machine in qemu & runs scripts, most qemu machines, just says "kill" - unknown
release blocker causing qa failures
also, systemd having timeout issues
should OE care about these things? (yes)
PE
set up environment to detect regressions
did upgrading qemu and systemd create these? get to a correct point
not poky changes or bsp changes
eg poky enables ptest, doesn't affect systemd timeout
RP
have massively increased scope of tests
ptests, sdk..
resources always an issue
-> ask for cycles from employers to work on these issues
-> make people aware, help with triage, provide resources
KK -> plan B, C, etc. have had this problem for years
more issues recently

=== Security ===

security a long term issue, beginning to be noticed - now reluctant to address it, as it is being noticed/resourced
if patch had standard cv, could write automated tools to parse
-> need a method for tracking CVs
MH have to have someone whose job it is to pull CV list, look for differences, assess applicability
Michael Halstead : LF can run security audits of individual tools
could do layer index, toaster, ... busybox
MH independent academic audit found OE very good

=== Systemd ===

currently scaling up
complaints: more package config, comments; look at packaging to have minimal systemd even with options available
-> need someone with time available to work on it
-> need to get systemd feedback, people using systemd talk to package maintainer
MH automotive is a heavy user, could ask genivi for help
peter, koen using systemd but not using official oe recipe - based on

Can we get systemd first boot support to work?
MH wind struggling on read-only filesystems

Easy setup "should work now"
yes can get it to work - talk to upstream
changing prefixes problematic
MH unitdir to /usr/lib - can't boot without base lib
should be able to boot minimal system w/shell and some commands
should work if reasonable default can be changed
patches are problematic - RP wants clear coherent vision

systemctl wrapper needs documentation for working with systemd
current docs targeted at app developers - not distro devs
want to use the install section
=> file systemctl wrapper bug

=== Advocacy ===
b
why aren't more projects using OE?

Belen:
difficult to understand & get started with
- toaster
don't understand the benefits
- not a distro
slower systems complain about performance (also don't understand sstate)
- could enable sstate mirrors by default
- now measuring size of builds
- massively examine macros in autotools

how can we get more people using OE?

outreach
documentation
intro on oe, what it is & benefits

no official body within OE to handle this - community mgmt, advocacy
-> board to discuss advocacy/community, invite jefro to meetings

need someone to run oe booth at fosdem, as paul is leaving [beth, belen]

value in tools:
devtool
adt

who should we be targeting? build people, kernel devs, userspace devs

* college kids, interns
* grad school programs
* makers
* white papers - active promotion (how is this different from debian etc) - at executive level; case studies, potato counter, comcast
* maintain community metrics
* koen: conference presentation comparing various build systems (oe, buildroot, etc)
* devs doing board bringup
* is oe for everyone?

OEDEM 2015

2015-10-09T15:49:46Z

Twoerner: /* Agenda */

The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland. Part of this meeting will also constitute the annual OE General Assembly, and some corporation/eV matters will be discussed.

== Location and Time ==

[http://www.thegibsonhotel.ie/ The Gibson Hotel] 
Point Village 
Dublin 1, Ireland 
+353 1 681 5000

9am - 5pm (note: times may change)

Gibson Hotel is at the end of the red LUAS line, adjacent to the stadium. Come up to the 3rd floor and follow the signs for the Cordoba room. (the sign says "Mtg", that's us) There is coffee here. See you all soon

== OpenEmbedded eV General Assembly ==

We have a short administrative meeting before starting the Developer meeting. All are welcome for this.

* Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project.
* Define a method for identifying lapsed memberships.
* Proxy form [[File:Proxy_instructions-oe.pdf]]
* [http://www.openembedded.org/wiki/Dublin,_2015 Meeting Minutes]

== Agenda ==

* <s>Metadata</s>
** <s>OVERRIDE syntax: is it time to reconsider _?</s>
** <s>meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)</s>
** <s>variable expand = True by default</s>

* <s>BSPs (tlwoerner)</s>
** <s>Standards for BSP behavior. (Crofton)</s>
** <s>feedback on layerindex to indicate BSP:
*** last successful compile (feedback from outside builders?)
*** last successful boot
*** master branch parsability (perhaps ties into bugzilla 7792?)</s>
** <s>several BSP layers to choose from for some boards, none for others (linux.com SBC survey)</s>
** <s>guidelines/requirements for setting up a new BSP on layerindex
*** bugzilla
*** mailing list (use general mailing list(s) for patches?)
*** git.yoctoproject.org/<yourbsplayer></s>
** <s>making sure BSP layers only touch the variables/settings they should touch
*** should a BSP layer ever use = ?</s>
** <s>does/should a BSP produce artifacts that are easy to install to SD cards? (Crofton)</s>

*<s>Processes</s>
** <s>LayerIndex feature requests (tlwoerner)
** build feedback (autobuilders and off-site)
** Build and test failures on the public Autobuilder (Bluelightening)</s>

*Systemd
** <s>Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info)
** Can we get systemd's first-boot support to work? It is currently disabled in the systemd recipe by touching /etc/machine-id. (Saur)</s>
** <s>How to make it easy to setup a system "the systemd way"? New DISTRO_FEATURE or IMAGE_FEATURE? (Saur)</s>
*** <s>Link /bin -> /usr/bin, /lib -> /usr/lib, etc.</s>
*** <s>Change ${systemd_unitdir} to /usr/lib.</s>
*** <s>Make the systemctl wrapper install in ${systemd_unitdir} rather than ${systemconf}/systemd.
**** This should also happen when installing a package in runtime.</s>

*<s>Advocacy
** There are still a lot of projects (too many?) not using OE (tlwoerner)
** why aren't more projects using OE?
** how can we get more people using OE?
** who should we be targeting? (build people (obviously), kernel devs? user-space devs?)</s>

== Attendees ==

If you plan to attend, please list your name below.

# Jeff Osier-Mixon (jefro)
# Philip Balister (Crofton)
# Trevor Woerner (tlwoerner)
# Anders Darander (andersd)
# Marco Cavallini (mckoan)
# Koen Kooi (koen)
# Alexandre Belloni (abelloni)
# Armin Kuster (armpit)
# Belén Barros Pena (belen)
# Peter Kjellerstedt (Saur)
# Alejandro del Castillo (adelcast)
# Denys Dmytriyenko (denix)
# Sean Hudson (darknighte)
# Nathan Rossi (nrossi)
# Mark Hatle (fray)
# Nicolas Dechesne (ndec)
# Paul Eggleton (bluelightning)
# Andrei Gherzan (agherzan)
# Felipe F. Tonello (ftonello)
# Changhyeok Bae (chbae)
# Saul Wold (sgw)
# Ashish Shrivastava
# Pascal Bach (bachp)
# Richard Purdie (RP)
# Michael Halstead (halstead)

== Proceedings ==

RAW notes shown in boxes like this
=> this is an action item
-> this is a desired thing

Introduce TSC

* Martin Jansa (jama)
* Mark Hatle (fray)
* Paul Eggleton (bluelightning)
* Richard Purdie (RP)
* Khem Raj (khem)

go over agenda
BSP topic first to accommodate member travel

=== BSPs & Layer Index ===

Paul described layer index process & how it works
BBP layers also come into toaster, expose to people, dependency list very important - snapshot when setting up toaster
module branches - will look in repo for branches
some layers don't have a master branch, don't show content - need way to present in UI
REST API
DD automatically parse layer to check for required content? PE do want, necessitates background queuing process
parse w/dependencies
also affects YP Compatible, RP's proposed layer validation tool
error reporting system - tie together with info in layer index, intention there
JH ability to register layer & specify quality
------------------------------------------
not getting resources to work on core BSPs
people working on own BSPs - not really a complaint, but an observation
SH would love to see REST APIs
PE would love some help with the layer index
RP love ideas, but people need to resource, step up & drive
------------------------------------------
=> oe driving toward machine readable files, can also drive from layer test (yp compat) side - KK
------------------------------------------
oe-core or oe-devel? oe-core
------------------------------------------
=> publicize defs of each list? discuss on members list - where to overall architecture discussions belong
discussion: decided on oe-core
oe needs its own goals, interact with the yocto project
------------------------------------------
status email to oe-core list, useful? to most people. cross-postd to yocto list
KK should be about oe-core, not about poky
=> TSC to add new mailing list specifically about project architecture, no patches, and determine list name
------------------------------------------
KK realize that OE has no project vision
RP is there any vision that needs to be represented to YP, and are there resources
KK as a project take an active role to work with YP
marketing/visibility standpoint, wear OE hat
if list of oe bugs that should be raised, bring to philip
-> KK bring discussion to new mailing list
------------------------------------------
TW can new layers use bugzilla
PE struggle with volume of bugs currently in triage process
RP triage process - yp has taken on oe-core eg. don't want many bugs from idle layers, YP judged on metrics from that system
SW some layers already in that state
DD attended call regularly
RP maintainers must be willing to come to triage process
some issues don't have a clear maintainer
------------------------------------------
BSP standards - standards exist,coming soon are methods for comparing a given layer with the standard
"oe has no rules, only half-documented best practices" - Koen
=> need wiki documentation for TSC to ratify
-> document distro vs. machine policies, other best practices
------------------------------------------
BSP layer availability
-> encourage board vendors to provide a BSP, make it easier to do so
people problem, not technical problem
add questionnaire about why people don't
ask LF to include a list of BSPs that are supported
=> ask yp ab to talk to linux.com [PB] - community issue
build for qemu, with limited resources
-> look at digi manual (i.e. "just add bsp changes in local.conf")
best practices : should be easy to use, instructions/tools to put it on a card, etc
wic incomplete but promising
------------------------------------------
touching variables - discuss on new arch list
------------------------------------------

=== Metadata ===

meta-yocto to meta-poky:

=> RP to take action on the YP side, possibly not for 2.0

override syntax

underscore character to designate overrides, underscore is overloaded
need better method
KK maybe _OVERRIDE_
dot character?
require all lowercase overrides? benefits for bitbake speed
=> formalize lowercase as mandatory requirement for overrides, look for other options in the future

=== Processes ===

Layer Index feature requests discussed with layer index
build feedback>>

Build/test failures on public autobuilder

problems:
RP
different failures "random" - actually is a pattern, but initially looks random
build poky and poky-lsb, lsb turns on different distro features
boots a machine in qemu & runs scripts, most qemu machines, just says "kill" - unknown
release blocker causing qa failures
also, systemd having timeout issues
should OE care about these things? (yes)
PE
set up environment to detect regressions
did upgrading qemu and systemd create these? get to a correct point
not poky changes or bsp changes
eg poky enables ptest, doesn't affect systemd timeout
RP
have massively increased scope of tests
ptests, sdk..
resources always an issue
-> ask for cycles from employers to work on these issues
-> make people aware, help with triage, provide resources
KK -> plan B, C, etc. have had this problem for years
more issues recently

=== Security ===

security a long term issue, beginning to be noticed - now reluctant to address it, as it is being noticed/resourced
if patch had standard cv, could write automated tools to parse
-> need a method for tracking CVs
MH have to have someone whose job it is to pull CV list, look for differences, assess applicability
Michael Halstead : LF can run security audits of individual tools
could do layer index, toaster, ... busybox
MH independent academic audit found OE very good

=== Systemd ===

currently scaling up
complaints: more package config, comments; look at packaging to have minimal systemd even with options available
-> need someone with time available to work on it
-> need to get systemd feedback, people using systemd talk to package maintainer
MH automotive is a heavy user, could ask genivi for help
peter, koen using systemd but not using official oe recipe - based on

Can we get systemd first boot support to work?
MH wind struggling on read-only filesystems

Easy setup "should work now"
yes can get it to work - talk to upstream
changing prefixes problematic
MH unitdir to /usr/lib - can't boot without base lib
should be able to boot minimal system w/shell and some commands
should work if reasonable default can be changed
patches are problematic - RP wants clear coherent vision

systemctl wrapper needs documentation for working with systemd
current docs targeted at app developers - not distro devs
want to use the install section
=> file systemctl wrapper bug

=== Advocacy ===
b
why aren't more projects using OE?

Belen:
difficult to understand & get started with
- toaster
don't understand the benefits
- not a distro
slower systems complain about performance (also don't understand sstate)
- could enable sstate mirrors by default
- now measuring size of builds
- massively examine macros in autotools

how can we get more people using OE?

outreach
documentation
intro on oe, what it is & benefits

no official body within OE to handle this - community mgmt, advocacy
-> board to discuss advocacy/community, invite jefro to meetings

need someone to run oe booth at fosdem, as paul is leaving [beth, belen]

value in tools:
devtool
adt

who should we be targeting? build people, kernel devs, userspace devs

* college kids, interns
* grad school programs
* makers
* white papers - active promotion (how is this different from debian etc) - at executive level; case studies, potato counter, comcast
* maintain community metrics
* koen: conference presentation comparing various build systems (oe, buildroot, etc)
* devs doing board bringup
* is oe for everyone?

OEDEM 2015

2015-10-09T14:58:50Z

Twoerner: /* Agenda */

The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland. Part of this meeting will also constitute the annual OE General Assembly, and some corporation/eV matters will be discussed.

== Location and Time ==

[http://www.thegibsonhotel.ie/ The Gibson Hotel] 
Point Village 
Dublin 1, Ireland 
+353 1 681 5000

9am - 5pm (note: times may change)

Gibson Hotel is at the end of the red LUAS line, adjacent to the stadium. Come up to the 3rd floor and follow the signs for the Cordoba room. (the sign says "Mtg", that's us) There is coffee here. See you all soon

== OpenEmbedded eV General Assembly ==

We have a short administrative meeting before starting the Developer meeting. All are welcome for this.

* Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project.
* Define a method for identifying lapsed memberships.
* Proxy form [[File:Proxy_instructions-oe.pdf]]
* [http://www.openembedded.org/wiki/Dublin,_2015 Meeting Minutes]

== Agenda ==

* <s>Metadata</s>
** <s>OVERRIDE syntax: is it time to reconsider _?</s>
** <s>meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)</s>
** <s>variable expand = True by default</s>

* <s>BSPs (tlwoerner)</s>
** <s>Standards for BSP behavior. (Crofton)</s>
** <s>feedback on layerindex to indicate BSP:
*** last successful compile (feedback from outside builders?)
*** last successful boot
*** master branch parsability (perhaps ties into bugzilla 7792?)</s>
** <s>several BSP layers to choose from for some boards, none for others (linux.com SBC survey)</s>
** <s>guidelines/requirements for setting up a new BSP on layerindex
*** bugzilla
*** mailing list (use general mailing list(s) for patches?)
*** git.yoctoproject.org/<yourbsplayer></s>
** <s>making sure BSP layers only touch the variables/settings they should touch
*** should a BSP layer ever use = ?</s>
** <s>does/should a BSP produce artifacts that are easy to install to SD cards? (Crofton)</s>

*<s>Processes</s>
** <s>LayerIndex feature requests (tlwoerner)
** build feedback (autobuilders and off-site)
** Build and test failures on the public Autobuilder (Bluelightening)</s>

*Systemd
** <s>Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info)
** Can we get systemd's first-boot support to work? It is currently disabled in the systemd recipe by touching /etc/machine-id. (Saur)</s>
** <s>How to make it easy to setup a system "the systemd way"? New DISTRO_FEATURE or IMAGE_FEATURE? (Saur)</s>
*** <s>Link /bin -> /usr/bin, /lib -> /usr/lib, etc.</s>
*** <s>Change ${systemd_unitdir} to /usr/lib.</s>
*** <s>Make the systemctl wrapper install in ${systemd_unitdir} rather than ${systemconf}/systemd.
**** This should also happen when installing a package in runtime.</s>

*Advocacy
** There are still a lot of projects (too many?) not using OE (tlwoerner)
** why aren't more projects using OE?
** how can we get more people using OE?
** who should we be targeting? (build people (obviously), kernel devs? user-space devs?)

== Attendees ==

If you plan to attend, please list your name below.

# Jeff Osier-Mixon (jefro)
# Philip Balister (Crofton)
# Trevor Woerner (tlwoerner)
# Anders Darander (andersd)
# Marco Cavallini (mckoan)
# Koen Kooi (koen)
# Alexandre Belloni (abelloni)
# Armin Kuster (armpit)
# Belén Barros Pena (belen)
# Peter Kjellerstedt (Saur)
# Alejandro del Castillo (adelcast)
# Denys Dmytriyenko (denix)
# Sean Hudson (darknighte)
# Nathan Rossi (nrossi)
# Mark Hatle (fray)
# Nicolas Dechesne (ndec)
# Paul Eggleton (bluelightning)
# Andrei Gherzan (agherzan)
# Felipe F. Tonello (ftonello)
# Changhyeok Bae (chbae)
# Saul Wold (sgw)
# Ashish Shrivastava
# Pascal Bach (bachp)
# Richard Purdie (RP)
# Michael Halstead (halstead)

== Proceedings ==

RAW notes shown in boxes like this
=> this is an action item
-> this is a desired thing

Introduce TSC

* Martin Jansa (jama)
* Mark Hatle (fray)
* Paul Eggleton (bluelightning)
* Richard Purdie (RP)
* Khem Raj (khem)

go over agenda
BSP topic first to accommodate member travel

=== BSPs & Layer Index ===

Paul described layer index process & how it works
BBP layers also come into toaster, expose to people, dependency list very important - snapshot when setting up toaster
module branches - will look in repo for branches
some layers don't have a master branch, don't show content - need way to present in UI
REST API
DD automatically parse layer to check for required content? PE do want, necessitates background queuing process
parse w/dependencies
also affects YP Compatible, RP's proposed layer validation tool
error reporting system - tie together with info in layer index, intention there
JH ability to register layer & specify quality
------------------------------------------
not getting resources to work on core BSPs
people working on own BSPs - not really a complaint, but an observation
SH would love to see REST APIs
PE would love some help with the layer index
RP love ideas, but people need to resource, step up & drive
------------------------------------------
=> oe driving toward machine readable files, can also drive from layer test (yp compat) side - KK
------------------------------------------
oe-core or oe-devel? oe-core
------------------------------------------
=> publicize defs of each list? discuss on members list - where to overall architecture discussions belong
discussion: decided on oe-core
oe needs its own goals, interact with the yocto project
------------------------------------------
status email to oe-core list, useful? to most people. cross-postd to yocto list
KK should be about oe-core, not about poky
=> TSC to add new mailing list specifically about project architecture, no patches, and determine list name
------------------------------------------
KK realize that OE has no project vision
RP is there any vision that needs to be represented to YP, and are there resources
KK as a project take an active role to work with YP
marketing/visibility standpoint, wear OE hat
if list of oe bugs that should be raised, bring to philip
-> KK bring discussion to new mailing list
------------------------------------------
TW can new layers use bugzilla
PE struggle with volume of bugs currently in triage process
RP triage process - yp has taken on oe-core eg. don't want many bugs from idle layers, YP judged on metrics from that system
SW some layers already in that state
DD attended call regularly
RP maintainers must be willing to come to triage process
some issues don't have a clear maintainer
------------------------------------------
BSP standards - standards exist,coming soon are methods for comparing a given layer with the standard
"oe has no rules, only half-documented best practices" - Koen
=> need wiki documentation for TSC to ratify
-> document distro vs. machine policies, other best practices
------------------------------------------
BSP layer availability
-> encourage board vendors to provide a BSP, make it easier to do so
people problem, not technical problem
add questionnaire about why people don't
ask LF to include a list of BSPs that are supported
=> ask yp ab to talk to linux.com [PB] - community issue
build for qemu, with limited resources
-> look at digi manual (i.e. "just add bsp changes in local.conf")
best practices : should be easy to use, instructions/tools to put it on a card, etc
wic incomplete but promising
------------------------------------------
touching variables - discuss on new arch list
------------------------------------------

=== Metadata ===

meta-yocto to meta-poky:

=> RP to take action on the YP side, possibly not for 2.0

override syntax

underscore character to designate overrides, underscore is overloaded
need better method
KK maybe _OVERRIDE_
dot character?
require all lowercase overrides? benefits for bitbake speed
=> formalize lowercase as mandatory requirement for overrides, look for other options in the future

=== Processes ===

Layer Index feature requests discussed with layer index
build feedback>>

Build/test failures on public autobuilder

problems:
RP
different failures "random" - actually is a pattern, but initially looks random
build poky and poky-lsb, lsb turns on different distro features
boots a machine in qemu & runs scripts, most qemu machines, just says "kill" - unknown
release blocker causing qa failures
also, systemd having timeout issues
should OE care about these things? (yes)
PE
set up environment to detect regressions
did upgrading qemu and systemd create these? get to a correct point
not poky changes or bsp changes
eg poky enables ptest, doesn't affect systemd timeout
RP
have massively increased scope of tests
ptests, sdk..
resources always an issue
-> ask for cycles from employers to work on these issues
-> make people aware, help with triage, provide resources
KK -> plan B, C, etc. have had this problem for years
more issues recently

=== Security ===

security a long term issue, beginning to be noticed - now reluctant to address it, as it is being noticed/resourced
if patch had standard cv, could write automated tools to parse
-> need a method for tracking CVs
MH have to have someone whose job it is to pull CV list, look for differences, assess applicability
Michael Halstead : LF can run security audits of individual tools
could do layer index, toaster, ... busybox
MH independent academic audit found OE very good

=== Systemd ===

currently scaling up
complaints: more package config, comments; look at packaging to have minimal systemd even with options available
-> need someone with time available to work on it
-> need to get systemd feedback, people using systemd talk to package maintainer
MH automotive is a heavy user, could ask genivi for help
peter, koen using systemd but not using official oe recipe - based on

Can we get systemd first boot support to work?
MH wind struggling on read-only filesystems

Easy setup "should work now"
yes can get it to work - talk to upstream
changing prefixes problematic
MH unitdir to /usr/lib - can't boot without base lib
should be able to boot minimal system w/shell and some commands
should work if reasonable default can be changed
patches are problematic - RP wants clear coherent vision

systemctl wrapper needs documentation for working with systemd
current docs targeted at app developers - not distro devs
want to use the install section
=> file systemctl wrapper bug

=== Advocacy ===

why aren't more projects using OE?
how can we get more people using OE?
who should we be targeting? build people, kernel devs, userspace devs

OEDEM 2015

2015-10-09T14:32:27Z

Twoerner: /* Agenda */

The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland. Part of this meeting will also constitute the annual OE General Assembly, and some corporation/eV matters will be discussed.

== Location and Time ==

[http://www.thegibsonhotel.ie/ The Gibson Hotel] 
Point Village 
Dublin 1, Ireland 
+353 1 681 5000

9am - 5pm (note: times may change)

Gibson Hotel is at the end of the red LUAS line, adjacent to the stadium. Come up to the 3rd floor and follow the signs for the Cordoba room. (the sign says "Mtg", that's us) There is coffee here. See you all soon

== OpenEmbedded eV General Assembly ==

We have a short administrative meeting before starting the Developer meeting. All are welcome for this.

* Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project.
* Define a method for identifying lapsed memberships.
* Proxy form [[File:Proxy_instructions-oe.pdf]]
* [http://www.openembedded.org/wiki/Dublin,_2015 Meeting Minutes]

== Agenda ==

* <s>Metadata</s>
** <s>OVERRIDE syntax: is it time to reconsider _?</s>
** <s>meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)</s>
** <s>variable expand = True by default</s>

* <s>BSPs (tlwoerner)</s>
** <s>Standards for BSP behavior. (Crofton)</s>
** <s>feedback on layerindex to indicate BSP:
*** last successful compile (feedback from outside builders?)
*** last successful boot
*** master branch parsability (perhaps ties into bugzilla 7792?)</s>
** <s>several BSP layers to choose from for some boards, none for others (linux.com SBC survey)</s>
** <s>guidelines/requirements for setting up a new BSP on layerindex
*** bugzilla
*** mailing list (use general mailing list(s) for patches?)
*** git.yoctoproject.org/<yourbsplayer></s>
** <s>making sure BSP layers only touch the variables/settings they should touch
*** should a BSP layer ever use = ?</s>
** <s>does/should a BSP produce artifacts that are easy to install to SD cards? (Crofton)</s>

*<s>Processes</s>
** <s>LayerIndex feature requests (tlwoerner)
** build feedback (autobuilders and off-site)
** Build and test failures on the public Autobuilder (Bluelightening)</s>

*Systemd
** <s>Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info)
** Can we get systemd's first-boot support to work? It is currently disabled in the systemd recipe by touching /etc/machine-id. (Saur)</s>
** How to make it easy to setup a system "the systemd way"? New DISTRO_FEATURE or IMAGE_FEATURE? (Saur)
*** <s>Link /bin -> /usr/bin, /lib -> /usr/lib, etc.</s>
*** <s>Change ${systemd_unitdir} to /usr/lib.</s>
*** Make the systemctl wrapper install in ${systemd_unitdir} rather than ${systemconf}/systemd.
**** This should also happen when installing a package in runtime.

*Advocacy
** There are still a lot of projects (too many?) not using OE (tlwoerner)
** why aren't more projects using OE?
** how can we get more people using OE?
** who should we be targeting? (build people (obviously), kernel devs? user-space devs?)

== Attendees ==

If you plan to attend, please list your name below.

# Jeff Osier-Mixon (jefro)
# Philip Balister (Crofton)
# Trevor Woerner (tlwoerner)
# Anders Darander (andersd)
# Marco Cavallini (mckoan)
# Koen Kooi (koen)
# Alexandre Belloni (abelloni)
# Armin Kuster (armpit)
# Belén Barros Pena (belen)
# Peter Kjellerstedt (Saur)
# Alejandro del Castillo (adelcast)
# Denys Dmytriyenko (denix)
# Sean Hudson (darknighte)
# Nathan Rossi (nrossi)
# Mark Hatle (fray)
# Nicolas Dechesne (ndec)
# Paul Eggleton (bluelightning)
# Andrei Gherzan (agherzan)
# Felipe F. Tonello (ftonello)
# Changhyeok Bae (chbae)
# Saul Wold (sgw)
# Ashish Shrivastava
# Pascal Bach (bachp)
# Richard Purdie (RP)
# Michael Halstead (halstead)

== Proceedings ==

RAW notes shown in boxes like this
=> this is an action item
-> this is a desired thing

Introduce TSC

* Martin Jansa (jama)
* Mark Hatle (fray)
* Paul Eggleton (bluelightning)
* Richard Purdie (RP)
* Khem Raj (khem)

go over agenda
BSP topic first to accommodate member travel

=== BSPs & Layer Index ===

Paul described layer index process & how it works
BBP layers also come into toaster, expose to people, dependency list very important - snapshot when setting up toaster
module branches - will look in repo for branches
some layers don't have a master branch, don't show content - need way to present in UI
REST API
DD automatically parse layer to check for required content? PE do want, necessitates background queuing process
parse w/dependencies
also affects YP Compatible, RP's proposed layer validation tool
error reporting system - tie together with info in layer index, intention there
JH ability to register layer & specify quality
------------------------------------------
not getting resources to work on core BSPs
people working on own BSPs - not really a complaint, but an observation
SH would love to see REST APIs
PE would love some help with the layer index
RP love ideas, but people need to resource, step up & drive
------------------------------------------
=> oe driving toward machine readable files, can also drive from layer test (yp compat) side - KK
------------------------------------------
oe-core or oe-devel? oe-core
------------------------------------------
=> publicize defs of each list? discuss on members list - where to overall architecture discussions belong
discussion: decided on oe-core
oe needs its own goals, interact with the yocto project
------------------------------------------
status email to oe-core list, useful? to most people. cross-postd to yocto list
KK should be about oe-core, not about poky
=> TSC to add new mailing list specifically about project architecture, no patches, and determine list name
------------------------------------------
KK realize that OE has no project vision
RP is there any vision that needs to be represented to YP, and are there resources
KK as a project take an active role to work with YP
marketing/visibility standpoint, wear OE hat
if list of oe bugs that should be raised, bring to philip
-> KK bring discussion to new mailing list
------------------------------------------
TW can new layers use bugzilla
PE struggle with volume of bugs currently in triage process
RP triage process - yp has taken on oe-core eg. don't want many bugs from idle layers, YP judged on metrics from that system
SW some layers already in that state
DD attended call regularly
RP maintainers must be willing to come to triage process
some issues don't have a clear maintainer
------------------------------------------
BSP standards - standards exist,coming soon are methods for comparing a given layer with the standard
"oe has no rules, only half-documented best practices" - Koen
=> need wiki documentation for TSC to ratify
-> document distro vs. machine policies, other best practices
------------------------------------------
BSP layer availability
-> encourage board vendors to provide a BSP, make it easier to do so
people problem, not technical problem
add questionnaire about why people don't
ask LF to include a list of BSPs that are supported
=> ask yp ab to talk to linux.com [PB] - community issue
build for qemu, with limited resources
-> look at digi manual (i.e. "just add bsp changes in local.conf")
best practices : should be easy to use, instructions/tools to put it on a card, etc
wic incomplete but promising
------------------------------------------
touching variables - discuss on new arch list
------------------------------------------

=== Metadata ===

meta-yocto to meta-poky:

=> RP to take action on the YP side, possibly not for 2.0

override syntax

underscore character to designate overrides, underscore is overloaded
need better method
KK maybe _OVERRIDE_
dot character?
require all lowercase overrides? benefits for bitbake speed
=> formalize lowercase as mandatory requirement for overrides, look for other options in the future

=== Processes ===

Layer Index feature requests discussed with layer index
build feedback>>

Build/test failures on public autobuilder

problems:
RP
different failures "random" - actually is a pattern, but initially looks random
build poky and poky-lsb, lsb turns on different distro features
boots a machine in qemu & runs scripts, most qemu machines, just says "kill" - unknown
release blocker causing qa failures
also, systemd having timeout issues
should OE care about these things? (yes)
PE
set up environment to detect regressions
did upgrading qemu and systemd create these? get to a correct point
not poky changes or bsp changes
eg poky enables ptest, doesn't affect systemd timeout
RP
have massively increased scope of tests
ptests, sdk..
resources always an issue
-> ask for cycles from employers to work on these issues
-> make people aware, help with triage, provide resources
KK -> plan B, C, etc. have had this problem for years
more issues recently

=== Security ===

security a long term issue, beginning to be noticed - now reluctant to address it, as it is being noticed/resourced
if patch had standard cv, could write automated tools to parse
-> need a method for tracking CVs
MH have to have someone whose job it is to pull CV list, look for differences, assess applicability
Michael Halstead : LF can run security audits of individual tools
could do layer index, toaster, ... busybox
MH independent academic audit found OE very good

=== Systemd ===

currently scaling up
complaints: more package config, comments; look at packaging to have minimal systemd even with options available
-> need someone with time available to work on it
-> need to get systemd feedback, people using systemd talk to package maintainer
MH automotive is a heavy user, could ask genivi for help
peter, koen using systemd but not using official oe recipe - based on

Can we get systemd first boot support to work?

MH wind struggling

=== Advocacy ===

why aren't more projects using OE?
how can we get more people using OE?
who should we be targeting? build people, kernel devs, userspace devs

OEDEM 2015

2015-10-09T14:31:34Z

Twoerner: /* Agenda */

The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland. Part of this meeting will also constitute the annual OE General Assembly, and some corporation/eV matters will be discussed.

== Location and Time ==

[http://www.thegibsonhotel.ie/ The Gibson Hotel] 
Point Village 
Dublin 1, Ireland 
+353 1 681 5000

9am - 5pm (note: times may change)

Gibson Hotel is at the end of the red LUAS line, adjacent to the stadium. Come up to the 3rd floor and follow the signs for the Cordoba room. (the sign says "Mtg", that's us) There is coffee here. See you all soon

== OpenEmbedded eV General Assembly ==

We have a short administrative meeting before starting the Developer meeting. All are welcome for this.

* Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project.
* Define a method for identifying lapsed memberships.
* Proxy form [[File:Proxy_instructions-oe.pdf]]
* [http://www.openembedded.org/wiki/Dublin,_2015 Meeting Minutes]

== Agenda ==

* <s>Metadata</s>
** <s>OVERRIDE syntax: is it time to reconsider _?</s>
** <s>meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)</s>
** <s>variable expand = True by default</s>

* <s>BSPs (tlwoerner)</s>
** <s>Standards for BSP behavior. (Crofton)</s>
** <s>feedback on layerindex to indicate BSP:
*** last successful compile (feedback from outside builders?)
*** last successful boot
*** master branch parsability (perhaps ties into bugzilla 7792?)</s>
** <s>several BSP layers to choose from for some boards, none for others (linux.com SBC survey)</s>
** <s>guidelines/requirements for setting up a new BSP on layerindex
*** bugzilla
*** mailing list (use general mailing list(s) for patches?)
*** git.yoctoproject.org/<yourbsplayer></s>
** <s>making sure BSP layers only touch the variables/settings they should touch
*** should a BSP layer ever use = ?</s>
** <s>does/should a BSP produce artifacts that are easy to install to SD cards? (Crofton)</s>

*<s>Processes</s>
** <s>LayerIndex feature requests (tlwoerner)
** build feedback (autobuilders and off-site)
** Build and test failures on the public Autobuilder (Bluelightening)</s>

*Systemd
** <s>Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info)
** Can we get systemd's first-boot support to work? It is currently disabled in the systemd recipe by touching /etc/machine-id. (Saur)</s>
** How to make it easy to setup a system "the systemd way"? New DISTRO_FEATURE or IMAGE_FEATURE? (Saur)
*** <s>Link /bin -> /usr/bin, /lib -> /usr/lib, etc.</s>
*** <s>Change ${systemd_unitdir} to /usr/lib.
*** Make the systemctl wrapper install in ${systemd_unitdir} rather than ${systemconf}/systemd.
**** This should also happen when installing a package in runtime.</s>

*Advocacy
** There are still a lot of projects (too many?) not using OE (tlwoerner)
** why aren't more projects using OE?
** how can we get more people using OE?
** who should we be targeting? (build people (obviously), kernel devs? user-space devs?)

== Attendees ==

If you plan to attend, please list your name below.

# Jeff Osier-Mixon (jefro)
# Philip Balister (Crofton)
# Trevor Woerner (tlwoerner)
# Anders Darander (andersd)
# Marco Cavallini (mckoan)
# Koen Kooi (koen)
# Alexandre Belloni (abelloni)
# Armin Kuster (armpit)
# Belén Barros Pena (belen)
# Peter Kjellerstedt (Saur)
# Alejandro del Castillo (adelcast)
# Denys Dmytriyenko (denix)
# Sean Hudson (darknighte)
# Nathan Rossi (nrossi)
# Mark Hatle (fray)
# Nicolas Dechesne (ndec)
# Paul Eggleton (bluelightning)
# Andrei Gherzan (agherzan)
# Felipe F. Tonello (ftonello)
# Changhyeok Bae (chbae)
# Saul Wold (sgw)
# Ashish Shrivastava
# Pascal Bach (bachp)
# Richard Purdie (RP)
# Michael Halstead (halstead)

== Proceedings ==

RAW notes shown in boxes like this
=> this is an action item
-> this is a desired thing

Introduce TSC

* Martin Jansa (jama)
* Mark Hatle (fray)
* Paul Eggleton (bluelightning)
* Richard Purdie (RP)
* Khem Raj (khem)

go over agenda
BSP topic first to accommodate member travel

=== BSPs & Layer Index ===

Paul described layer index process & how it works
BBP layers also come into toaster, expose to people, dependency list very important - snapshot when setting up toaster
module branches - will look in repo for branches
some layers don't have a master branch, don't show content - need way to present in UI
REST API
DD automatically parse layer to check for required content? PE do want, necessitates background queuing process
parse w/dependencies
also affects YP Compatible, RP's proposed layer validation tool
error reporting system - tie together with info in layer index, intention there
JH ability to register layer & specify quality
------------------------------------------
not getting resources to work on core BSPs
people working on own BSPs - not really a complaint, but an observation
SH would love to see REST APIs
PE would love some help with the layer index
RP love ideas, but people need to resource, step up & drive
------------------------------------------
=> oe driving toward machine readable files, can also drive from layer test (yp compat) side - KK
------------------------------------------
oe-core or oe-devel? oe-core
------------------------------------------
=> publicize defs of each list? discuss on members list - where to overall architecture discussions belong
discussion: decided on oe-core
oe needs its own goals, interact with the yocto project
------------------------------------------
status email to oe-core list, useful? to most people. cross-postd to yocto list
KK should be about oe-core, not about poky
=> TSC to add new mailing list specifically about project architecture, no patches, and determine list name
------------------------------------------
KK realize that OE has no project vision
RP is there any vision that needs to be represented to YP, and are there resources
KK as a project take an active role to work with YP
marketing/visibility standpoint, wear OE hat
if list of oe bugs that should be raised, bring to philip
-> KK bring discussion to new mailing list
------------------------------------------
TW can new layers use bugzilla
PE struggle with volume of bugs currently in triage process
RP triage process - yp has taken on oe-core eg. don't want many bugs from idle layers, YP judged on metrics from that system
SW some layers already in that state
DD attended call regularly
RP maintainers must be willing to come to triage process
some issues don't have a clear maintainer
------------------------------------------
BSP standards - standards exist,coming soon are methods for comparing a given layer with the standard
"oe has no rules, only half-documented best practices" - Koen
=> need wiki documentation for TSC to ratify
-> document distro vs. machine policies, other best practices
------------------------------------------
BSP layer availability
-> encourage board vendors to provide a BSP, make it easier to do so
people problem, not technical problem
add questionnaire about why people don't
ask LF to include a list of BSPs that are supported
=> ask yp ab to talk to linux.com [PB] - community issue
build for qemu, with limited resources
-> look at digi manual (i.e. "just add bsp changes in local.conf")
best practices : should be easy to use, instructions/tools to put it on a card, etc
wic incomplete but promising
------------------------------------------
touching variables - discuss on new arch list
------------------------------------------

=== Metadata ===

meta-yocto to meta-poky:

=> RP to take action on the YP side, possibly not for 2.0

override syntax

underscore character to designate overrides, underscore is overloaded
need better method
KK maybe _OVERRIDE_
dot character?
require all lowercase overrides? benefits for bitbake speed
=> formalize lowercase as mandatory requirement for overrides, look for other options in the future

=== Processes ===

Layer Index feature requests discussed with layer index
build feedback>>

Build/test failures on public autobuilder

problems:
RP
different failures "random" - actually is a pattern, but initially looks random
build poky and poky-lsb, lsb turns on different distro features
boots a machine in qemu & runs scripts, most qemu machines, just says "kill" - unknown
release blocker causing qa failures
also, systemd having timeout issues
should OE care about these things? (yes)
PE
set up environment to detect regressions
did upgrading qemu and systemd create these? get to a correct point
not poky changes or bsp changes
eg poky enables ptest, doesn't affect systemd timeout
RP
have massively increased scope of tests
ptests, sdk..
resources always an issue
-> ask for cycles from employers to work on these issues
-> make people aware, help with triage, provide resources
KK -> plan B, C, etc. have had this problem for years
more issues recently

=== Security ===

security a long term issue, beginning to be noticed - now reluctant to address it, as it is being noticed/resourced
if patch had standard cv, could write automated tools to parse
-> need a method for tracking CVs
MH have to have someone whose job it is to pull CV list, look for differences, assess applicability
Michael Halstead : LF can run security audits of individual tools
could do layer index, toaster, ... busybox
MH independent academic audit found OE very good

=== Systemd ===

currently scaling up
complaints: more package config, comments; look at packaging to have minimal systemd even with options available
-> need someone with time available to work on it
-> need to get systemd feedback, people using systemd talk to package maintainer
MH automotive is a heavy user, could ask genivi for help
peter, koen using systemd but not using official oe recipe - based on

Can we get systemd first boot support to work?

MH wind struggling

=== Advocacy ===

why aren't more projects using OE?
how can we get more people using OE?
who should we be targeting? build people, kernel devs, userspace devs

OEDEM 2015

2015-10-09T14:30:34Z

Twoerner: /* Agenda */

The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland. Part of this meeting will also constitute the annual OE General Assembly, and some corporation/eV matters will be discussed.

== Location and Time ==

[http://www.thegibsonhotel.ie/ The Gibson Hotel] 
Point Village 
Dublin 1, Ireland 
+353 1 681 5000

9am - 5pm (note: times may change)

Gibson Hotel is at the end of the red LUAS line, adjacent to the stadium. Come up to the 3rd floor and follow the signs for the Cordoba room. (the sign says "Mtg", that's us) There is coffee here. See you all soon

== OpenEmbedded eV General Assembly ==

We have a short administrative meeting before starting the Developer meeting. All are welcome for this.

* Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project.
* Define a method for identifying lapsed memberships.
* Proxy form [[File:Proxy_instructions-oe.pdf]]
* [http://www.openembedded.org/wiki/Dublin,_2015 Meeting Minutes]

== Agenda ==

* <s>Metadata</s>
** <s>OVERRIDE syntax: is it time to reconsider _?</s>
** <s>meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)</s>
** <s>variable expand = True by default</s>

* <s>BSPs (tlwoerner)</s>
** <s>Standards for BSP behavior. (Crofton)</s>
** <s>feedback on layerindex to indicate BSP:
*** last successful compile (feedback from outside builders?)
*** last successful boot
*** master branch parsability (perhaps ties into bugzilla 7792?)</s>
** <s>several BSP layers to choose from for some boards, none for others (linux.com SBC survey)</s>
** <s>guidelines/requirements for setting up a new BSP on layerindex
*** bugzilla
*** mailing list (use general mailing list(s) for patches?)
*** git.yoctoproject.org/<yourbsplayer></s>
** <s>making sure BSP layers only touch the variables/settings they should touch
*** should a BSP layer ever use = ?</s>
** <s>does/should a BSP produce artifacts that are easy to install to SD cards? (Crofton)</s>

*<s>Processes</s>
** <s>LayerIndex feature requests (tlwoerner)
** build feedback (autobuilders and off-site)
** Build and test failures on the public Autobuilder (Bluelightening)</s>

*Systemd
** <s>Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info)
** Can we get systemd's first-boot support to work? It is currently disabled in the systemd recipe by touching /etc/machine-id. (Saur)</s>
** How to make it easy to setup a system "the systemd way"? New DISTRO_FEATURE or IMAGE_FEATURE? (Saur)
*** <s>Link /bin -> /usr/bin, /lib -> /usr/lib, etc.</s>
*** <s>Change ${systemd_unitdir} to /usr/lib.</s>
*** Make the systemctl wrapper install in ${systemd_unitdir} rather than ${systemconf}/systemd.
**** This should also happen when installing a package in runtime.

*Advocacy
** There are still a lot of projects (too many?) not using OE (tlwoerner)
** why aren't more projects using OE?
** how can we get more people using OE?
** who should we be targeting? (build people (obviously), kernel devs? user-space devs?)

== Attendees ==

If you plan to attend, please list your name below.

# Jeff Osier-Mixon (jefro)
# Philip Balister (Crofton)
# Trevor Woerner (tlwoerner)
# Anders Darander (andersd)
# Marco Cavallini (mckoan)
# Koen Kooi (koen)
# Alexandre Belloni (abelloni)
# Armin Kuster (armpit)
# Belén Barros Pena (belen)
# Peter Kjellerstedt (Saur)
# Alejandro del Castillo (adelcast)
# Denys Dmytriyenko (denix)
# Sean Hudson (darknighte)
# Nathan Rossi (nrossi)
# Mark Hatle (fray)
# Nicolas Dechesne (ndec)
# Paul Eggleton (bluelightning)
# Andrei Gherzan (agherzan)
# Felipe F. Tonello (ftonello)
# Changhyeok Bae (chbae)
# Saul Wold (sgw)
# Ashish Shrivastava
# Pascal Bach (bachp)
# Richard Purdie (RP)
# Michael Halstead (halstead)

== Proceedings ==

RAW notes shown in boxes like this
=> this is an action item
-> this is a desired thing

Introduce TSC

* Martin Jansa (jama)
* Mark Hatle (fray)
* Paul Eggleton (bluelightning)
* Richard Purdie (RP)
* Khem Raj (khem)

go over agenda
BSP topic first to accommodate member travel

=== BSPs & Layer Index ===

Paul described layer index process & how it works
BBP layers also come into toaster, expose to people, dependency list very important - snapshot when setting up toaster
module branches - will look in repo for branches
some layers don't have a master branch, don't show content - need way to present in UI
REST API
DD automatically parse layer to check for required content? PE do want, necessitates background queuing process
parse w/dependencies
also affects YP Compatible, RP's proposed layer validation tool
error reporting system - tie together with info in layer index, intention there
JH ability to register layer & specify quality
------------------------------------------
not getting resources to work on core BSPs
people working on own BSPs - not really a complaint, but an observation
SH would love to see REST APIs
PE would love some help with the layer index
RP love ideas, but people need to resource, step up & drive
------------------------------------------
=> oe driving toward machine readable files, can also drive from layer test (yp compat) side - KK
------------------------------------------
oe-core or oe-devel? oe-core
------------------------------------------
=> publicize defs of each list? discuss on members list - where to overall architecture discussions belong
discussion: decided on oe-core
oe needs its own goals, interact with the yocto project
------------------------------------------
status email to oe-core list, useful? to most people. cross-postd to yocto list
KK should be about oe-core, not about poky
=> TSC to add new mailing list specifically about project architecture, no patches, and determine list name
------------------------------------------
KK realize that OE has no project vision
RP is there any vision that needs to be represented to YP, and are there resources
KK as a project take an active role to work with YP
marketing/visibility standpoint, wear OE hat
if list of oe bugs that should be raised, bring to philip
-> KK bring discussion to new mailing list
------------------------------------------
TW can new layers use bugzilla
PE struggle with volume of bugs currently in triage process
RP triage process - yp has taken on oe-core eg. don't want many bugs from idle layers, YP judged on metrics from that system
SW some layers already in that state
DD attended call regularly
RP maintainers must be willing to come to triage process
some issues don't have a clear maintainer
------------------------------------------
BSP standards - standards exist,coming soon are methods for comparing a given layer with the standard
"oe has no rules, only half-documented best practices" - Koen
=> need wiki documentation for TSC to ratify
-> document distro vs. machine policies, other best practices
------------------------------------------
BSP layer availability
-> encourage board vendors to provide a BSP, make it easier to do so
people problem, not technical problem
add questionnaire about why people don't
ask LF to include a list of BSPs that are supported
=> ask yp ab to talk to linux.com [PB] - community issue
build for qemu, with limited resources
-> look at digi manual (i.e. "just add bsp changes in local.conf")
best practices : should be easy to use, instructions/tools to put it on a card, etc
wic incomplete but promising
------------------------------------------
touching variables - discuss on new arch list
------------------------------------------

=== Metadata ===

meta-yocto to meta-poky:

=> RP to take action on the YP side, possibly not for 2.0

override syntax

underscore character to designate overrides, underscore is overloaded
need better method
KK maybe _OVERRIDE_
dot character?
require all lowercase overrides? benefits for bitbake speed
=> formalize lowercase as mandatory requirement for overrides, look for other options in the future

=== Processes ===

Layer Index feature requests discussed with layer index
build feedback>>

Build/test failures on public autobuilder

problems:
RP
different failures "random" - actually is a pattern, but initially looks random
build poky and poky-lsb, lsb turns on different distro features
boots a machine in qemu & runs scripts, most qemu machines, just says "kill" - unknown
release blocker causing qa failures
also, systemd having timeout issues
should OE care about these things? (yes)
PE
set up environment to detect regressions
did upgrading qemu and systemd create these? get to a correct point
not poky changes or bsp changes
eg poky enables ptest, doesn't affect systemd timeout
RP
have massively increased scope of tests
ptests, sdk..
resources always an issue
-> ask for cycles from employers to work on these issues
-> make people aware, help with triage, provide resources
KK -> plan B, C, etc. have had this problem for years
more issues recently

=== Security ===

security a long term issue, beginning to be noticed - now reluctant to address it, as it is being noticed/resourced
if patch had standard cv, could write automated tools to parse
-> need a method for tracking CVs
MH have to have someone whose job it is to pull CV list, look for differences, assess applicability
Michael Halstead : LF can run security audits of individual tools
could do layer index, toaster, ... busybox
MH independent academic audit found OE very good

=== Systemd ===

currently scaling up
complaints: more package config, comments; look at packaging to have minimal systemd even with options available
-> need someone with time available to work on it
-> need to get systemd feedback, people using systemd talk to package maintainer
MH automotive is a heavy user, could ask genivi for help
peter, koen using systemd but not using official oe recipe - based on

Can we get systemd first boot support to work?

MH wind struggling

=== Advocacy ===

why aren't more projects using OE?
how can we get more people using OE?
who should we be targeting? build people, kernel devs, userspace devs

OEDEM 2015

2015-10-09T14:26:48Z

Twoerner: /* Agenda */

The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland. Part of this meeting will also constitute the annual OE General Assembly, and some corporation/eV matters will be discussed.

== Location and Time ==

[http://www.thegibsonhotel.ie/ The Gibson Hotel] 
Point Village 
Dublin 1, Ireland 
+353 1 681 5000

9am - 5pm (note: times may change)

Gibson Hotel is at the end of the red LUAS line, adjacent to the stadium. Come up to the 3rd floor and follow the signs for the Cordoba room. (the sign says "Mtg", that's us) There is coffee here. See you all soon

== OpenEmbedded eV General Assembly ==

We have a short administrative meeting before starting the Developer meeting. All are welcome for this.

* Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project.
* Define a method for identifying lapsed memberships.
* Proxy form [[File:Proxy_instructions-oe.pdf]]
* [http://www.openembedded.org/wiki/Dublin,_2015 Meeting Minutes]

== Agenda ==

* <s>Metadata</s>
** <s>OVERRIDE syntax: is it time to reconsider _?</s>
** <s>meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)</s>
** <s>variable expand = True by default</s>

* <s>BSPs (tlwoerner)</s>
** <s>Standards for BSP behavior. (Crofton)</s>
** <s>feedback on layerindex to indicate BSP:
*** last successful compile (feedback from outside builders?)
*** last successful boot
*** master branch parsability (perhaps ties into bugzilla 7792?)</s>
** <s>several BSP layers to choose from for some boards, none for others (linux.com SBC survey)</s>
** <s>guidelines/requirements for setting up a new BSP on layerindex
*** bugzilla
*** mailing list (use general mailing list(s) for patches?)
*** git.yoctoproject.org/<yourbsplayer></s>
** <s>making sure BSP layers only touch the variables/settings they should touch
*** should a BSP layer ever use = ?</s>
** <s>does/should a BSP produce artifacts that are easy to install to SD cards? (Crofton)</s>

*<s>Processes</s>
** <s>LayerIndex feature requests (tlwoerner)
** build feedback (autobuilders and off-site)
** Build and test failures on the public Autobuilder (Bluelightening)</s>

*Systemd
** <s>Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info)
** Can we get systemd's first-boot support to work? It is currently disabled in the systemd recipe by touching /etc/machine-id. (Saur)</s>
** How to make it easy to setup a system "the systemd way"? New DISTRO_FEATURE or IMAGE_FEATURE? (Saur)
*** <s>Link /bin -> /usr/bin, /lib -> /usr/lib, etc.</s>
*** Change ${systemd_unitdir} to /usr/lib.
*** Make the systemctl wrapper install in ${systemd_unitdir} rather than ${systemconf}/systemd.
**** This should also happen when installing a package in runtime.

*Advocacy
** There are still a lot of projects (too many?) not using OE (tlwoerner)
** why aren't more projects using OE?
** how can we get more people using OE?
** who should we be targeting? (build people (obviously), kernel devs? user-space devs?)

== Attendees ==

If you plan to attend, please list your name below.

# Jeff Osier-Mixon (jefro)
# Philip Balister (Crofton)
# Trevor Woerner (tlwoerner)
# Anders Darander (andersd)
# Marco Cavallini (mckoan)
# Koen Kooi (koen)
# Alexandre Belloni (abelloni)
# Armin Kuster (armpit)
# Belén Barros Pena (belen)
# Peter Kjellerstedt (Saur)
# Alejandro del Castillo (adelcast)
# Denys Dmytriyenko (denix)
# Sean Hudson (darknighte)
# Nathan Rossi (nrossi)
# Mark Hatle (fray)
# Nicolas Dechesne (ndec)
# Paul Eggleton (bluelightning)
# Andrei Gherzan (agherzan)
# Felipe F. Tonello (ftonello)
# Changhyeok Bae (chbae)
# Saul Wold (sgw)
# Ashish Shrivastava
# Pascal Bach (bachp)
# Richard Purdie (RP)
# Michael Halstead (halstead)

== Proceedings ==

RAW notes shown in boxes like this
=> this is an action item
-> this is a desired thing

Introduce TSC

* Martin Jansa (jama)
* Mark Hatle (fray)
* Paul Eggleton (bluelightning)
* Richard Purdie (RP)
* Khem Raj (khem)

go over agenda
BSP topic first to accommodate member travel

=== BSPs & Layer Index ===

Paul described layer index process & how it works
BBP layers also come into toaster, expose to people, dependency list very important - snapshot when setting up toaster
module branches - will look in repo for branches
some layers don't have a master branch, don't show content - need way to present in UI
REST API
DD automatically parse layer to check for required content? PE do want, necessitates background queuing process
parse w/dependencies
also affects YP Compatible, RP's proposed layer validation tool
error reporting system - tie together with info in layer index, intention there
JH ability to register layer & specify quality
------------------------------------------
not getting resources to work on core BSPs
people working on own BSPs - not really a complaint, but an observation
SH would love to see REST APIs
PE would love some help with the layer index
RP love ideas, but people need to resource, step up & drive
------------------------------------------
=> oe driving toward machine readable files, can also drive from layer test (yp compat) side - KK
------------------------------------------
oe-core or oe-devel? oe-core
------------------------------------------
=> publicize defs of each list? discuss on members list - where to overall architecture discussions belong
discussion: decided on oe-core
oe needs its own goals, interact with the yocto project
------------------------------------------
status email to oe-core list, useful? to most people. cross-postd to yocto list
KK should be about oe-core, not about poky
=> TSC to add new mailing list specifically about project architecture, no patches, and determine list name
------------------------------------------
KK realize that OE has no project vision
RP is there any vision that needs to be represented to YP, and are there resources
KK as a project take an active role to work with YP
marketing/visibility standpoint, wear OE hat
if list of oe bugs that should be raised, bring to philip
-> KK bring discussion to new mailing list
------------------------------------------
TW can new layers use bugzilla
PE struggle with volume of bugs currently in triage process
RP triage process - yp has taken on oe-core eg. don't want many bugs from idle layers, YP judged on metrics from that system
SW some layers already in that state
DD attended call regularly
RP maintainers must be willing to come to triage process
some issues don't have a clear maintainer
------------------------------------------
BSP standards - standards exist,coming soon are methods for comparing a given layer with the standard
"oe has no rules, only half-documented best practices" - Koen
=> need wiki documentation for TSC to ratify
-> document distro vs. machine policies, other best practices
------------------------------------------
BSP layer availability
-> encourage board vendors to provide a BSP, make it easier to do so
people problem, not technical problem
add questionnaire about why people don't
ask LF to include a list of BSPs that are supported
=> ask yp ab to talk to linux.com [PB] - community issue
build for qemu, with limited resources
-> look at digi manual (i.e. "just add bsp changes in local.conf")
best practices : should be easy to use, instructions/tools to put it on a card, etc
wic incomplete but promising
------------------------------------------
touching variables - discuss on new arch list
------------------------------------------

=== Metadata ===

meta-yocto to meta-poky:

=> RP to take action on the YP side, possibly not for 2.0

override syntax

underscore character to designate overrides, underscore is overloaded
need better method
KK maybe _OVERRIDE_
dot character?
require all lowercase overrides? benefits for bitbake speed
=> formalize lowercase as mandatory requirement for overrides, look for other options in the future

=== Processes ===

Layer Index feature requests discussed with layer index
build feedback>>

Build/test failures on public autobuilder

problems:
RP
different failures "random" - actually is a pattern, but initially looks random
build poky and poky-lsb, lsb turns on different distro features
boots a machine in qemu & runs scripts, most qemu machines, just says "kill" - unknown
release blocker causing qa failures
also, systemd having timeout issues
should OE care about these things? (yes)
PE
set up environment to detect regressions
did upgrading qemu and systemd create these? get to a correct point
not poky changes or bsp changes
eg poky enables ptest, doesn't affect systemd timeout
RP
have massively increased scope of tests
ptests, sdk..
resources always an issue
-> ask for cycles from employers to work on these issues
-> make people aware, help with triage, provide resources
KK -> plan B, C, etc. have had this problem for years
more issues recently

=== Security ===

security a long term issue, beginning to be noticed - now reluctant to address it, as it is being noticed/resourced
if patch had standard cv, could write automated tools to parse
-> need a method for tracking CVs
MH have to have someone whose job it is to pull CV list, look for differences, assess applicability
Michael Halstead : LF can run security audits of individual tools
could do layer index, toaster, ... busybox
MH independent academic audit found OE very good

=== Systemd ===

currently scaling up
complaints: more package config, comments; look at packaging to have minimal systemd even with options available
-> need someone with time available to work on it
-> need to get systemd feedback, people using systemd talk to package maintainer
MH automotive is a heavy user, could ask genivi for help
peter, koen using systemd but not using official oe recipe - based on

Can we get systemd first boot support to work?

MH wind struggling

=== Advocacy ===

why aren't more projects using OE?
how can we get more people using OE?
who should we be targeting? build people, kernel devs, userspace devs