https://www.openembedded.org/api.php?action=feedcontributions&user=Rpurdie&feedformat=atomOpenembedded.org - User contributions [en]2024-03-19T10:19:05ZUser contributionsMediaWiki 1.29.0https://www.openembedded.org/index.php?title=OpenEmbedded_and_The_Yocto_Project&diff=11214OpenEmbedded and The Yocto Project2024-03-18T22:06:11Z<p>Rpurdie: </p>
<hr />
<div>The relationship between OpenEmbedded and the Yocto Project confuses many people. If you have questions, mail them to <code>board@openembedded.org</code> and we will try to add answers here.<br />
<br />
==OpenEmbedded Overview==<br />
<br />
OpenEmbedded is community driven Open Source project. Individuals are not required to be a member to contribute to the project, but is highly encouraged and recommended if you want to help steer the direction of the project or serve on any of the various boards (e.g. the Technical Steering Committee). The project owns the OpenEmbedded Core layer, meta-openembedded which provides additional community maintained recipes, the bitbake build tool, and in general any git project hosted on https://git.openembedded.org. Project discussion and discourse is primarily done on public mailing lists, and most meetings are open for anyone to join. OpenEmbedded general holds a few meetings a year for developers to discuss topics of relevance to the project.<br />
<br />
OpenEmbedded accepts donations to keep the light on and the servers running, with the financial services provided by [https://spi-inc.org Software in the Public Interest] (which helps many other Open Source projects).<br />
<br />
==Yocto Project Overview==<br />
<br />
The Yocto Project is a [https://www.linuxfoundation.org/ Linux Foundation] project which primarily provides resources to help encourage and sustain development of Embedded systems using OpenEmbedded. The Yocto Project consumes from and contributes back to OpenEmbedded Core and bitbake from OpenEmbedded, in addition to owning and maintaining it's own additional layers and codebases such as poky. The Yocto Project provides funding for full and part time staff to work on the project, server infrastructure to perform automated testing (the AutoBuilder), web hosting for the project website and project documentation, manages the release schedule, and provides the Poky reference distribution as a stable testing target (which is necessary due to the large amount of configuration and customization allowed in OpenEmbedded).<br />
<br />
Membership in the Yocto Project is primarily focused on companies or organizations that are involved in the Linux Embedded Ecosystem. Membership is through the Linux Foundation, and generally requires the paying of membership fees. These fees are used to pay for the resources listed above. <br />
<br />
OpenEmbedded is a member organization of the Yocto Project and elects representatives from its own members.<br />
<br />
==FAQ==<br />
<br />
===Am I contributing to Yocto Project, or OpenEmbedded?===<br />
<br />
In general, if you are committing to a repo on https://git.openembedded.org/, that is directly contributing to the OpenEmbedded. This could also be considered indirectly contributing to the Yocto Project also, since it consumes many of the repositories provided by OpenEmbedded.<br />
<br />
If you are contributing to a repo on https://git.yoctoproject.org/, that is most likely a contribution to the Yocto Project, although be aware that the popular poky repo is an amalgamation of some OpenEmbedded repos and some Yocto Project repos into one juicy git tree, so in there it will likely depend on which directory you are looking at :)<br />
<br />
The other way that can help to differentiate is to look at the mailing list where patches are sent: OpenEmbedded projects will typically use a mailing lists on lists.openembedded.org whereas Yocto Project uses mailing lists on lists.yoctoproject.org<br />
<br />
===Is Person ''X'' Working with Yocto Project or OpenEmbedded?===<br />
<br />
It can sometimes be confusing as to which project a given person is working with/for. The reason for this is actually simpler than it might seem at first: Many of the developers on the project are passionate about Embedded Linux and thus have (as individuals) joined OpenEmbedded. In addition, since their passion is Embedded Linux, they tend to gravitate toward Embedded Linux careers, and the companies that provide those are sometimes members of (or even just involved with) the Yocto Project. This means you may frequently encounter the same people in both project contexts.<br />
<br />
===Why two organizations?===<br />
<br />
There is a lot of history behind this but it amounts to needing decision making processes both for developer/community interests and also having decision making processes which can work for business/commercial interests. OpenEmbedded is the organization representing the developers and community who created the OpenEmbedded build system. Without it, it would be hard to quantify and represent the developer community which supports the open source project. Yocto Project membership is the other half of this equation and the two balance and work together symbiotically. <br />
<br />
While OpenEmbedded and the Yocto Project are distinct entities, and each runs their domains differently, it is important to note that ''both'' have the same goal of advancing and enabling Embedded Linux, and both benefit from each other in a symbiotic relationship.</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDvM_2023.12&diff=11183OEDvM 2023.122023-11-30T14:48:40Z<p>Rpurdie: </p>
<hr />
<div>==Location and Time==<br />
<br />
Held after the [https://summit.yoctoproject.org/yocto-project-summit-2023-11/ Yocto Project Summit ], the OE Developers Meeting is scheduled for Friday, December 1st 2023 between 12:00 and 20:00 UTC. Exact times for each individual topic are found below in the schedule.<br />
<br />
The meeting is held on Zoom https://zoom.us/j/99151508871 (Meeting ID: 991 5150 8871). We thank Automotive Grade Linux for providing!<br />
<br />
==Format==<br />
<br />
As always, we will collect topics on the wiki at<br />
https://www.openembedded.org/wiki/OEDvM_2023.12.<br />
<br />
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.<br />
<br />
==Topic Ideas==<br />
<br />
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.<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
! Notes<br />
|-<br />
<br />
| Data store operation changes <br />
| ? <br />
| ?<br />
| Pending developers spending time working on this.<br />
|-<br />
<br />
| Syntax removal <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Data store internal rewrite <br />
| ? <br />
| ?<br />
| Pending developers spending time working on this.<br />
|-<br />
<br />
| f-string in Python code (and more modern python in general) <br />
| ?<br />
| ?<br />
| Have upgraded python versions, still not convinced this has huge advantages. Don't want mass conversion as makes LTS patches harder.<br />
|-<br />
<br />
| Dropping core features <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Security (PSiRT) <br />
| ? <br />
| ?<br />
| Nobody willing to commit to joining a team. Security processes documented.<br />
|-<br />
<br />
<br />
| QA Automation <br />
| ? <br />
| ?<br />
| Now have significant automation on the autobuilder<br />
|-<br />
<br />
| Code submission process <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Software updates <br />
| ?<br />
| ?<br />
| Think we're happy that there are various layers/tools allowing this?<br />
|-<br />
<br />
| AI/ML <br />
| ? <br />
| ?<br />
|-<br />
|}<br />
<br />
Here are some new topic ideas:<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
|-<br />
<br />
<br />
| How to plan out ideas/new features/development in a way we can seek people to work on/fund things<br />
| ? <br />
| ?<br />
|-<br />
<br />
| Feedback on recent development topic areas<br />
| ? <br />
| ?<br />
|-<br />
<br />
<br />
|}</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDvM_2023.12&diff=11182OEDvM 2023.122023-11-30T14:47:42Z<p>Rpurdie: /* Topic Ideas */</p>
<hr />
<div>==Location and Time==<br />
<br />
Held after the [https://summit.yoctoproject.org/yocto-project-summit-2023-11/ Yocto Project Summit ], the OE Developers Meeting is scheduled for Friday, December 1st 2023 between 12:00 and 20:00 UTC. Exact times for each individual topic are found below in the schedule.<br />
<br />
The meeting is held on Zoom https://zoom.us/j/99151508871 (Meeting ID: 991 5150 8871). We thank Automotive Grade Linux for providing!<br />
<br />
==Format==<br />
<br />
As always, we will collect topics on the wiki at<br />
https://www.openembedded.org/wiki/OEDvM_2023.12.<br />
<br />
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.<br />
<br />
==Topic Ideas==<br />
<br />
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.<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
! Notes<br />
|-<br />
<br />
| Data store operation changes <br />
| ? <br />
| ?<br />
| Pending developers spending time working on this.<br />
|-<br />
<br />
| Syntax removal <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Data store internal rewrite <br />
| ? <br />
| ?<br />
| Pending developers spending time working on this.<br />
|-<br />
<br />
| f-string in Python code (and more modern python in general) <br />
| ?<br />
| ?<br />
| Have upgraded python versions, still not convinced this has huge advantages. Don't want mass conversion as makes LTS patches harder.<br />
|-<br />
<br />
| Dropping core features <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Security (PSiRT) <br />
| ? <br />
| ?<br />
| Nobody willing to commit to joining a team. Security processes documented.<br />
|-<br />
<br />
<br />
| QA Automation <br />
| ? <br />
| ?<br />
| Now have significant automation on the autobuilder<br />
|-<br />
<br />
| Code submission process <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Software updates <br />
| ?<br />
| ?<br />
| Think we're happy that there are various layers/tools allowing this?<br />
|-<br />
<br />
| AI/ML <br />
| ? <br />
| ?<br />
|-<br />
|}<br />
<br />
Here are some new topic ideas:<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
|-<br />
<br />
<br />
| How to plan out ideas/new features/development in a way we can seek people to work on/fund things<br />
| ? <br />
| ?<br />
|-<br />
<br />
|}</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDvM_2023.12&diff=11181OEDvM 2023.122023-11-30T14:46:29Z<p>Rpurdie: </p>
<hr />
<div>==Location and Time==<br />
<br />
Held after the [https://summit.yoctoproject.org/yocto-project-summit-2023-11/ Yocto Project Summit ], the OE Developers Meeting is scheduled for Friday, December 1st 2023 between 12:00 and 20:00 UTC. Exact times for each individual topic are found below in the schedule.<br />
<br />
The meeting is held on Zoom https://zoom.us/j/99151508871 (Meeting ID: 991 5150 8871). We thank Automotive Grade Linux for providing!<br />
<br />
==Format==<br />
<br />
As always, we will collect topics on the wiki at<br />
https://www.openembedded.org/wiki/OEDvM_2023.12.<br />
<br />
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.<br />
<br />
==Topic Ideas==<br />
<br />
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.<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
! Notes<br />
|-<br />
<br />
| Data store operation changes <br />
| ? <br />
| ?<br />
| Pending developers spending time working on this.<br />
|-<br />
<br />
| Syntax removal <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Data store internal rewrite <br />
| ? <br />
| ?<br />
| Pending developers spending time working on this.<br />
|-<br />
<br />
| f-string in Python code (and more modern python in general) <br />
| ?<br />
| ?<br />
| Have upgraded python versions, still not convinced this has huge advantages. Don't want mass conversion as makes LTS patches harder.<br />
|-<br />
<br />
| Dropping core features <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Security (PSiRT) <br />
| ? <br />
| ?<br />
| Nobody willing to commit to joining a team. Security processes documented.<br />
|-<br />
<br />
<br />
| QA Automation <br />
| ? <br />
| ?<br />
| Now have significant automation on the autobuilder<br />
|-<br />
<br />
| Code submission process <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Software updates <br />
| ?<br />
| ?<br />
| Think we're happy that there are various layers/tools allowing this?<br />
|-<br />
<br />
| AI/ML <br />
| ? <br />
| ?<br />
|-<br />
|}<br />
<br />
Here are some new topic ideas:<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
|-<br />
<br />
<br />
| ?<br />
| ? <br />
| ?<br />
|-<br />
<br />
|}</div>Rpurdiehttps://www.openembedded.org/index.php?title=Document_Consolidation&diff=11111Document Consolidation2023-04-17T22:03:55Z<p>Rpurdie: </p>
<hr />
<div>This page lists the various sources of user documentation that should be consolidated into the Yocto Project User Manual<br />
<br />
When a page has been consolidated, redirect it to the YP docs and cross it off the list (but please keep it in the list for posterity)<br />
<br />
* https://www.openembedded.org/wiki/Styleguide<br />
* https://www.openembedded.org/wiki/Getting_started<br />
* http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded<br />
* https://wiki.yoctoproject.org/wiki/Poky_Contributions<br />
* https://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-change-to-the-yocto-project<br />
* https://git.yoctoproject.org/meta-yocto/tree/meta-poky/README.poky.md<br />
* https://git.openembedded.org/bitbake/tree/README<br />
* https://git.openembedded.org/openembedded-core/tree/README.OE-Core.md</div>Rpurdiehttps://www.openembedded.org/index.php?title=Document_Consolidation&diff=11110Document Consolidation2023-04-17T22:03:28Z<p>Rpurdie: </p>
<hr />
<div>This page lists the various sources of user documentation that should be consolidated into the Yocto Project User Manual<br />
<br />
When a page has been consolidated, redirect it to the YP docs and cross it off the list (but please keep it in the list for posterity)<br />
<br />
* https://www.openembedded.org/wiki/Styleguide<br />
* https://www.openembedded.org/wiki/Getting_started<br />
* http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded<br />
* https://wiki.yoctoproject.org/wiki/Poky_Contributions<br />
* https://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-change-to-the-yocto-project<br />
* https://git.yoctoproject.org/meta-yocto/tree/meta-poky/README.poky.md<br />
* https://git.openembedded.org/bitbake/tree/README</div>Rpurdiehttps://www.openembedded.org/index.php?title=Document_Consolidation&diff=11109Document Consolidation2023-04-17T22:02:46Z<p>Rpurdie: </p>
<hr />
<div>This page lists the various sources of user documentation that should be consolidated into the Yocto Project User Manual<br />
<br />
When a page has been consolidated, redirect it to the YP docs and cross it off the list (but please keep it in the list for posterity)<br />
<br />
* https://www.openembedded.org/wiki/Styleguide<br />
* https://www.openembedded.org/wiki/Getting_started<br />
* http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded<br />
* https://wiki.yoctoproject.org/wiki/Poky_Contributions<br />
* https://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-change-to-the-yocto-project<br />
* https://git.yoctoproject.org/meta-yocto/tree/meta-poky/README.poky.md</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDVM_2022_05&diff=11017OEDVM 2022 052022-05-20T12:05:55Z<p>Rpurdie: </p>
<hr />
<div>==Location and Time==<br />
<br />
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.<br />
<br />
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!<br />
<br />
==Format==<br />
<br />
As always, we will collect topics on the wiki at<br />
https://wiki.openembedded.org/OEDVM_2022_05.<br />
<br />
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.<br />
<br />
==Topic Ideas==<br />
<br />
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.<br />
<br />
Actual schedule<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Time in UTC (Start is 1200 UTC/0800 EDT)<br />
! Notes<br />
|-<br />
| Introduction <br />
| OE Board<br />
| 1200<br />
|-<br />
| Future of eSDK (inc. bblock/bbunlock commands)<br />
| ? <br />
| 1215<br />
| https://lists.openembedded.org/g/openembedded-architecture/topic/thoughts_on_the_esdk/90990557<br />
|-<br />
| Copyright in OE-Core files<br />
| ? <br />
| 1300<br />
| https://lists.openembedded.org/g/openembedded-architecture/topic/oe_core_copyright_notices/91159593<br />
|-<br />
| layer.conf changes <br />
| ? <br />
| 1330<br />
|-<br />
| Kernel config RFC<br />
| Trevor Woerner <br />
| 1400<br />
|-<br />
<br />
| Layer Setup Configuration<br />
| Joshua Watt<br />
| 1430<br />
|-<br />
<br />
| Bitbake & OE "Core improvements"<br />
| Joshua Watt<br />
| 1500<br />
|-<br />
<br />
| Multiple SBOM formats, both in and out<br />
| Peter Kjellerstedt<br />
| 1530<br />
|-<br />
<br />
| Layerindex: quality, tooling, enhancements<br />
| Jan-Simon Möller, Tim Orling<br />
| 1550<br />
|-<br />
<br />
| Airing of Grievances<br />
| OpenEmbedded Board<br />
| 1610 (After all other topics covered)<br />
|-<br />
<br />
|}<br />
<br />
<br />
<br />
Unassigned ideas for next time<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
! Notes<br />
|-<br />
<br />
| Data store operation changes <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Syntax removal <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Data store internal rewrite <br />
| ? <br />
| ?<br />
|-<br />
<br />
| f-string in Python code (and more modern python in general) <br />
| Ross Burton, Tim Orling <br />
| ?<br />
|-<br />
<br />
| Merging optional functionality to make it mandatory <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Dropping core features <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Security (PSiRT) <br />
| ? <br />
| ?<br />
|-<br />
<br />
<br />
| QA Automation <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Code submission process <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Software updates <br />
| Bruce Ashfield <br />
| ?<br />
|-<br />
<br />
| AI/ML <br />
| ? <br />
| ?<br />
|-<br />
|}<br />
<br />
Here are some new topic ideas:<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
|-<br />
<br />
<br />
|}<br />
<br />
==Notes==<br />
===Social===<br />
Meet up @ ELC?<br />
<br />
==Minutes==<br />
<br />
https://docs.google.com/document/d/12rtiKrLgtZl617I5aew0g-N3ZoIyJts3r-FKP2AGRgQ/edit?usp=sharing</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDVM_2022_05&diff=11001OEDVM 2022 052022-05-17T09:14:56Z<p>Rpurdie: </p>
<hr />
<div>==Location and Time==<br />
<br />
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.<br />
<br />
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!<br />
<br />
==Format==<br />
<br />
As always, we will collect topics on the wiki at<br />
https://wiki.openembedded.org/OEDVM_2022_05.<br />
<br />
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.<br />
<br />
==Topic Ideas==<br />
<br />
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.<br />
<br />
(In no particular order)<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
! Notes<br />
|-<br />
| Introduction <br />
| OE Board<br />
| ?<br />
|-<br />
| Future of eSDK (inc. bblock/bbunlock commands)<br />
| ? <br />
| ?<br />
| https://lists.openembedded.org/g/openembedded-architecture/topic/thoughts_on_the_esdk/90990557<br />
|-<br />
| Copyright in OE-Core files<br />
| ? <br />
| ?<br />
| https://lists.openembedded.org/g/openembedded-architecture/topic/oe_core_copyright_notices/91159593<br />
|-<br />
| layer.conf changes <br />
| ? <br />
| ? <br />
|-<br />
<br />
<br />
| Data store operation changes <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Syntax removal <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Data store internal rewrite <br />
| ? <br />
| ?<br />
|-<br />
<br />
| f-string in Python code (and more modern python in general) <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Merging optional functionality to make it mandatory <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Dropping core features <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Security (PSiRT) <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Layer setup configuration <br />
| ? <br />
| ?<br />
|-<br />
<br />
| QA Automation <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Code submission process <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Software updates <br />
| ? <br />
| ?<br />
|-<br />
<br />
| AI/ML <br />
| ? <br />
| ?<br />
|-<br />
|}<br />
<br />
Here are some new topic ideas:<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
|-<br />
<br />
| Kernel config RFC<br />
| Trevor Woerner <br />
| 30<br />
|-<br />
<br />
| Layer Setup Configuration<br />
| Joshua Watt<br />
| 30<br />
|-<br />
<br />
| Bitbake & OE "Core improvements"<br />
| Joshua Watt<br />
| 30<br />
|-<br />
<br />
| Airing of Grievances<br />
| OpenEmbedded Board<br />
| 30+ (After all other topics covered)<br />
|-<br />
<br />
|}<br />
<br />
==Notes==<br />
===Social===<br />
Meet up @ ELC?<br />
<br />
==Minutes==<br />
<br />
TBD</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDVM_2022_05&diff=10998OEDVM 2022 052022-05-16T21:13:30Z<p>Rpurdie: </p>
<hr />
<div>==Location and Time==<br />
<br />
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.<br />
<br />
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!<br />
<br />
==Format==<br />
<br />
As always, we will collect topics on the wiki at<br />
https://wiki.openembedded.org/OEDVM_2022_05.<br />
<br />
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.<br />
<br />
==Topic Ideas==<br />
<br />
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.<br />
<br />
(In no particular order)<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
! Notes<br />
|-<br />
| Introduction <br />
| OE Board<br />
| ?<br />
|-<br />
| Future of eSDK (inc. bblock/bbunlock commands)<br />
| ? <br />
| ?<br />
| https://lists.openembedded.org/g/openembedded-architecture/topic/thoughts_on_the_esdk/90990557<br />
|-<br />
<br />
| layer.conf changes <br />
| ? <br />
| ? <br />
|-<br />
<br />
<br />
| Data store operation changes <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Syntax removal <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Data store internal rewrite <br />
| ? <br />
| ?<br />
|-<br />
<br />
| f-string in Python code (and more modern python in general) <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Merging optional functionality to make it mandatory <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Dropping core features <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Security (PSiRT) <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Layer setup configuration <br />
| ? <br />
| ?<br />
|-<br />
<br />
| QA Automation <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Code submission process <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Software updates <br />
| ? <br />
| ?<br />
|-<br />
<br />
| AI/ML <br />
| ? <br />
| ?<br />
|-<br />
|}<br />
<br />
Here are some new topic ideas:<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
|-<br />
<br />
| Kernel config RFC<br />
| Trevor Woerner <br />
| 30<br />
|-<br />
<br />
|}<br />
<br />
==Notes==<br />
===Social===<br />
Meet up @ ELC?<br />
<br />
==Minutes==<br />
<br />
TBD</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDVM_2022_05&diff=10997OEDVM 2022 052022-05-16T21:12:35Z<p>Rpurdie: </p>
<hr />
<div>==Location and Time==<br />
<br />
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.<br />
<br />
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!<br />
<br />
==Format==<br />
<br />
As always, we will collect topics on the wiki at<br />
https://wiki.openembedded.org/OEDVM_2022_05.<br />
<br />
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.<br />
<br />
==Topic Ideas==<br />
<br />
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.<br />
<br />
(In no particular order)<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
! Notes<br />
|-<br />
| Introduction <br />
| OE Board<br />
| ?<br />
|-<br />
| Future of eSDK (inc. bblock/bbunlock commands)<br />
| ? <br />
| ?<br />
| https://lists.openembedded.org/g/openembedded-architecture/topic/thoughts_on_the_esdk/90990557<br />
|-<br />
<br />
| layer.conf changes <br />
| ? <br />
| ? <br />
|-<br />
<br />
<br />
| Data store operation changes <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Syntax removal <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Data store internal rewrite <br />
| ? <br />
| ?<br />
|-<br />
<br />
| f-string in Python code (and more modern python in general) <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Bitbake internal changes <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Merging optional functionality to make it mandatory <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Dropping core features <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Security (PSiRT) <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Layer setup configuration <br />
| ? <br />
| ?<br />
|-<br />
<br />
| QA Automation <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Code submission process <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Software updates <br />
| ? <br />
| ?<br />
|-<br />
<br />
| AI/ML <br />
| ? <br />
| ?<br />
|-<br />
|}<br />
<br />
Here are some new topic ideas:<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
|-<br />
<br />
| Kernel config RFC<br />
| Trevor Woerner <br />
| 30<br />
|-<br />
<br />
|}<br />
<br />
==Notes==<br />
===Social===<br />
Meet up @ ELC?<br />
<br />
==Minutes==<br />
<br />
TBD</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDVM_2022_05&diff=10996OEDVM 2022 052022-05-11T18:39:53Z<p>Rpurdie: /* Topic Ideas */</p>
<hr />
<div>==Location and Time==<br />
<br />
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.<br />
<br />
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!<br />
<br />
==Format==<br />
<br />
As always, we will collect topics on the wiki at<br />
https://wiki.openembedded.org/OEDVM_2022_05.<br />
<br />
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.<br />
<br />
==Topic Ideas==<br />
<br />
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.<br />
<br />
(In no particular order)<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
! Notes<br />
|-<br />
| Introduction <br />
| OE Board<br />
| ?<br />
|-<br />
| Future of eSDK <br />
| ? <br />
| ?<br />
| https://lists.openembedded.org/g/openembedded-architecture/topic/thoughts_on_the_esdk/90990557<br />
|-<br />
<br />
| bblock/bbunlock <br />
| ? <br />
| ?<br />
|-<br />
<br />
| layer.conf changes <br />
| ? <br />
| ? <br />
|-<br />
<br />
<br />
| Data store operation changes <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Syntax removal <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Data store internal rewrite <br />
| ? <br />
| ?<br />
|-<br />
<br />
| f-string in Python code (and more modern python in general) <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Bitbake internal changes <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Merging optional functionality to make it mandatory <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Dropping core features <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Security (PSiRT) <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Layer setup configuration <br />
| ? <br />
| ?<br />
|-<br />
<br />
| QA Automation <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Code submission process <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Software updates <br />
| ? <br />
| ?<br />
|-<br />
<br />
| AI/ML <br />
| ? <br />
| ?<br />
|-<br />
|}<br />
<br />
Here are some new topic ideas:<br />
<br />
::{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
|-<br />
<br />
| Kernel config RFC<br />
| Trevor Woerner <br />
| 30<br />
|-<br />
<br />
|}<br />
<br />
==Notes==<br />
===Social===<br />
Meet up @ ELC?<br />
<br />
==Minutes==<br />
<br />
TBD</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDVM_Nov_2021&diff=10932OEDVM Nov 20212021-12-07T12:43:20Z<p>Rpurdie: </p>
<hr />
<div>==Location and Time==<br />
<br />
Held after the [https://pretalx.com/yocto-project-summit-2021-11/ Yocto Project Summit ], The OE Developers Meeting is scheduled for Friday, 03 December 2021 between 12:00 and 20:00 UTC.<br />
The exact times for each individual topic are found below in the schedule.<br />
<br />
We will be using Automotive Grade Linux's Zoom (and many thanks to AGL for this!)<br />
https://zoom.us/j/99151508871<br />
<br />
<br />
==Format==<br />
<br />
As always, we will collect topics on the wiki at<br />
https://www.openembedded.org/OEDVM_Nov_2021.<br />
<br />
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.<br />
<br />
==Topic Ideas==<br />
<br />
(In no particular order)<br />
{|<br />
! Topic <br />
! Moderator(s)<br />
! Estimate of time<br />
|-<br />
<br />
| Future direction for SBOM <br />
| Ross Burton, Saul Wold, Joshua Watt <br />
| ?<br />
|-<br />
<br />
| Replacing Sato with Phosh <br />
| Joshua Watt, Tim Orling <br />
| ?<br />
|-<br />
<br />
| Future of eSDK <br />
| ? <br />
| ?<br />
|-<br />
<br />
| bblock/bbunlock <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Binary distributions <br />
| Bruce Ashfield <br />
| ?<br />
|-<br />
<br />
| Modern languages (e.g. go) <br />
| Paul Barker<br />
| ?<br />
|-<br />
<br />
| Inclusive language <br />
| Jon Mason, Tim Orling <br />
| 15mins <br />
|-<br />
<br />
| layer.conf changes <br />
| ? <br />
| ? <br />
|-<br />
<br />
<br />
| Data store operation changes <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Syntax removal <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Data store internal rewrite <br />
| ? <br />
| ?<br />
|-<br />
<br />
| f-string in Python code (and more modern python in general) <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Bitbake internal changes <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Merging optional functionality to make it mandatory <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Dropping core features <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Migration to SPDX license <br />
| Ross Burton, Joshua Watt <br />
| ?<br />
|-<br />
<br />
| Security (PSiRT) <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Layer setup configuration <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Yocto Project compatibility <br />
| ndec<br />
| ?<br />
|-<br />
<br />
| QA Automation <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Code submission process <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Software updates <br />
| ? <br />
| ?<br />
|-<br />
<br />
| AI/ML <br />
| ? <br />
| ?<br />
|-<br />
<br />
| Increasing OE membership and voter turnout <br />
| OE Board member<br />
| ?<br />
|-<br />
|}<br />
<br />
==Minutes==<br />
<br />
https://docs.google.com/document/d/1T7pqHvNZuwDGOPXIgRR1_1-ECgDcw0xNin2IgahHpRk/edit#</div>Rpurdiehttps://www.openembedded.org/index.php?title=TSC&diff=10909TSC2021-10-19T10:21:14Z<p>Rpurdie: /* 2020 Minutes */</p>
<hr />
<div>=OE Technical Steering Committee=<br />
<br />
The TSC consists of 5 people who are elected by, and ultimately be answerable to, the members of the OpenEmbedded organisation.<br />
<br />
Here is the [[TSCCharter | working copy]] of the new TSC charter.<br />
<br />
The TSC meets on an irregular basis, but is happy to hold meetings on request if there are issues to discuss.<br />
<br />
The TSC discusses technical issues for the direction of OpenEmbedded. Note that the TSC is NOT chartered with actually doing all of the work discussed, but they do make every effort to locate resources to do that work.<br />
<br />
= Members =<br />
<br />
In order by name:<br />
<br />
* Bruce Ashfield (zeddii) re-elected Sep 2021<br />
* Jon Mason (jonmason) - elected Sep 2021<br />
* Joshua Watt (JPEW) re-elected Sep 2021<br />
* Paul Eggleton (bluelightning) - re-elected Sep 2021<br />
* Richard Purdie (RP) - re-elected Sep 2021<br />
<br />
Each member serves a two-year term.<br />
<br />
= Responsibilities =<br />
<br />
On a day-to-day basis the TSC is responsible for making<br />
tactical policy decisions, resolving disputes between contributors,<br />
administering access control to the git tree, and generally promoting<br />
good development practice.<br />
<br />
= Decision Making =<br />
<br />
Decisions are made where necessary by majority vote. Once a decision is made by<br />
the technical steering committee, the decision should be respected as a democratic decision.<br />
<br />
= TSC topics =<br />
<br />
This list keeps a running list of topics for the TSC. If you would like to add a topic for discussion, please e-mail one of the TSC members or the list curator [mailto:JPEWhacker@gmail.com Joshua Watt] so that the TSC is aware of the change. The issue will be added to the agenda for the next meeting. If the issue is particularly urgent, a specific TSC meeting may be called.<br />
<br />
* Talk about how to acknowledge contributions from community members<br />
* Further discussion on how to increase participation in the project<br />
* OE/YP Training and certification<br />
* Layer Quality<br />
<br />
= TSC mailing list archive =<br />
* Current Groups.io<br />
https://lists.openembedded.org/g/tsc<br />
<br />
* old Archive<br />
http://lists.openembedded.org/pipermail/tsc/<br />
<br />
= Meeting Minutes =<br />
<br />
Meetings are usually held in #oe-tsc on Libera Chat on 3rd Monday of each month 9PM UTC (10PM UTC during winter time).<br />
<br />
== 2021 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/message/519 18 January 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/518 15 February 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/555 16 March 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/530 19 April 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/557 17 May 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/544 21 June 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/545 19 July 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/554 16 August 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/553 20 September 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/552 18 October 2021]<br />
<br />
== 2020 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188966 20 January 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72189000 17 March 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/487 20 April 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/74313532 19 May 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/502 20 July 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/508 17 August 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/513 19 October 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/512 16 November 2020]<br />
<br />
== 2019 Minutes ==<br />
<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188896 21 October 2019]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188949 16 December 2019]<br />
<br />
== 2013 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000362.html 29 January 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000363.html 12 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000365.html 26 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000366.html 19 March 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-April/000367.html 8 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/000368.html 23 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/00037.html 7 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000372.html 21 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000373.html 4 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000381.html 18 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-August/000393.html 2 July 2013]<br />
* 16 July 2013<br />
* 30 July 2013 (public meeting)<br />
* 13 August 2013 (cancelled)<br />
* 27 August 2013<br />
<br />
== 2012 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000330.html 3-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000331.html 17-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-February/000332.html 30-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000334.html 15-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000335.html 28-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000336.html 13-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000337.html 27-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000340.html 10-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000342.html 24-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000341.html 08-May-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000343.html 22-May-2012]<br />
* 5-Jun-2012 (no meeting)<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000344.html 19-Jun-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000346.html 3-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000347.html 17-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000348.html 31-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000353.html 14-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000354.html 28-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000355.html 11-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000356.html 25-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000357.html 9-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-November/000358.html 23-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-December/000359.html 6-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000360.html 20-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000361.html 4-Dec-2012]<br />
<br />
== 2011 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/029974.html 14-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/030355.html 21-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000113.html 28-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000192.html 10-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000193.html 17-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000208.html 25-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000224.html 31-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000232.html 10-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000241.html 28-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000240.html 05-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000245.html 12-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000246.html 19-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000249.html 26-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000250.html 02-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000251.html 09-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000258.html 16-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000266.html 23-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000270.html 30-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000272.html 14-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000283.html 21-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000285.html 04-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000298.html 11-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000301.html 01-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000297.html 16-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000299.html 29-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000302.html 06-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000303.html 20-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000304.html 03-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000322.html 17-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000323.html 22-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-core/2011-December/014563.html 13-Dec-2011]<br />
<br />
== 2010 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-June/020655.html June 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-May/020047.html May 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-March/017876.html March 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-February/017094.html February 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-January/015931.html January 2010]<br />
<br />
[[Category:Policy]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=TSC&diff=10908TSC2021-10-19T10:20:47Z<p>Rpurdie: /* Meeting Minutes */</p>
<hr />
<div>=OE Technical Steering Committee=<br />
<br />
The TSC consists of 5 people who are elected by, and ultimately be answerable to, the members of the OpenEmbedded organisation.<br />
<br />
Here is the [[TSCCharter | working copy]] of the new TSC charter.<br />
<br />
The TSC meets on an irregular basis, but is happy to hold meetings on request if there are issues to discuss.<br />
<br />
The TSC discusses technical issues for the direction of OpenEmbedded. Note that the TSC is NOT chartered with actually doing all of the work discussed, but they do make every effort to locate resources to do that work.<br />
<br />
= Members =<br />
<br />
In order by name:<br />
<br />
* Bruce Ashfield (zeddii) re-elected Sep 2021<br />
* Jon Mason (jonmason) - elected Sep 2021<br />
* Joshua Watt (JPEW) re-elected Sep 2021<br />
* Paul Eggleton (bluelightning) - re-elected Sep 2021<br />
* Richard Purdie (RP) - re-elected Sep 2021<br />
<br />
Each member serves a two-year term.<br />
<br />
= Responsibilities =<br />
<br />
On a day-to-day basis the TSC is responsible for making<br />
tactical policy decisions, resolving disputes between contributors,<br />
administering access control to the git tree, and generally promoting<br />
good development practice.<br />
<br />
= Decision Making =<br />
<br />
Decisions are made where necessary by majority vote. Once a decision is made by<br />
the technical steering committee, the decision should be respected as a democratic decision.<br />
<br />
= TSC topics =<br />
<br />
This list keeps a running list of topics for the TSC. If you would like to add a topic for discussion, please e-mail one of the TSC members or the list curator [mailto:JPEWhacker@gmail.com Joshua Watt] so that the TSC is aware of the change. The issue will be added to the agenda for the next meeting. If the issue is particularly urgent, a specific TSC meeting may be called.<br />
<br />
* Talk about how to acknowledge contributions from community members<br />
* Further discussion on how to increase participation in the project<br />
* OE/YP Training and certification<br />
* Layer Quality<br />
<br />
= TSC mailing list archive =<br />
* Current Groups.io<br />
https://lists.openembedded.org/g/tsc<br />
<br />
* old Archive<br />
http://lists.openembedded.org/pipermail/tsc/<br />
<br />
= Meeting Minutes =<br />
<br />
Meetings are usually held in #oe-tsc on Libera Chat on 3rd Monday of each month 9PM UTC (10PM UTC during winter time).<br />
<br />
== 2021 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/message/519 18 January 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/518 15 February 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/555 16 March 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/530 19 April 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/557 17 May 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/544 21 June 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/545 19 July 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/554 16 August 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/553 20 September 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/552 18 October 2021]<br />
<br />
== 2020 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188966 20 January 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72189000 17 March 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/487 20 April 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/74313532 19 May 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/502 20 July 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/508 17 August 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/513 19 October 2020<br />
* [https://lists.openembedded.org/g/tsc/message/512 16 November 2020]<br />
<br />
== 2019 Minutes ==<br />
<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188896 21 October 2019]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188949 16 December 2019]<br />
<br />
== 2013 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000362.html 29 January 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000363.html 12 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000365.html 26 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000366.html 19 March 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-April/000367.html 8 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/000368.html 23 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/00037.html 7 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000372.html 21 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000373.html 4 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000381.html 18 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-August/000393.html 2 July 2013]<br />
* 16 July 2013<br />
* 30 July 2013 (public meeting)<br />
* 13 August 2013 (cancelled)<br />
* 27 August 2013<br />
<br />
== 2012 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000330.html 3-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000331.html 17-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-February/000332.html 30-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000334.html 15-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000335.html 28-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000336.html 13-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000337.html 27-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000340.html 10-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000342.html 24-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000341.html 08-May-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000343.html 22-May-2012]<br />
* 5-Jun-2012 (no meeting)<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000344.html 19-Jun-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000346.html 3-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000347.html 17-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000348.html 31-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000353.html 14-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000354.html 28-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000355.html 11-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000356.html 25-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000357.html 9-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-November/000358.html 23-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-December/000359.html 6-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000360.html 20-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000361.html 4-Dec-2012]<br />
<br />
== 2011 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/029974.html 14-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/030355.html 21-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000113.html 28-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000192.html 10-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000193.html 17-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000208.html 25-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000224.html 31-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000232.html 10-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000241.html 28-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000240.html 05-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000245.html 12-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000246.html 19-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000249.html 26-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000250.html 02-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000251.html 09-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000258.html 16-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000266.html 23-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000270.html 30-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000272.html 14-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000283.html 21-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000285.html 04-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000298.html 11-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000301.html 01-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000297.html 16-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000299.html 29-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000302.html 06-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000303.html 20-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000304.html 03-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000322.html 17-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000323.html 22-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-core/2011-December/014563.html 13-Dec-2011]<br />
<br />
== 2010 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-June/020655.html June 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-May/020047.html May 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-March/017876.html March 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-February/017094.html February 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-January/015931.html January 2010]<br />
<br />
[[Category:Policy]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=TSC&diff=10907TSC2021-10-19T10:19:24Z<p>Rpurdie: /* 2021 Minutes */</p>
<hr />
<div>=OE Technical Steering Committee=<br />
<br />
The TSC consists of 5 people who are elected by, and ultimately be answerable to, the members of the OpenEmbedded organisation.<br />
<br />
Here is the [[TSCCharter | working copy]] of the new TSC charter.<br />
<br />
The TSC meets on an irregular basis, but is happy to hold meetings on request if there are issues to discuss.<br />
<br />
The TSC discusses technical issues for the direction of OpenEmbedded. Note that the TSC is NOT chartered with actually doing all of the work discussed, but they do make every effort to locate resources to do that work.<br />
<br />
= Members =<br />
<br />
In order by name:<br />
<br />
* Bruce Ashfield (zeddii) re-elected Sep 2021<br />
* Jon Mason (jonmason) - elected Sep 2021<br />
* Joshua Watt (JPEW) re-elected Sep 2021<br />
* Paul Eggleton (bluelightning) - re-elected Sep 2021<br />
* Richard Purdie (RP) - re-elected Sep 2021<br />
<br />
Each member serves a two-year term.<br />
<br />
= Responsibilities =<br />
<br />
On a day-to-day basis the TSC is responsible for making<br />
tactical policy decisions, resolving disputes between contributors,<br />
administering access control to the git tree, and generally promoting<br />
good development practice.<br />
<br />
= Decision Making =<br />
<br />
Decisions are made where necessary by majority vote. Once a decision is made by<br />
the technical steering committee, the decision should be respected as a democratic decision.<br />
<br />
= TSC topics =<br />
<br />
This list keeps a running list of topics for the TSC. If you would like to add a topic for discussion, please e-mail one of the TSC members or the list curator [mailto:JPEWhacker@gmail.com Joshua Watt] so that the TSC is aware of the change. The issue will be added to the agenda for the next meeting. If the issue is particularly urgent, a specific TSC meeting may be called.<br />
<br />
* Talk about how to acknowledge contributions from community members<br />
* Further discussion on how to increase participation in the project<br />
* OE/YP Training and certification<br />
* Layer Quality<br />
<br />
= TSC mailing list archive =<br />
* Current Groups.io<br />
https://lists.openembedded.org/g/tsc<br />
<br />
* old Archive<br />
http://lists.openembedded.org/pipermail/tsc/<br />
<br />
= Meeting Minutes =<br />
<br />
Meetings are usually held in #oe-tsc on Freenode on 3rd Monday of each month 9PM UTC (10PM UTC during winter time).<br />
<br />
== 2021 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/message/519 18 January 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/518 15 February 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/555 16 March 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/530 19 April 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/557 17 May 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/544 21 June 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/545 19 July 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/554 16 August 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/553 20 September 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/552 18 October 2021]<br />
<br />
== 2020 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188966 20 January 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72189000 17 March 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/487 20 April 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/74313532 19 May 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/502 20 July 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/508 17 August 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/513 19 October 2020<br />
* [https://lists.openembedded.org/g/tsc/message/512 16 November 2020]<br />
<br />
== 2019 Minutes ==<br />
<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188896 21 October 2019]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188949 16 December 2019]<br />
<br />
== 2013 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000362.html 29 January 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000363.html 12 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000365.html 26 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000366.html 19 March 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-April/000367.html 8 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/000368.html 23 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/00037.html 7 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000372.html 21 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000373.html 4 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000381.html 18 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-August/000393.html 2 July 2013]<br />
* 16 July 2013<br />
* 30 July 2013 (public meeting)<br />
* 13 August 2013 (cancelled)<br />
* 27 August 2013<br />
<br />
== 2012 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000330.html 3-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000331.html 17-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-February/000332.html 30-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000334.html 15-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000335.html 28-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000336.html 13-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000337.html 27-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000340.html 10-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000342.html 24-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000341.html 08-May-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000343.html 22-May-2012]<br />
* 5-Jun-2012 (no meeting)<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000344.html 19-Jun-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000346.html 3-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000347.html 17-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000348.html 31-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000353.html 14-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000354.html 28-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000355.html 11-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000356.html 25-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000357.html 9-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-November/000358.html 23-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-December/000359.html 6-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000360.html 20-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000361.html 4-Dec-2012]<br />
<br />
== 2011 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/029974.html 14-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/030355.html 21-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000113.html 28-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000192.html 10-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000193.html 17-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000208.html 25-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000224.html 31-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000232.html 10-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000241.html 28-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000240.html 05-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000245.html 12-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000246.html 19-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000249.html 26-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000250.html 02-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000251.html 09-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000258.html 16-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000266.html 23-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000270.html 30-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000272.html 14-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000283.html 21-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000285.html 04-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000298.html 11-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000301.html 01-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000297.html 16-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000299.html 29-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000302.html 06-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000303.html 20-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000304.html 03-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000322.html 17-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000323.html 22-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-core/2011-December/014563.html 13-Dec-2011]<br />
<br />
== 2010 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-June/020655.html June 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-May/020047.html May 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-March/017876.html March 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-February/017094.html February 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-January/015931.html January 2010]<br />
<br />
[[Category:Policy]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=TSC&diff=10906TSC2021-10-19T10:15:47Z<p>Rpurdie: /* 2021 Minutes */</p>
<hr />
<div>=OE Technical Steering Committee=<br />
<br />
The TSC consists of 5 people who are elected by, and ultimately be answerable to, the members of the OpenEmbedded organisation.<br />
<br />
Here is the [[TSCCharter | working copy]] of the new TSC charter.<br />
<br />
The TSC meets on an irregular basis, but is happy to hold meetings on request if there are issues to discuss.<br />
<br />
The TSC discusses technical issues for the direction of OpenEmbedded. Note that the TSC is NOT chartered with actually doing all of the work discussed, but they do make every effort to locate resources to do that work.<br />
<br />
= Members =<br />
<br />
In order by name:<br />
<br />
* Bruce Ashfield (zeddii) re-elected Sep 2021<br />
* Jon Mason (jonmason) - elected Sep 2021<br />
* Joshua Watt (JPEW) re-elected Sep 2021<br />
* Paul Eggleton (bluelightning) - re-elected Sep 2021<br />
* Richard Purdie (RP) - re-elected Sep 2021<br />
<br />
Each member serves a two-year term.<br />
<br />
= Responsibilities =<br />
<br />
On a day-to-day basis the TSC is responsible for making<br />
tactical policy decisions, resolving disputes between contributors,<br />
administering access control to the git tree, and generally promoting<br />
good development practice.<br />
<br />
= Decision Making =<br />
<br />
Decisions are made where necessary by majority vote. Once a decision is made by<br />
the technical steering committee, the decision should be respected as a democratic decision.<br />
<br />
= TSC topics =<br />
<br />
This list keeps a running list of topics for the TSC. If you would like to add a topic for discussion, please e-mail one of the TSC members or the list curator [mailto:JPEWhacker@gmail.com Joshua Watt] so that the TSC is aware of the change. The issue will be added to the agenda for the next meeting. If the issue is particularly urgent, a specific TSC meeting may be called.<br />
<br />
* Talk about how to acknowledge contributions from community members<br />
* Further discussion on how to increase participation in the project<br />
* OE/YP Training and certification<br />
* Layer Quality<br />
<br />
= TSC mailing list archive =<br />
* Current Groups.io<br />
https://lists.openembedded.org/g/tsc<br />
<br />
* old Archive<br />
http://lists.openembedded.org/pipermail/tsc/<br />
<br />
= Meeting Minutes =<br />
<br />
Meetings are usually held in #oe-tsc on Freenode on 3rd Monday of each month 9PM UTC (10PM UTC during winter time).<br />
<br />
== 2021 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/message/519 18 January 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/518 15 February 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/555 16 March 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/530 19 April 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/544 21 June 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/545 19 July 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/554 16 August 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/553 20 September 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/552 18 October 2021]<br />
<br />
== 2020 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188966 20 January 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72189000 17 March 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/487 20 April 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/74313532 19 May 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/502 20 July 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/508 17 August 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/513 19 October 2020<br />
* [https://lists.openembedded.org/g/tsc/message/512 16 November 2020]<br />
<br />
== 2019 Minutes ==<br />
<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188896 21 October 2019]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188949 16 December 2019]<br />
<br />
== 2013 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000362.html 29 January 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000363.html 12 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000365.html 26 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000366.html 19 March 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-April/000367.html 8 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/000368.html 23 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/00037.html 7 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000372.html 21 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000373.html 4 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000381.html 18 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-August/000393.html 2 July 2013]<br />
* 16 July 2013<br />
* 30 July 2013 (public meeting)<br />
* 13 August 2013 (cancelled)<br />
* 27 August 2013<br />
<br />
== 2012 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000330.html 3-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000331.html 17-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-February/000332.html 30-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000334.html 15-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000335.html 28-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000336.html 13-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000337.html 27-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000340.html 10-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000342.html 24-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000341.html 08-May-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000343.html 22-May-2012]<br />
* 5-Jun-2012 (no meeting)<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000344.html 19-Jun-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000346.html 3-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000347.html 17-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000348.html 31-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000353.html 14-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000354.html 28-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000355.html 11-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000356.html 25-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000357.html 9-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-November/000358.html 23-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-December/000359.html 6-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000360.html 20-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000361.html 4-Dec-2012]<br />
<br />
== 2011 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/029974.html 14-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/030355.html 21-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000113.html 28-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000192.html 10-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000193.html 17-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000208.html 25-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000224.html 31-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000232.html 10-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000241.html 28-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000240.html 05-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000245.html 12-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000246.html 19-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000249.html 26-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000250.html 02-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000251.html 09-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000258.html 16-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000266.html 23-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000270.html 30-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000272.html 14-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000283.html 21-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000285.html 04-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000298.html 11-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000301.html 01-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000297.html 16-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000299.html 29-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000302.html 06-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000303.html 20-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000304.html 03-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000322.html 17-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000323.html 22-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-core/2011-December/014563.html 13-Dec-2011]<br />
<br />
== 2010 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-June/020655.html June 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-May/020047.html May 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-March/017876.html March 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-February/017094.html February 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-January/015931.html January 2010]<br />
<br />
[[Category:Policy]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=TSC&diff=10905TSC2021-10-19T10:01:21Z<p>Rpurdie: /* 2021 Minutes */</p>
<hr />
<div>=OE Technical Steering Committee=<br />
<br />
The TSC consists of 5 people who are elected by, and ultimately be answerable to, the members of the OpenEmbedded organisation.<br />
<br />
Here is the [[TSCCharter | working copy]] of the new TSC charter.<br />
<br />
The TSC meets on an irregular basis, but is happy to hold meetings on request if there are issues to discuss.<br />
<br />
The TSC discusses technical issues for the direction of OpenEmbedded. Note that the TSC is NOT chartered with actually doing all of the work discussed, but they do make every effort to locate resources to do that work.<br />
<br />
= Members =<br />
<br />
In order by name:<br />
<br />
* Bruce Ashfield (zeddii) re-elected Sep 2021<br />
* Jon Mason (jonmason) - elected Sep 2021<br />
* Joshua Watt (JPEW) re-elected Sep 2021<br />
* Paul Eggleton (bluelightning) - re-elected Sep 2021<br />
* Richard Purdie (RP) - re-elected Sep 2021<br />
<br />
Each member serves a two-year term.<br />
<br />
= Responsibilities =<br />
<br />
On a day-to-day basis the TSC is responsible for making<br />
tactical policy decisions, resolving disputes between contributors,<br />
administering access control to the git tree, and generally promoting<br />
good development practice.<br />
<br />
= Decision Making =<br />
<br />
Decisions are made where necessary by majority vote. Once a decision is made by<br />
the technical steering committee, the decision should be respected as a democratic decision.<br />
<br />
= TSC topics =<br />
<br />
This list keeps a running list of topics for the TSC. If you would like to add a topic for discussion, please e-mail one of the TSC members or the list curator [mailto:JPEWhacker@gmail.com Joshua Watt] so that the TSC is aware of the change. The issue will be added to the agenda for the next meeting. If the issue is particularly urgent, a specific TSC meeting may be called.<br />
<br />
* Talk about how to acknowledge contributions from community members<br />
* Further discussion on how to increase participation in the project<br />
* OE/YP Training and certification<br />
* Layer Quality<br />
<br />
= TSC mailing list archive =<br />
* Current Groups.io<br />
https://lists.openembedded.org/g/tsc<br />
<br />
* old Archive<br />
http://lists.openembedded.org/pipermail/tsc/<br />
<br />
= Meeting Minutes =<br />
<br />
Meetings are usually held in #oe-tsc on Freenode on 3rd Monday of each month 9PM UTC (10PM UTC during winter time).<br />
<br />
== 2021 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/message/519 18 January 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/518 15 February 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/544 21 June 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/545 19 July 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/554 16 August 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/553 20 September 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/552 18 October 2021]<br />
<br />
== 2020 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188966 20 January 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72189000 17 March 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/487 20 April 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/74313532 19 May 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/502 20 July 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/508 17 August 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/513 19 October 2020<br />
* [https://lists.openembedded.org/g/tsc/message/512 16 November 2020]<br />
<br />
== 2019 Minutes ==<br />
<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188896 21 October 2019]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188949 16 December 2019]<br />
<br />
== 2013 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000362.html 29 January 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000363.html 12 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000365.html 26 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000366.html 19 March 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-April/000367.html 8 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/000368.html 23 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/00037.html 7 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000372.html 21 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000373.html 4 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000381.html 18 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-August/000393.html 2 July 2013]<br />
* 16 July 2013<br />
* 30 July 2013 (public meeting)<br />
* 13 August 2013 (cancelled)<br />
* 27 August 2013<br />
<br />
== 2012 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000330.html 3-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000331.html 17-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-February/000332.html 30-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000334.html 15-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000335.html 28-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000336.html 13-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000337.html 27-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000340.html 10-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000342.html 24-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000341.html 08-May-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000343.html 22-May-2012]<br />
* 5-Jun-2012 (no meeting)<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000344.html 19-Jun-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000346.html 3-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000347.html 17-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000348.html 31-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000353.html 14-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000354.html 28-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000355.html 11-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000356.html 25-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000357.html 9-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-November/000358.html 23-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-December/000359.html 6-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000360.html 20-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000361.html 4-Dec-2012]<br />
<br />
== 2011 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/029974.html 14-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/030355.html 21-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000113.html 28-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000192.html 10-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000193.html 17-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000208.html 25-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000224.html 31-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000232.html 10-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000241.html 28-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000240.html 05-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000245.html 12-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000246.html 19-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000249.html 26-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000250.html 02-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000251.html 09-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000258.html 16-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000266.html 23-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000270.html 30-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000272.html 14-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000283.html 21-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000285.html 04-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000298.html 11-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000301.html 01-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000297.html 16-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000299.html 29-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000302.html 06-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000303.html 20-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000304.html 03-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000322.html 17-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000323.html 22-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-core/2011-December/014563.html 13-Dec-2011]<br />
<br />
== 2010 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-June/020655.html June 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-May/020047.html May 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-March/017876.html March 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-February/017094.html February 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-January/015931.html January 2010]<br />
<br />
[[Category:Policy]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=TSC&diff=10898TSC2021-09-20T21:00:34Z<p>Rpurdie: /* Members */</p>
<hr />
<div>=OE Technical Steering Committee=<br />
<br />
The TSC consists of 5 people who are elected by, and ultimately be answerable to, the members of the OpenEmbedded organisation.<br />
<br />
Here is the [[TSCCharter | working copy]] of the new TSC charter.<br />
<br />
The TSC meets on an irregular basis, but is happy to hold meetings on request if there are issues to discuss.<br />
<br />
The TSC discusses technical issues for the direction of OpenEmbedded. Note that the TSC is NOT chartered with actually doing all of the work discussed, but they do make every effort to locate resources to do that work.<br />
<br />
= Members =<br />
<br />
In order by name:<br />
<br />
* Bruce Ashfield (zeddii) re-elected Sep 2021<br />
* Jon Mason (jonmason) - elected Sep 2021<br />
* Joshua Watt (JPEW) re-elected Sep 2021<br />
* Paul Eggleton (bluelightning) - re-elected Sep 2021<br />
* Richard Purdie (RP) - re-elected Sep 2021<br />
<br />
Each member serves a two-year term.<br />
<br />
= Responsibilities =<br />
<br />
On a day-to-day basis the TSC is responsible for making<br />
tactical policy decisions, resolving disputes between contributors,<br />
administering access control to the git tree, and generally promoting<br />
good development practice.<br />
<br />
= Decision Making =<br />
<br />
Decisions are made where necessary by majority vote. Once a decision is made by<br />
the technical steering committee, the decision should be respected as a democratic decision.<br />
<br />
= TSC topics =<br />
<br />
This list keeps a running list of topics for the TSC. If you would like to add a topic for discussion, please e-mail one of the TSC members or the list curator [mailto:JPEWhacker@gmail.com Joshua Watt] so that the TSC is aware of the change. The issue will be added to the agenda for the next meeting. If the issue is particularly urgent, a specific TSC meeting may be called.<br />
<br />
* TSC Elections are this year<br />
* Talk about how to acknowledge contributions from community members<br />
* Further discussion on how to increase participation in the project<br />
* OE/YP Training and certification<br />
* Layer Quality<br />
<br />
= TSC mailing list archive =<br />
* Current Groups.io<br />
https://lists.openembedded.org/g/tsc<br />
<br />
* old Archive<br />
http://lists.openembedded.org/pipermail/tsc/<br />
<br />
= Meeting Minutes =<br />
<br />
Meetings are usually held in #oe-tsc on Freenode on 3rd Monday of each month 9PM UTC (10PM UTC during winter time).<br />
<br />
== 2021 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/message/519 18 January 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/518 15 February 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/544 21 June 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/545 19 July 2021]<br />
<br />
== 2020 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188966 20 January 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72189000 17 March 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/487 20 April 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/74313532 19 May 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/502 20 July 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/508 17 August 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/513 19 October 2020<br />
* [https://lists.openembedded.org/g/tsc/message/512 16 November 2020]<br />
<br />
== 2019 Minutes ==<br />
<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188896 21 October 2019]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188949 16 December 2019]<br />
<br />
== 2013 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000362.html 29 January 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000363.html 12 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000365.html 26 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000366.html 19 March 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-April/000367.html 8 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/000368.html 23 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/00037.html 7 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000372.html 21 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000373.html 4 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000381.html 18 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-August/000393.html 2 July 2013]<br />
* 16 July 2013<br />
* 30 July 2013 (public meeting)<br />
* 13 August 2013 (cancelled)<br />
* 27 August 2013<br />
<br />
== 2012 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000330.html 3-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000331.html 17-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-February/000332.html 30-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000334.html 15-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000335.html 28-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000336.html 13-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000337.html 27-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000340.html 10-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000342.html 24-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000341.html 08-May-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000343.html 22-May-2012]<br />
* 5-Jun-2012 (no meeting)<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000344.html 19-Jun-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000346.html 3-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000347.html 17-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000348.html 31-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000353.html 14-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000354.html 28-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000355.html 11-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000356.html 25-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000357.html 9-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-November/000358.html 23-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-December/000359.html 6-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000360.html 20-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000361.html 4-Dec-2012]<br />
<br />
== 2011 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/029974.html 14-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/030355.html 21-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000113.html 28-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000192.html 10-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000193.html 17-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000208.html 25-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000224.html 31-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000232.html 10-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000241.html 28-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000240.html 05-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000245.html 12-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000246.html 19-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000249.html 26-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000250.html 02-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000251.html 09-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000258.html 16-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000266.html 23-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000270.html 30-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000272.html 14-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000283.html 21-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000285.html 04-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000298.html 11-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000301.html 01-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000297.html 16-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000299.html 29-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000302.html 06-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000303.html 20-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000304.html 03-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000322.html 17-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000323.html 22-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-core/2011-December/014563.html 13-Dec-2011]<br />
<br />
== 2010 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-June/020655.html June 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-May/020047.html May 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-March/017876.html March 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-February/017094.html February 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-January/015931.html January 2010]<br />
<br />
[[Category:Policy]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=TSC&diff=10896TSC2021-09-11T15:25:56Z<p>Rpurdie: </p>
<hr />
<div>=OE Technical Steering Committee=<br />
<br />
The TSC consists of 5 people who are elected by, and ultimately be answerable to, the members of the OpenEmbedded organisation.<br />
<br />
Here is the [[TSCCharter | working copy]] of the new TSC charter.<br />
<br />
The TSC meets on an irregular basis, but is happy to hold meetings on request if there are issues to discuss.<br />
<br />
The TSC discusses technical issues for the direction of OpenEmbedded. Note that the TSC is NOT chartered with actually doing all of the work discussed, but they do make every effort to locate resources to do that work.<br />
<br />
= Members =<br />
<br />
In order by name:<br />
<br />
* Bruce Ashfield re-elected Sep 2021<br />
* Jon Mason (jonmason) - elected Sep 2021<br />
* Joshua Watt (JPEW) re-elected Sep 2021<br />
* Paul Eggleton (bluelightning) - re-elected Sep 2021<br />
* Richard Purdie (RP) - re-elected Sep 2021<br />
<br />
Each member serves a two-year term.<br />
<br />
= Responsibilities =<br />
<br />
On a day-to-day basis the TSC is responsible for making<br />
tactical policy decisions, resolving disputes between contributors,<br />
administering access control to the git tree, and generally promoting<br />
good development practice.<br />
<br />
= Decision Making =<br />
<br />
Decisions are made where necessary by majority vote. Once a decision is made by<br />
the technical steering committee, the decision should be respected as a democratic decision.<br />
<br />
= TSC topics =<br />
<br />
This list keeps a running list of topics for the TSC. If you would like to add a topic for discussion, please e-mail one of the TSC members or the list curator [mailto:JPEWhacker@gmail.com Joshua Watt] so that the TSC is aware of the change. The issue will be added to the agenda for the next meeting. If the issue is particularly urgent, a specific TSC meeting may be called.<br />
<br />
* TSC Elections are this year<br />
* Talk about how to acknowledge contributions from community members<br />
* Further discussion on how to increase participation in the project<br />
* OE/YP Training and certification<br />
* Layer Quality<br />
<br />
= TSC mailing list archive =<br />
<br />
http://lists.openembedded.org/pipermail/tsc/<br />
<br />
= Meeting Minutes =<br />
<br />
Meetings are usually held in #oe-tsc on Freenode on 3rd Monday of each month 9PM UTC (10PM UTC during winter time).<br />
<br />
== 2021 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/message/519 18 January 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/518 15 February 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/544 21 June 2021]<br />
* [https://lists.openembedded.org/g/tsc/message/545 19 July 2021]<br />
<br />
== 2020 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188966 20 January 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72189000 17 March 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/487 20 April 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/74313532 19 May 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/502 20 July 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/508 17 August 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/513 19 October 2020<br />
* [https://lists.openembedded.org/g/tsc/message/512 16 November 2020]<br />
<br />
== 2019 Minutes ==<br />
<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188896 21 October 2019]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188949 16 December 2019]<br />
<br />
== 2013 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000362.html 29 January 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000363.html 12 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000365.html 26 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000366.html 19 March 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-April/000367.html 8 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/000368.html 23 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/00037.html 7 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000372.html 21 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000373.html 4 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000381.html 18 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-August/000393.html 2 July 2013]<br />
* 16 July 2013<br />
* 30 July 2013 (public meeting)<br />
* 13 August 2013 (cancelled)<br />
* 27 August 2013<br />
<br />
== 2012 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000330.html 3-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000331.html 17-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-February/000332.html 30-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000334.html 15-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000335.html 28-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000336.html 13-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000337.html 27-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000340.html 10-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000342.html 24-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000341.html 08-May-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000343.html 22-May-2012]<br />
* 5-Jun-2012 (no meeting)<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000344.html 19-Jun-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000346.html 3-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000347.html 17-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000348.html 31-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000353.html 14-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000354.html 28-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000355.html 11-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000356.html 25-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000357.html 9-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-November/000358.html 23-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-December/000359.html 6-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000360.html 20-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000361.html 4-Dec-2012]<br />
<br />
== 2011 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/029974.html 14-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/030355.html 21-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000113.html 28-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000192.html 10-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000193.html 17-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000208.html 25-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000224.html 31-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000232.html 10-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000241.html 28-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000240.html 05-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000245.html 12-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000246.html 19-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000249.html 26-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000250.html 02-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000251.html 09-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000258.html 16-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000266.html 23-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000270.html 30-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000272.html 14-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000283.html 21-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000285.html 04-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000298.html 11-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000301.html 01-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000297.html 16-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000299.html 29-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000302.html 06-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000303.html 20-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000304.html 03-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000322.html 17-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000323.html 22-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-core/2011-December/014563.html 13-Dec-2011]<br />
<br />
== 2010 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-June/020655.html June 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-May/020047.html May 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-March/017876.html March 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-February/017094.html February 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-January/015931.html January 2010]<br />
<br />
[[Category:Policy]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=New_Bitbake_Syntax_Brainstorm&diff=10880New Bitbake Syntax Brainstorm2021-07-14T18:26:16Z<p>Rpurdie: </p>
<hr />
<div>{| border=1<br />
! Example !! Expands To !! Description<br />
|-<br />
| <tt>FOO += "bar"</tt> || <tt>FOO_defvar_append = " bar"</tt> || Append " bar" to the default value<br />
|-<br />
| <tt>FOO ??= "bar"</tt> || <tt>FOO_weakval = "bar"</tt> || Set the weakest override value to "bar"<br />
|-<br />
| <tt>FOO_append = "bar"</tt> || <tt>FOO_append = "bar"</tt> || Append "bar" to any value of FOO<br />
|-<br />
| <tt>FOO_o_append = "bar" </tt> || <tt>FOO_o_append = "bar"</tt> || Append "bar" to FOO_o<br />
|-<br />
| <tt>FOO_append_o = "bar" </tt> || <tt>FOO_append_o = "bar"</tt> || Append "bar" to any value of FOO if o is in OVERRIDES<br />
|-<br />
| <tt>FOO_o += "bar"</tt> || <tt>FOO_o_defvar_append = " bar"</tt> || Append " bar" to the default value of FOO_o<br />
|}</div>Rpurdiehttps://www.openembedded.org/index.php?title=New_Bitbake_Syntax_Brainstorm&diff=10875New Bitbake Syntax Brainstorm2021-07-14T17:59:33Z<p>Rpurdie: </p>
<hr />
<div>{| border=1<br />
! Example !! Expands To !! Description<br />
|-<br />
| <tt>FOO += "bar"</tt> || <tt>FOO_defvar_append = " bar"</tt> || Append " bar" to the default value<br />
|-<br />
| <tt>FOO ??= "bar"</tt> || <tt>FOO_weakval = "bar"</tt> || Set the weakest override value to "bar"<br />
|-<br />
| <tt>FOO_append = "bar"</tt> || <tt>FOO_append = "bar"</tt> || Append "bar" to any value of FOO<br />
|-<br />
| <tt>FOO_o_append = "bar" </tt> || <tt>FOO_o_append = "bar"</tt> || Append "bar" to FOO_o<br />
|-<br />
| <tt>FOO_append_o = "bar" </tt> || <tt>FOO_append_o = "bar"</tt> || Append "bar" to value of FOO_o if o is in OVERRIDES<br />
|}</div>Rpurdiehttps://www.openembedded.org/index.php?title=New_Bitbake_Syntax_Brainstorm&diff=10874New Bitbake Syntax Brainstorm2021-07-14T17:58:54Z<p>Rpurdie: </p>
<hr />
<div>{| border=1<br />
! Example !! Expands To !! Description<br />
|-<br />
| <tt>FOO += "bar"</tt> || <tt>FOO_defvar_append = " bar"</tt> || Append " bar" to the default value<br />
|-<br />
| <tt>FOO ??= "bar"</tt> || <tt>FOO_weakval = "bar"</tt> || Set the weakest override value to "bar"<br />
|-<br />
| <tt>FOO_append = "bar"</tt> || <tt>FOO_append = "bar"</tt> || Append "bar" to any value<br />
|-<br />
| <tt>FOO_o_append = "bar" </tt> || <tt>FOO_o_append = "bar"</tt> || Append "bar" to FOO_o<br />
|-<br />
| <tt>FOO_append_o = "bar" </tt> || <tt>FOO_append_o = "bar"</tt> || Append "bar" to value of FOO_o if o is in OVERRIDES<br />
|}</div>Rpurdiehttps://www.openembedded.org/index.php?title=How_to_submit_a_patch_to_OpenEmbedded&diff=10832How to submit a patch to OpenEmbedded2021-05-17T22:49:18Z<p>Rpurdie: </p>
<hr />
<div>OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.<br />
<br />
== Finding the right place for your patch ==<br />
<br />
OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.<br />
<br />
New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].<br />
<br />
== A task-oriented guide to creating a patch ==<br />
<br />
Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.<br />
<br />
=== Set up git ===<br />
<br />
Properly configuring git (using tekkub@gmail.com as an example user)<br />
<br />
On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)<br />
<br />
sudo aptitude install git-core git-email<br />
<br />
These are important to the commit meta-data<br />
<br />
git config --global user.name "Tekkub"<br />
git config --global user.email "tekkub@gmail.com"<br />
<br />
Any Google Apps account<br />
<br />
git config --global sendemail.smtpserver smtp.gmail.com<br />
git config --global sendemail.smtpserverport 587<br />
git config --global sendemail.smtpencryption tls<br />
git config --global sendemail.smtpuser tekkupl@gmail.com<br />
<br />
You can use the --envelope-sender option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the gmail settings tab. Use the Send mail as selection to address you want to send email from.<br />
<br />
=== Subscribe to the mailing list ===<br />
<br />
You need to subscribe to the appropriate mailing-list in order to be able to send your patch(es) there; for patches against OE-Core the mailing list is '''openembedded-core@lists.openembedded.org''' and for patches against meta-oe and many other layers the list is '''openembedded-devel@lists.openembedded.org'''. See [[Mailing lists]] for subscription and further details.<br />
<br />
=== Committing your patch ===<br />
<br />
Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code. <br />
<br />
cd oe-core/ # or whereever you keep your clone of the repo<br />
git add meta/recipes-devtools/flex<br />
git commit -s # don't use the -m option but include my signature<br />
<br />
flex: backport Debian patches to fix generated code warnings<br />
<br />
The generated parser had warnings regarding signess and return check<br />
which makes Linux Kernel's perf tool from 3.4 release to fail without<br />
those patches.<br />
<br />
All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].<br />
<br />
Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.<br />
<br />
=== Sending patches ===<br />
<br />
There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.<br />
<br />
==== Sending using git-send-email ====<br />
<br />
To send just the top commit on your current branch (substitute mailing list address as appropriate):<br />
<br />
git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1<br />
<br />
For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.<br />
<br />
Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:<br />
--subject-prefix="meta-oe][PATCH"<br />
<br />
Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)<br />
<br />
==== Sending via a pull request ====<br />
<br />
Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:<br />
<br />
# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.<br />
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.<br />
# Push the branch to the remote.<br />
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.<br />
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.<br />
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.<br />
<br />
<br />
=== Backporting fixes to stable releases ===<br />
<br />
When a bug is present on a stable branch of OE yet has been fixed in master one can request that the stable branch's maintainer accept the fix into the stable branch.<br />
The best way to do this is generate a patch with the backport and submit it to the openembedded-core@lists.openembedded.org mailing list (CC'ing the maintainer may help the patch be reviewed for inclusion more quickly).<br />
<br />
Patches for stable branches should be prefixed with the branch name (which is the same as the release series name), for example morty, pyro, etc.<br />
Once you've identified the commit hash of the patch you'd like to see accepted as a backport you can generate the patch with:<br />
<br />
git format-patch <COMMIT_HASH> -1 --subject-prefix="<BRANCH_NAME>][PATCH"<br />
<br />
The generated patch can then be sent using the procedure described above.<br />
<br />
== Community review ==<br />
<br />
Your patch will be sent to the mailing list and for some layers should be immediately visible on http://patches.openembedded.org/<br />
<br />
If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.<br />
<br />
If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.<br />
<br />
== Automated testing ==<br />
<br />
The project has extensive tests in several forms:<br />
<br />
* image tests (testimage.bbclass)<br />
* sdk tests (testsdk.bbclass)<br />
* eSDK tests<br />
* 'selftests' (through oe-selftest)<br />
* bitbake selftests (through bitbake-selftest)<br />
* ptests - recipe/package specific tests<br />
<br />
When submitting patches, they will be tested on the Yocto Project's autobuilder test infrastructure https://autobuilder.yoctoproject.org/typhoon/#/console . Where patches add a new major piece of functionality, additions to the automated testing would be expected. Additions for new tests to prevent regressions are also extremely welcome.<br />
<br />
== Appendix ==<br />
<br />
=== Steps for people which don't have SMTP access for git === <br />
<br />
Patches should not be sent as attachment but inline.<br />
<br />
If you do not have SMTP access to your email account you have two options:<br />
<br />
1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)<br />
<br />
2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,<br />
wrap lines etc etc).<br />
<br />
A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.<br />
<br />
=== Streamlining git-send-email with configuration ===<br />
<br />
Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.<br />
<br />
<ul><br />
<li>Always confirm sending (for all repositories):<br />
<pre>git config --global sendemail.confirm always</pre></li><br />
<li>Set send-to email address for the repository (don't forget to specify the right address!):<br />
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre><br />
</li><br />
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):<br />
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre><br />
</li><br />
</ul><br />
<br />
==See also==<br />
* [[Commit Patch Message Guidelines]]<br />
* [[Styleguide]]<br />
<br />
[[Category:FAQ]]<br />
[[Category:User]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=Commit_Patch_Message_Guidelines&diff=10788Commit Patch Message Guidelines2020-10-08T19:41:40Z<p>Rpurdie: /* Patch Headers and Commit Messages */</p>
<hr />
<div>This set of guidelines is intended to help both the developer and reviewers of<br />
changes determine reasonable patch headers and change commit messages. Often<br />
when working with the code, you forget that not everyone is as familiar with the<br />
problem and/or fix as you are. Often the next person in the code doesn't<br />
understand what or why something is done so they quickly look at patch header<br />
and commit messages. Unless these messages are clear it will be difficult to<br />
understand the relevance of a given change and how future changes may impact<br />
previous decisions.<br />
<br />
This policy refers both to patches that are being applied by recipes as well as<br />
commit messages that are part of the source control system, usually git. A patch<br />
file needs a header in order to describe the specific changes that are made<br />
within that patch, while a commit message describes one or more changes to the<br />
overall project or system. Both the patch headers and commit messages require<br />
the same attention and basic details, however the purposes of the messages are<br />
slightly different. A commit message documents all of the changes made as part<br />
of a commit, while a patch header documents items specific to a single patch. In<br />
many cases the patch header can also be used as the commit message.<br />
<br />
This policy does not cover the testing of the changes, the technical criteria<br />
for accepting a patch, nor the style requirements for the technical changes. See <br />
the [http://www.openembedded.org/wiki/Styleguide Styleguide] for more information on style requirements.<br />
<br />
By following these guidelines we will have a better record of the problems and<br />
solutions made over the course of development. It will also help establish a<br />
clear provenance of all of the code and changes.<br />
<br />
Draft version, changes from last approved version:<br />
* Revised General Information section to correct broken link<br />
* Clarify the ''Developer's Certificate of Origin''<br />
<br />
== General Information ==<br />
<br />
While specific to the Linux kernel development, the following could also be<br />
considered a general guide for any Open Source development:<br />
<br />
https://www.linux.com/publications/how-participate-linux-community<br />
<br />
Many of the guidelines in this document are related to the items referenced in<br />
the link above.<br />
<br />
Pay particular attention to section 5.3 that talks about patch preparation.<br />
The key thing to remember is to break up your changes into logical sections.<br />
Otherwise you run the risk of not being able to even explain the purpose of a<br />
change in the patch headers!<br />
<br />
In addition section 5.4 explains the purpose of the Signed-off-by: tag line. The<br />
signed-off-by: tag line is the ''Developer's Certificate of Origin''. The full text<br />
of which can be found in the Linux kernel's Documentation/SubmittingPatches.<br />
<br />
Pay particular attention to section 11 of <br />
<br />
https://www.kernel.org/doc/html/latest/process/submitting-patches.html<br />
<br />
Due to the importance of the ''Developer's Certificate of Origin'', part of section 11<br />
is copied below:<br />
<br />
The sign-off is a simple line at the end of the explanation for the<br />
patch, which certifies that you wrote it or otherwise have the right to<br />
pass it on as an open-source patch. The rules are pretty simple: if you<br />
can certify the below:<br />
<br />
Developer's Certificate of Origin 1.1<br />
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br />
<br />
By making a contribution to this project, I certify that:<br />
<br />
(a) The contribution was created in whole or in part by me and I<br />
have the right to submit it under the open source license<br />
indicated in the file; or<br />
<br />
(b) The contribution is based upon previous work that, to the best<br />
of my knowledge, is covered under an appropriate open source<br />
license and I have the right under that license to submit that<br />
work with modifications, whether created in whole or in part<br />
by me, under the same open source license (unless I am<br />
permitted to submit under a different license), as indicated<br />
in the file; or<br />
<br />
(c) The contribution was provided directly to me by some other<br />
person who certified (a), (b) or (c) and I have not modified<br />
it.<br />
<br />
(d) I understand and agree that this project and the contribution<br />
are public and that a record of the contribution (including all<br />
personal information I submit with it, including my sign-off) is<br />
maintained indefinitely and may be redistributed consistent with<br />
this project or the open source license(s) involved.<br />
<br />
then you just add a line saying::<br />
<br />
Signed-off-by: Random J Developer <random@developer.example.org><br />
<br />
using your real name (sorry, no pseudonyms or anonymous contributions.)<br />
<br />
== Patch Headers and Commit Messages ==<br />
<br />
There seems to always be a question or two surrounding what a person<br />
should put in a patch header, or commit message.<br />
<br />
The general rules always apply, those being that there is a single line<br />
short log or summary of the change (think of this as the subject when the patch<br />
is e-mailed), and then the more detailed long log, and closure with tag lines<br />
such as "Signed-off-by:".<br />
<br />
If the bug relates to a bug in the Yocto Project Bugzilla (https://bugzilla.yoctoproject.org/) then a reference to that bugzilla entry should be added to the details in the form:<br />
<br />
[YOCTO #12345]<br />
<br />
where 12345 is the number of the bug being referenced. The commit message should be understandable in its own right without needing to look at the bug.<br />
<br />
It is useful to include a version number in the [PATCH] prefix of the subject line, e.g. [PATCH v2] so that its known to be a new version of an earlier patch. It can also be useful to include information about what changed in the new version. This should either be in the cover letter of the series (if one is present) or be done under the detailed commit message and after a "---" separator line. This will mean git will discard the revision information when the patch is applied. This is because the history of the patch revisions is not usually useful to the information being stored against the change. If it is useful information, it should be in the commit message instead.<br />
<br />
== New Development ==<br />
<br />
A minimal patch or commit message would be of the format:<br />
<br />
Short log / Statement of what needed to be changed.<br />
<br />
(Optional pointers to external resources, such as defect tracking)<br />
<br />
The intent of your change.<br />
<br />
(Optional, if it's not clear from above) how your change resolves the<br />
issues in the first part.<br />
<br />
Tag line(s) at the end.<br />
<br />
For example:<br />
<br />
foobar: Adjusted the foo setting in bar<br />
<br />
When using foobar on systems with less than a gigabyte of RAM common<br />
usage patterns often result in an Out-of-memory condition causing<br />
slowdowns and unexpected application termination.<br />
<br />
Low-memory systems should continue to function without running into<br />
memory-starvation conditions with minimal cost to systems with more<br />
available memory. High-memory systems will be less able to use the<br />
full extent of the system, a dynamically tunable option may be best,<br />
long-term.<br />
<br />
The foo setting in bar was decreased from X to X-50% in order to<br />
ensure we don't exhaust all system memory with foobar threads.<br />
<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
The minimal commit message is good for new code development and simple changes.<br />
<br />
The single short log message indicates what needed to be changed. It should<br />
begin with an indicator as to the primary item changed by this work,<br />
followed by a short summary of the change. In the above case we're indicating<br />
that we've changed the "foobar" item, by "adjusting the foo setting in bar".<br />
<br />
The single short log message is analogous to the git "commit summary". While no<br />
maximum line length is specified by this policy, it is suggested that it remains<br />
under 78 characters wherever possible.<br />
<br />
Optionally, you may include pointers to defects this change corrects. Unless<br />
the defect format is specified by the component you are modifying, it is<br />
suggested that you use a full URL to specify the reference to the defect<br />
information. Generally these pointers will precede any long description, but as<br />
an optional item it may be after the long description.<br />
<br />
For example, you might refer to an open source defect in the RPM project:<br />
<br />
rpm: Adjusted the foo setting in bar<br />
<br />
<nowiki>[RPM Ticket #65] -- http://rpm5.org/cvs/tktview?tn=65,5</nowiki><br />
<br />
The foo setting in bar was decreased from X to X-50% in order to<br />
ensure we don't exhaust all system memory with foobar threads.<br />
<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
You must then have a full description of the change. Specifying the intent of<br />
your change and if necessary how the change resolves the issue.<br />
<br />
As mentioned above this is intended to answer the "what were you thinking"<br />
questions down the road and to know what other impacts are likely to<br />
result of the change needs to be reverted. It also allows for better<br />
solutions if someone comes along later and agrees with paragraph 1<br />
(the problem statement) and either disagrees with paragraph 2<br />
(the design) or paragraph 3 (the implementation).<br />
<br />
Finally one or more tag lines should exist. Each developer responsible<br />
for working on the patch is responsible for adding a Signed-off-by: tag line.<br />
<br />
It is not acceptable to have an empty or non-existent header, or just a single<br />
line message. The summary and description is required for all changes.<br />
<br />
=== Describing license changes ===<br />
<br />
When you change the LICENSE or LIC_FILES_CHKSUM lines in the recipe, you need to<br />
briefly explain the reason for the change in via License-Update: tag. Quite often<br />
it's trivial, such as<br />
<br />
License-Update: copyright years refreshed<br />
<br />
but if the licensing terms themselves changed, do try to include a link to the upstream<br />
making/justifying that decision.<br />
<br />
== Importing from Elsewhere ==<br />
<br />
If you are importing work from somewhere else, such as a cherry-pick from<br />
another repository or a code patch pulled from a mailing list, the minimum patch<br />
header or commit message is not enough. It does not clearly establish the<br />
provenance of the code.<br />
<br />
The following specifies the additional guidelines required for importing changes<br />
from elsewhere.<br />
<br />
By default you should keep the original author's summary and description,<br />
along with any tag lines such as, "Signed-off-by:". If the original change that<br />
was imported does not have a summary and/or commit message from the original<br />
author, it is still your responsibility to add the summary and commit message to<br />
the patch header. Just as if you wrote the code, you should be able to clearly<br />
explain what the change does. It is also necessary to document the original<br />
author of the change. You should indicate the original author by simply stating<br />
"written by" or "posted to the ... mailing list by". You must not add a<br />
Signed-off-by: tag line with their name, only the original author may add their<br />
own Signed-off-by: tag line.<br />
<br />
It is also required that the origin of the work be fully documented. The origin<br />
should be specified as part of the commit message in a way that an average<br />
developer would be able to track down the original code. URLs should reference<br />
original authoritative sources and not mirrors.<br />
<br />
If changes were required to resolve conflicts, they should be documented as<br />
well. When incorporating a commit or patch from an external source, changes to<br />
the functionality not related to resolving conflicts should be made in a<br />
second commit or patch. This preserves the original external commit, and makes<br />
the modifications clearly visible, and prevents confusion over the author of the<br />
code.<br />
<br />
Finally you must add a "Signed-off-by:" tag line to indicate that you worked<br />
with the patch.<br />
<br />
<br />
=== Example: Importing from Elsewhere Unmodified ===<br />
<br />
For example, if you were to pull in the patch from the above example unmodified:<br />
<br />
foobar: Adjusted the foo setting in bar<br />
<br />
When using foobar on systems with less than a gigabyte of RAM common<br />
usage patterns often result in an Out-of-memory condition causing<br />
slowdowns and unexpected application termination.<br />
<br />
Low-memory systems should continue to function without running into<br />
memory-starvation conditions with minimal cost to systems with more<br />
available memory. High-memory systems will be less able to use the<br />
full extent of the system, a dynamically tunable option may be best,<br />
long-term.<br />
<br />
The foo setting in bar was decreased from X to X-50% in order to<br />
ensure we don't exhaust all system memory with foobar threads.<br />
<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
The patch was imported from the OpenEmbedded git server<br />
(<nowiki>git://git.openembedded.org/openembedded</nowiki>) as of commit id<br />
b65a0e0c84cf489bfa00d6aa6c48abc5a237100f.<br />
<br />
Signed-off-by: Your Name <your.name@openembedded.org><br />
<br />
The above example shows a clear way for a developer to find the original source<br />
of the change. It indicates that the OpenEmbedded developer simply integrated<br />
the change into the system without making any further modifications.<br />
<br />
=== Example: Importing from Elsewhere Modified ===<br />
<br />
When importing a patch, occasionally changes have to be made in order to resolve<br />
conflicts. The following is an example of the commit message when the item needed<br />
to be modified:<br />
<br />
foobar: Adjusted the foo setting in bar<br />
<br />
When using foobar on systems with less than a gigabyte of RAM common<br />
usage patterns often result in an Out-of-memory condition causing<br />
slowdowns and unexpected application termination.<br />
<br />
Low-memory systems should continue to function without running into<br />
memory-starvation conditions with minimal cost to systems with more<br />
available memory. High-memory systems will be less able to use the<br />
full extent of the system, a dynamically tunable option may be best,<br />
long-term.<br />
<br />
The foo setting in bar was decreased from X to X-50% in order to<br />
ensure we don't exhaust all system memory with foobar threads.<br />
<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
The patch was imported from the OpenEmbedded git server<br />
(<nowiki>git://git.openembedded.org/openembedded</nowiki>) as of commit id<br />
b65a0e0c84cf489bfa00d6aa6c48abc5a237100f.<br />
<br />
A previous change had modified the memory threshold calculation,<br />
causing a conflict. The conflict was resolved by preserving the<br />
memory threshold calculation from the existing implementation.<br />
<br />
Signed-off-by: Your Name <your.name@openembedded.org><br />
<br />
== Patch Header Recommendations: Upstream-Status ==<br />
<br />
In order to keep track of patches and ultimately reduce the number of patches<br />
that are required to be maintained, we need to track the status of the patches<br />
that are created. The following items are specific to patches applied by recipes.<br />
<br />
In addition to the items mentioned above, we also want to track if it's<br />
appropriate to get this particular patch into the upstream project. Since we<br />
want to track this information, we need a consistent tag and status indicator<br />
that can be searched.<br />
<br />
While adding this tracking information to the patch headers is currently<br />
optional, it is highly recommended and some maintainers may require it. It is<br />
optional at this time so that it can be evaluated as to its usefulness over<br />
time. Existing patches will be updated with the tag as they are modified.<br />
<br />
As mentioned in the above, be sure to include any URL to bug tracking, mailing<br />
lists or other reference material pertaining to the patch. Then add a new tag<br />
"Upstream-Status:" which contains one of the following items:<br />
<br />
'''Pending'''<br />
- No determination has been made yet or not yet submitted to upstream<br />
<br />
'''Submitted''' [where]<br />
- Submitted to upstream, waiting approval<br />
- Optionally include where it was submitted, such as the author, mailing<br />
list, etc.<br />
<br />
'''Accepted'''<br />
- Accepted in upstream, expect it to be removed at next update, include<br />
expected version info<br />
<br />
'''Backport'''<br />
- Backported from new upstream version, because we are at a fixed version,<br />
include upstream version info<br />
<br />
'''Denied'''<br />
- Not accepted by upstream, include reason in patch<br />
<br />
'''Inappropriate [reason]'''<br />
- The patch is not appropriate for upstream, include a brief reason on the<br />
same line enclosed with []<br />
reason can be:<br />
not author (You are not the author and do not intend to upstream this,<br />
source must be listed in the comments)<br />
native<br />
licensing<br />
configuration<br />
enable feature<br />
disable feature<br />
bugfix (add bug URL here)<br />
embedded specific<br />
no upstream (the upstream is no longer available -- dead project)<br />
other (give details in comments)<br />
<br />
The various "Inappropriate [reason]" status items are meant to indicate that the<br />
person responsible for adding this patch to the system does not intend to<br />
upstream the patch for a specific reason. Unless otherwise noted, another<br />
person could submit this patch to the upstream, if they do the status should be<br />
changed to "Submitted [where]", and an additional Signed-off-by: line added to<br />
the patch by the person claiming responsibility for upstreaming.<br />
<br />
For example, if the patch has been submitted upstream:<br />
<br />
rpm: Adjusted the foo setting in bar<br />
<br />
<nowiki>[RPM Ticket #65] -- http://rpm5.org/cvs/tktview?tn=65,5</nowiki><br />
<br />
The foo setting in bar was decreased from X to X-50% in order to<br />
ensure we don't exhaust all system memory with foobar threads.<br />
<br />
Upstream-Status: Submitted [rpm5-devel@rpm5.org]<br />
<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
A future commit can change the value to "Accepted" or "Denied" as appropriate.<br />
<br />
=== CVE Patches ===<br />
<br />
In order to have a better control of vulnerabilities, patches that fix CVEs must contain the "CVE:" tag. This tag list all CVEs fixed by the patch. If more than one CVE is fixed, separate them using spaces.<br />
<br />
==== Example: CVE patch header ====<br />
<br />
This should be the header of patch that fixes grub2 CVE-2015-8370:<br />
<br />
grub2: Fix CVE-2015-8370<br />
<br />
<nowiki>[No upstream tracking] -- https://bugzilla.redhat.com/show_bug.cgi?id=1286966</nowiki><br />
<br />
Back to 28; Grub2 Authentication<br />
<br />
Two functions suffer from integer underflow fault; the grub_username_get() and grub_password_get()located in<br />
grub-core/normal/auth.c and lib/crypto.c respectively. This can be exploited to obtain a Grub rescue shell.<br />
<br />
<nowiki>Upstream-Status: Accepted [http://git.savannah.gnu.org/cgit/grub.git/commit/?id=451d80e52d851432e109771bb8febafca7a5f1f2]</nowiki><br />
CVE: CVE-2015-8370<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
== Common Errors in Patch and Commit Messages ==<br />
<br />
- Short log does not start with the file or component being modified. Such as<br />
"foo: Update to new upstream version 5.8.9"<br />
<br />
- Avoid starting the summary line with a capital letter, unless the component<br />
being referred to also begins with a capital letter.<br />
<br />
- Don't have one huge patch, split your change into logical subparts. It's<br />
easier to track down problems afterward using tools such as git bisect. It also<br />
makes it easy for people to cherry-pick changes into things like stable branches.<br />
<br />
- Don't simply translate your change into English for a commit log. The log<br />
"Change compare from zero to one" is bad because it describes only the code<br />
change in the patch; we can see that from reading the patch itself. Let the code<br />
tell the story of the mechanics of the change (as much as possible), and let<br />
your comment tell the other details -- i.e. what the problem was, how it<br />
manifested itself (symptoms), and if necessary, the justification for why the<br />
fix was done in manner that it was. In other words, the long commit message<br />
must describe *why* the change was needed (instead of what has changed).<br />
<br />
- Don't start your commit log with "This patch..." -- we already know it is a patch.<br />
<br />
- Don't repeat your short log in the long log. If you really really don't have<br />
anything new and informational to add in as a long log, then don't put a long<br />
log at all. This should be uncommon -- i.e. the only acceptable cases for no<br />
long log would be something like "Documentation/README: Fix spelling mistakes".<br />
<br />
- Don't put absolute paths to source files that are specific to your site, i.e.<br />
if you get a compile error on "fs/exec.c" then tidy up the parts of the compile<br />
output to just show that portion. We don't need to see that it was<br />
/home/wally/src/git/oe-core/meta/classes/insane.bbclass or similar - that full<br />
path has no value to others. Always reduce the path to something more<br />
meaningful, such as oe-core/meta/classes/insane.bbclass.<br />
<br />
- Always use the most significant ramification of the change in the words of<br />
your subject/shortlog. For example, don't say "fix compile warning in foo" when<br />
the compiler warning was really telling us that we were dereferencing complete<br />
garbage off in the weeds that could in theory cause an OOPS under some<br />
circumstances. When people are choosing commits for backports to stable or<br />
distro kernels, the shortlog will be what they use for an initial sorting<br />
selection. If they see "Fix possible OOPS in...." then these people will look<br />
closer, whereas they most likely will skip over simple warning fixes.<br />
<br />
- Don't put in the full 20 or more lines of a backtrace when really it is just<br />
the last 5 or so function calls that are relevant to the crash/fix. If the entry<br />
point, or start of the trace is relevant (i.e. a syscall or similar), you can<br />
leave that, and then replace a chunk of the intermediate calls in the middle<br />
with a single [...]<br />
<br />
- Don't include timestamps or other unnecessary information, unless they are<br />
relevant to the situation (i.e. indicating an unacceptable delay in a driver<br />
initialization etc.)<br />
<br />
- Don't use links to temporary resources like pastebin and friends. The commit<br />
message may be read long after this resource timed out.<br />
<br />
- Don't reference mirrors, but instead always reference original authoritative<br />
sources.<br />
<br />
- Avoid punctuation in the short log.<br />
<br />
[[Category:Policy]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=Commit_Patch_Message_Guidelines&diff=10787Commit Patch Message Guidelines2020-10-08T19:38:20Z<p>Rpurdie: /* Patch Headers and Commit Messages */</p>
<hr />
<div>This set of guidelines is intended to help both the developer and reviewers of<br />
changes determine reasonable patch headers and change commit messages. Often<br />
when working with the code, you forget that not everyone is as familiar with the<br />
problem and/or fix as you are. Often the next person in the code doesn't<br />
understand what or why something is done so they quickly look at patch header<br />
and commit messages. Unless these messages are clear it will be difficult to<br />
understand the relevance of a given change and how future changes may impact<br />
previous decisions.<br />
<br />
This policy refers both to patches that are being applied by recipes as well as<br />
commit messages that are part of the source control system, usually git. A patch<br />
file needs a header in order to describe the specific changes that are made<br />
within that patch, while a commit message describes one or more changes to the<br />
overall project or system. Both the patch headers and commit messages require<br />
the same attention and basic details, however the purposes of the messages are<br />
slightly different. A commit message documents all of the changes made as part<br />
of a commit, while a patch header documents items specific to a single patch. In<br />
many cases the patch header can also be used as the commit message.<br />
<br />
This policy does not cover the testing of the changes, the technical criteria<br />
for accepting a patch, nor the style requirements for the technical changes. See <br />
the [http://www.openembedded.org/wiki/Styleguide Styleguide] for more information on style requirements.<br />
<br />
By following these guidelines we will have a better record of the problems and<br />
solutions made over the course of development. It will also help establish a<br />
clear provenance of all of the code and changes.<br />
<br />
Draft version, changes from last approved version:<br />
* Revised General Information section to correct broken link<br />
* Clarify the ''Developer's Certificate of Origin''<br />
<br />
== General Information ==<br />
<br />
While specific to the Linux kernel development, the following could also be<br />
considered a general guide for any Open Source development:<br />
<br />
https://www.linux.com/publications/how-participate-linux-community<br />
<br />
Many of the guidelines in this document are related to the items referenced in<br />
the link above.<br />
<br />
Pay particular attention to section 5.3 that talks about patch preparation.<br />
The key thing to remember is to break up your changes into logical sections.<br />
Otherwise you run the risk of not being able to even explain the purpose of a<br />
change in the patch headers!<br />
<br />
In addition section 5.4 explains the purpose of the Signed-off-by: tag line. The<br />
signed-off-by: tag line is the ''Developer's Certificate of Origin''. The full text<br />
of which can be found in the Linux kernel's Documentation/SubmittingPatches.<br />
<br />
Pay particular attention to section 11 of <br />
<br />
https://www.kernel.org/doc/html/latest/process/submitting-patches.html<br />
<br />
Due to the importance of the ''Developer's Certificate of Origin'', part of section 11<br />
is copied below:<br />
<br />
The sign-off is a simple line at the end of the explanation for the<br />
patch, which certifies that you wrote it or otherwise have the right to<br />
pass it on as an open-source patch. The rules are pretty simple: if you<br />
can certify the below:<br />
<br />
Developer's Certificate of Origin 1.1<br />
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br />
<br />
By making a contribution to this project, I certify that:<br />
<br />
(a) The contribution was created in whole or in part by me and I<br />
have the right to submit it under the open source license<br />
indicated in the file; or<br />
<br />
(b) The contribution is based upon previous work that, to the best<br />
of my knowledge, is covered under an appropriate open source<br />
license and I have the right under that license to submit that<br />
work with modifications, whether created in whole or in part<br />
by me, under the same open source license (unless I am<br />
permitted to submit under a different license), as indicated<br />
in the file; or<br />
<br />
(c) The contribution was provided directly to me by some other<br />
person who certified (a), (b) or (c) and I have not modified<br />
it.<br />
<br />
(d) I understand and agree that this project and the contribution<br />
are public and that a record of the contribution (including all<br />
personal information I submit with it, including my sign-off) is<br />
maintained indefinitely and may be redistributed consistent with<br />
this project or the open source license(s) involved.<br />
<br />
then you just add a line saying::<br />
<br />
Signed-off-by: Random J Developer <random@developer.example.org><br />
<br />
using your real name (sorry, no pseudonyms or anonymous contributions.)<br />
<br />
== Patch Headers and Commit Messages ==<br />
<br />
There seems to always be a question or two surrounding what a person<br />
should put in a patch header, or commit message.<br />
<br />
The general rules always apply, those being that there is a single line<br />
short log or summary of the change (think of this as the subject when the patch<br />
is e-mailed), and then the more detailed long log, and closure with tag lines<br />
such as "Signed-off-by:".<br />
<br />
If the bug relates to a bug in the Yocto Project Bugzilla (https://bugzilla.yoctoproject.org/) then a reference to that bugzilla entry should be added to the details in the form:<br />
<br />
[YOCTO #12345]<br />
<br />
where 12345 is the number of the bug being referenced. The commit message should be understandable in its own right without needing to look at the bug.<br />
<br />
== New Development ==<br />
<br />
A minimal patch or commit message would be of the format:<br />
<br />
Short log / Statement of what needed to be changed.<br />
<br />
(Optional pointers to external resources, such as defect tracking)<br />
<br />
The intent of your change.<br />
<br />
(Optional, if it's not clear from above) how your change resolves the<br />
issues in the first part.<br />
<br />
Tag line(s) at the end.<br />
<br />
For example:<br />
<br />
foobar: Adjusted the foo setting in bar<br />
<br />
When using foobar on systems with less than a gigabyte of RAM common<br />
usage patterns often result in an Out-of-memory condition causing<br />
slowdowns and unexpected application termination.<br />
<br />
Low-memory systems should continue to function without running into<br />
memory-starvation conditions with minimal cost to systems with more<br />
available memory. High-memory systems will be less able to use the<br />
full extent of the system, a dynamically tunable option may be best,<br />
long-term.<br />
<br />
The foo setting in bar was decreased from X to X-50% in order to<br />
ensure we don't exhaust all system memory with foobar threads.<br />
<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
The minimal commit message is good for new code development and simple changes.<br />
<br />
The single short log message indicates what needed to be changed. It should<br />
begin with an indicator as to the primary item changed by this work,<br />
followed by a short summary of the change. In the above case we're indicating<br />
that we've changed the "foobar" item, by "adjusting the foo setting in bar".<br />
<br />
The single short log message is analogous to the git "commit summary". While no<br />
maximum line length is specified by this policy, it is suggested that it remains<br />
under 78 characters wherever possible.<br />
<br />
Optionally, you may include pointers to defects this change corrects. Unless<br />
the defect format is specified by the component you are modifying, it is<br />
suggested that you use a full URL to specify the reference to the defect<br />
information. Generally these pointers will precede any long description, but as<br />
an optional item it may be after the long description.<br />
<br />
For example, you might refer to an open source defect in the RPM project:<br />
<br />
rpm: Adjusted the foo setting in bar<br />
<br />
<nowiki>[RPM Ticket #65] -- http://rpm5.org/cvs/tktview?tn=65,5</nowiki><br />
<br />
The foo setting in bar was decreased from X to X-50% in order to<br />
ensure we don't exhaust all system memory with foobar threads.<br />
<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
You must then have a full description of the change. Specifying the intent of<br />
your change and if necessary how the change resolves the issue.<br />
<br />
As mentioned above this is intended to answer the "what were you thinking"<br />
questions down the road and to know what other impacts are likely to<br />
result of the change needs to be reverted. It also allows for better<br />
solutions if someone comes along later and agrees with paragraph 1<br />
(the problem statement) and either disagrees with paragraph 2<br />
(the design) or paragraph 3 (the implementation).<br />
<br />
Finally one or more tag lines should exist. Each developer responsible<br />
for working on the patch is responsible for adding a Signed-off-by: tag line.<br />
<br />
It is not acceptable to have an empty or non-existent header, or just a single<br />
line message. The summary and description is required for all changes.<br />
<br />
=== Describing license changes ===<br />
<br />
When you change the LICENSE or LIC_FILES_CHKSUM lines in the recipe, you need to<br />
briefly explain the reason for the change in via License-Update: tag. Quite often<br />
it's trivial, such as<br />
<br />
License-Update: copyright years refreshed<br />
<br />
but if the licensing terms themselves changed, do try to include a link to the upstream<br />
making/justifying that decision.<br />
<br />
== Importing from Elsewhere ==<br />
<br />
If you are importing work from somewhere else, such as a cherry-pick from<br />
another repository or a code patch pulled from a mailing list, the minimum patch<br />
header or commit message is not enough. It does not clearly establish the<br />
provenance of the code.<br />
<br />
The following specifies the additional guidelines required for importing changes<br />
from elsewhere.<br />
<br />
By default you should keep the original author's summary and description,<br />
along with any tag lines such as, "Signed-off-by:". If the original change that<br />
was imported does not have a summary and/or commit message from the original<br />
author, it is still your responsibility to add the summary and commit message to<br />
the patch header. Just as if you wrote the code, you should be able to clearly<br />
explain what the change does. It is also necessary to document the original<br />
author of the change. You should indicate the original author by simply stating<br />
"written by" or "posted to the ... mailing list by". You must not add a<br />
Signed-off-by: tag line with their name, only the original author may add their<br />
own Signed-off-by: tag line.<br />
<br />
It is also required that the origin of the work be fully documented. The origin<br />
should be specified as part of the commit message in a way that an average<br />
developer would be able to track down the original code. URLs should reference<br />
original authoritative sources and not mirrors.<br />
<br />
If changes were required to resolve conflicts, they should be documented as<br />
well. When incorporating a commit or patch from an external source, changes to<br />
the functionality not related to resolving conflicts should be made in a<br />
second commit or patch. This preserves the original external commit, and makes<br />
the modifications clearly visible, and prevents confusion over the author of the<br />
code.<br />
<br />
Finally you must add a "Signed-off-by:" tag line to indicate that you worked<br />
with the patch.<br />
<br />
<br />
=== Example: Importing from Elsewhere Unmodified ===<br />
<br />
For example, if you were to pull in the patch from the above example unmodified:<br />
<br />
foobar: Adjusted the foo setting in bar<br />
<br />
When using foobar on systems with less than a gigabyte of RAM common<br />
usage patterns often result in an Out-of-memory condition causing<br />
slowdowns and unexpected application termination.<br />
<br />
Low-memory systems should continue to function without running into<br />
memory-starvation conditions with minimal cost to systems with more<br />
available memory. High-memory systems will be less able to use the<br />
full extent of the system, a dynamically tunable option may be best,<br />
long-term.<br />
<br />
The foo setting in bar was decreased from X to X-50% in order to<br />
ensure we don't exhaust all system memory with foobar threads.<br />
<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
The patch was imported from the OpenEmbedded git server<br />
(<nowiki>git://git.openembedded.org/openembedded</nowiki>) as of commit id<br />
b65a0e0c84cf489bfa00d6aa6c48abc5a237100f.<br />
<br />
Signed-off-by: Your Name <your.name@openembedded.org><br />
<br />
The above example shows a clear way for a developer to find the original source<br />
of the change. It indicates that the OpenEmbedded developer simply integrated<br />
the change into the system without making any further modifications.<br />
<br />
=== Example: Importing from Elsewhere Modified ===<br />
<br />
When importing a patch, occasionally changes have to be made in order to resolve<br />
conflicts. The following is an example of the commit message when the item needed<br />
to be modified:<br />
<br />
foobar: Adjusted the foo setting in bar<br />
<br />
When using foobar on systems with less than a gigabyte of RAM common<br />
usage patterns often result in an Out-of-memory condition causing<br />
slowdowns and unexpected application termination.<br />
<br />
Low-memory systems should continue to function without running into<br />
memory-starvation conditions with minimal cost to systems with more<br />
available memory. High-memory systems will be less able to use the<br />
full extent of the system, a dynamically tunable option may be best,<br />
long-term.<br />
<br />
The foo setting in bar was decreased from X to X-50% in order to<br />
ensure we don't exhaust all system memory with foobar threads.<br />
<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
The patch was imported from the OpenEmbedded git server<br />
(<nowiki>git://git.openembedded.org/openembedded</nowiki>) as of commit id<br />
b65a0e0c84cf489bfa00d6aa6c48abc5a237100f.<br />
<br />
A previous change had modified the memory threshold calculation,<br />
causing a conflict. The conflict was resolved by preserving the<br />
memory threshold calculation from the existing implementation.<br />
<br />
Signed-off-by: Your Name <your.name@openembedded.org><br />
<br />
== Patch Header Recommendations: Upstream-Status ==<br />
<br />
In order to keep track of patches and ultimately reduce the number of patches<br />
that are required to be maintained, we need to track the status of the patches<br />
that are created. The following items are specific to patches applied by recipes.<br />
<br />
In addition to the items mentioned above, we also want to track if it's<br />
appropriate to get this particular patch into the upstream project. Since we<br />
want to track this information, we need a consistent tag and status indicator<br />
that can be searched.<br />
<br />
While adding this tracking information to the patch headers is currently<br />
optional, it is highly recommended and some maintainers may require it. It is<br />
optional at this time so that it can be evaluated as to its usefulness over<br />
time. Existing patches will be updated with the tag as they are modified.<br />
<br />
As mentioned in the above, be sure to include any URL to bug tracking, mailing<br />
lists or other reference material pertaining to the patch. Then add a new tag<br />
"Upstream-Status:" which contains one of the following items:<br />
<br />
'''Pending'''<br />
- No determination has been made yet or not yet submitted to upstream<br />
<br />
'''Submitted''' [where]<br />
- Submitted to upstream, waiting approval<br />
- Optionally include where it was submitted, such as the author, mailing<br />
list, etc.<br />
<br />
'''Accepted'''<br />
- Accepted in upstream, expect it to be removed at next update, include<br />
expected version info<br />
<br />
'''Backport'''<br />
- Backported from new upstream version, because we are at a fixed version,<br />
include upstream version info<br />
<br />
'''Denied'''<br />
- Not accepted by upstream, include reason in patch<br />
<br />
'''Inappropriate [reason]'''<br />
- The patch is not appropriate for upstream, include a brief reason on the<br />
same line enclosed with []<br />
reason can be:<br />
not author (You are not the author and do not intend to upstream this,<br />
source must be listed in the comments)<br />
native<br />
licensing<br />
configuration<br />
enable feature<br />
disable feature<br />
bugfix (add bug URL here)<br />
embedded specific<br />
no upstream (the upstream is no longer available -- dead project)<br />
other (give details in comments)<br />
<br />
The various "Inappropriate [reason]" status items are meant to indicate that the<br />
person responsible for adding this patch to the system does not intend to<br />
upstream the patch for a specific reason. Unless otherwise noted, another<br />
person could submit this patch to the upstream, if they do the status should be<br />
changed to "Submitted [where]", and an additional Signed-off-by: line added to<br />
the patch by the person claiming responsibility for upstreaming.<br />
<br />
For example, if the patch has been submitted upstream:<br />
<br />
rpm: Adjusted the foo setting in bar<br />
<br />
<nowiki>[RPM Ticket #65] -- http://rpm5.org/cvs/tktview?tn=65,5</nowiki><br />
<br />
The foo setting in bar was decreased from X to X-50% in order to<br />
ensure we don't exhaust all system memory with foobar threads.<br />
<br />
Upstream-Status: Submitted [rpm5-devel@rpm5.org]<br />
<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
A future commit can change the value to "Accepted" or "Denied" as appropriate.<br />
<br />
=== CVE Patches ===<br />
<br />
In order to have a better control of vulnerabilities, patches that fix CVEs must contain the "CVE:" tag. This tag list all CVEs fixed by the patch. If more than one CVE is fixed, separate them using spaces.<br />
<br />
==== Example: CVE patch header ====<br />
<br />
This should be the header of patch that fixes grub2 CVE-2015-8370:<br />
<br />
grub2: Fix CVE-2015-8370<br />
<br />
<nowiki>[No upstream tracking] -- https://bugzilla.redhat.com/show_bug.cgi?id=1286966</nowiki><br />
<br />
Back to 28; Grub2 Authentication<br />
<br />
Two functions suffer from integer underflow fault; the grub_username_get() and grub_password_get()located in<br />
grub-core/normal/auth.c and lib/crypto.c respectively. This can be exploited to obtain a Grub rescue shell.<br />
<br />
<nowiki>Upstream-Status: Accepted [http://git.savannah.gnu.org/cgit/grub.git/commit/?id=451d80e52d851432e109771bb8febafca7a5f1f2]</nowiki><br />
CVE: CVE-2015-8370<br />
Signed-off-by: Joe Developer <joe.developer@example.com><br />
<br />
== Common Errors in Patch and Commit Messages ==<br />
<br />
- Short log does not start with the file or component being modified. Such as<br />
"foo: Update to new upstream version 5.8.9"<br />
<br />
- Avoid starting the summary line with a capital letter, unless the component<br />
being referred to also begins with a capital letter.<br />
<br />
- Don't have one huge patch, split your change into logical subparts. It's<br />
easier to track down problems afterward using tools such as git bisect. It also<br />
makes it easy for people to cherry-pick changes into things like stable branches.<br />
<br />
- Don't simply translate your change into English for a commit log. The log<br />
"Change compare from zero to one" is bad because it describes only the code<br />
change in the patch; we can see that from reading the patch itself. Let the code<br />
tell the story of the mechanics of the change (as much as possible), and let<br />
your comment tell the other details -- i.e. what the problem was, how it<br />
manifested itself (symptoms), and if necessary, the justification for why the<br />
fix was done in manner that it was. In other words, the long commit message<br />
must describe *why* the change was needed (instead of what has changed).<br />
<br />
- Don't start your commit log with "This patch..." -- we already know it is a patch.<br />
<br />
- Don't repeat your short log in the long log. If you really really don't have<br />
anything new and informational to add in as a long log, then don't put a long<br />
log at all. This should be uncommon -- i.e. the only acceptable cases for no<br />
long log would be something like "Documentation/README: Fix spelling mistakes".<br />
<br />
- Don't put absolute paths to source files that are specific to your site, i.e.<br />
if you get a compile error on "fs/exec.c" then tidy up the parts of the compile<br />
output to just show that portion. We don't need to see that it was<br />
/home/wally/src/git/oe-core/meta/classes/insane.bbclass or similar - that full<br />
path has no value to others. Always reduce the path to something more<br />
meaningful, such as oe-core/meta/classes/insane.bbclass.<br />
<br />
- Always use the most significant ramification of the change in the words of<br />
your subject/shortlog. For example, don't say "fix compile warning in foo" when<br />
the compiler warning was really telling us that we were dereferencing complete<br />
garbage off in the weeds that could in theory cause an OOPS under some<br />
circumstances. When people are choosing commits for backports to stable or<br />
distro kernels, the shortlog will be what they use for an initial sorting<br />
selection. If they see "Fix possible OOPS in...." then these people will look<br />
closer, whereas they most likely will skip over simple warning fixes.<br />
<br />
- Don't put in the full 20 or more lines of a backtrace when really it is just<br />
the last 5 or so function calls that are relevant to the crash/fix. If the entry<br />
point, or start of the trace is relevant (i.e. a syscall or similar), you can<br />
leave that, and then replace a chunk of the intermediate calls in the middle<br />
with a single [...]<br />
<br />
- Don't include timestamps or other unnecessary information, unless they are<br />
relevant to the situation (i.e. indicating an unacceptable delay in a driver<br />
initialization etc.)<br />
<br />
- Don't use links to temporary resources like pastebin and friends. The commit<br />
message may be read long after this resource timed out.<br />
<br />
- Don't reference mirrors, but instead always reference original authoritative<br />
sources.<br />
<br />
- Avoid punctuation in the short log.<br />
<br />
[[Category:Policy]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDEM_2019&diff=10598OEDEM 20192019-10-01T15:52:23Z<p>Rpurdie: </p>
<hr />
<div>== Location and Time ==<br />
<br />
Friday, 1 November 2019 (Part of Yocto Project Summit after ELCE [October 31 - November 1])<br><br />
OEDEM is on Day 2 of the Summit, November 1.<br />
<br />
Details on the Yocto Project Summit are here https://wiki.yoctoproject.org/wiki/Yocto_Project_Summit_2019.<br />
And the registration link https://www.cvent.com/events/yocto-project-summit-2019/registration-f185462e4bb240fea6364d2db7a270f4.aspx?fqp=true<br />
<br />
== Logistics ==<br />
<br />
<br />
== Remote conference link ==<br />
<br />
<br />
== Planning to Attend ==<br />
<br />
# Philip Balister (Crofton) [XL]<br />
# Peter Kjellerstedt (Saur) [3XL]<br />
# Ola Nilsson (olani) [M]<br />
# Marco Cavallini (mckoan) [M]<br />
# Jon Mason (jonmason) [M]<br />
# Josef Holzmayr (LetoThe2nd) [XL]<br />
# Mark Hatle (fray) [XL]<br />
# Khem Raj (khem) [M]<br />
# Scott Murray (smurray) [2XL]<br />
# Matt Porter (mdp)<br />
# Michael Halstead (halstead)<br />
# Andrea Galbusera (gizero) [M]<br />
# Paul Barker (paulbarker)<br />
# Jan-Simon Möller [2XL]<br />
# Richard Purdie (RP) [L]<br />
# Alexander Kanavin (kanavin) t-shirt size S<br />
# Mauro Salvini [M]<br />
# Manjukumar [S]<br />
# Alejandro Hernandez [M]<br />
# Jan Lübbe (shoragan) [XL]<br />
# Behan Webster (behanw) [3XL]<br />
# Ruslan Bilovol (rbilovol) [XL]<br />
# Grygorii Tertychnyi (gtertych) [L]<br />
# Bruce Ashfield (zeddii) [XL]<br />
# Daniel Gomez (dagmcr) [L]<br />
<br />
== Agenda Items ==<br />
<br />
=== OE Developers Meeting ===<br />
<br />
# Review and discuss talks from the Yocto Project Summit the day before.<br />
# Clean-up of wiki and meta layer index<br />
# Ways to recognize corporate sponsors and those who donate hardware (and/or money)<br />
# T-shirts?<br />
# How do we communicate with users better? Not everyone is on mailing lists. Social Media?<br />
# Results of the Yocto/Openembedded new features survey (http://bit.ly/2kXvdsd)<br />
<br />
=== Meeting minutes for OEDeM ===<br />
<br />
== Minutes ==<br />
<br />
SHARED MINUTES AT<br />
<br />
ACTIONS identified in meeting:<br />
<br />
=== Prior minutes ===<br />
<br />
Minutes from Edinburgh, Oct 2018:<br />
https://docs.google.com/document/d/1YDAHjIOXCIgvSZVOKCYLxa8h26dkruX8zspoge7zCpk/<br />
<br />
Minutes from Portland, Mar 2018:<br />
https://docs.google.com/document/d/1h_otwcH-6ej4URB5vER-7FpaPthrji3TpJWf5jAKRIk/edit?usp=sharing<br />
<br />
Minutes from Prague, Oct 2017:<br />
https://docs.google.com/document/d/1R_pV_PumhZ9a8_aRDTuW7wBjqNwIDuau7FGr6sYYRu0/edit?usp=sharing<br />
<br />
Minutes from Portland, Feb 2017:<br />
https://docs.google.com/document/d/1ECCfBwdLUaW3I23RATWCU3kGnSh04Kv0DkH1_KfiLVA/edit?usp=sharing</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDEM_2019&diff=10571OEDEM 20192019-09-16T22:22:59Z<p>Rpurdie: </p>
<hr />
<div>== Location and Time ==<br />
<br />
Friday, 1 November 2019 (Part of Yocto Project Summit after ELCE [October 31 - November 1])<br><br />
OEDEM is on Day 2 of the Summit, November 1.<br />
<br />
== Logistics ==<br />
<br />
<br />
== Remote conference link ==<br />
<br />
<br />
== Planning to Attend ==<br />
<br />
# Philip Balister (Crofton) [XL]<br />
# Peter Kjellerstedt (Saur)<br />
# Ola Nilsson (olani)<br />
# Marco Cavallini (mckoan) [M]<br />
# Jon Mason (jonmason)<br />
# Josef Holzmayr (LetoThe2nd)<br />
# Mark Hatle (fray)<br />
# Scott Murray (smurray)<br />
# Matt Porter (mdp)<br />
# Michael Halstead (halstead)<br />
# Andrea Galbusera (gizero)<br />
# Paul Barker (paulbarker)<br />
# Jan-Simon Möller<br />
# Richard Purdie (RP) [M]<br />
# Alexander Kanavin (kanavin) t-shirt size S<br />
# Mauro Salvini [M]<br />
# Manjukumar [S]<br />
# Alejandro Hernandez [M]<br />
<br />
== Agenda Items ==<br />
<br />
=== OE Developers Meeting ===<br />
<br />
# Review and discuss talks from the Yocto Project Summit the day before.<br />
# Clean-up of wiki and meta layer index<br />
# Ways to recognize corporate sponsors and those who donate hardware (and/or money)<br />
# T-shirts?<br />
# How do we communicate with users better? Not everyone is on mailing lists.<br />
<br />
=== Meeting minutes for OEDeM ===<br />
<br />
== Minutes ==<br />
<br />
SHARED MINUTES AT<br />
<br />
ACTIONS identified in meeting:<br />
<br />
=== Prior minutes ===<br />
<br />
Minutes from Edinburgh, Oct 2018:<br />
https://docs.google.com/document/d/1YDAHjIOXCIgvSZVOKCYLxa8h26dkruX8zspoge7zCpk/<br />
<br />
Minutes from Portland, Mar 2018:<br />
https://docs.google.com/document/d/1h_otwcH-6ej4URB5vER-7FpaPthrji3TpJWf5jAKRIk/edit?usp=sharing<br />
<br />
Minutes from Prague, Oct 2017:<br />
https://docs.google.com/document/d/1R_pV_PumhZ9a8_aRDTuW7wBjqNwIDuau7FGr6sYYRu0/edit?usp=sharing<br />
<br />
Minutes from Portland, Feb 2017:<br />
https://docs.google.com/document/d/1ECCfBwdLUaW3I23RATWCU3kGnSh04Kv0DkH1_KfiLVA/edit?usp=sharing</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDEM_2019&diff=10562OEDEM 20192019-09-14T22:35:57Z<p>Rpurdie: /* Planning to Attend */</p>
<hr />
<div>== Location and Time ==<br />
<br />
Friday, 1 November 2019 (Part of Yocto Project Summit after ELCE [October 31 - November 1])<br><br />
OEDEM is on Day 2 of the Summit, November 1.<br />
<br />
== Logistics ==<br />
<br />
<br />
== Remote conference link ==<br />
<br />
<br />
== Planning to Attend ==<br />
<br />
# Philip Balister (Crofton)<br />
# Peter Kjellerstedt (Saur)<br />
# Ola Nilsson (olani)<br />
# Marco Cavallini (mckoan)<br />
# Jon Mason (jonmason)<br />
# Josef Holzmayr (LetoThe2nd)<br />
# Mark Hatle (fray)<br />
# Scott Murray (smurray)<br />
# Matt Porter (mdp)<br />
# Michael Halstead (halstead)<br />
# Andrea Galbusera (gizero)<br />
# Paul Barker (paulbarker)<br />
# Jan-Simon Möller<br />
# Richard Purdie (RP)<br />
<br />
== Agenda Items ==<br />
<br />
=== OE Developers Meeting ===<br />
<br />
# Review and discuss talks from the Yocto Project Summit the day before.<br />
# Clean-up of wiki and meta layer index<br />
# Ways to recognize corporate sponsors and those who donate hardware (and/or money)<br />
# T-shirts?<br />
<br />
=== Meeting minutes for OEDeM ===<br />
<br />
== Minutes ==<br />
<br />
SHARED MINUTES AT<br />
<br />
ACTIONS identified in meeting:<br />
<br />
=== Prior minutes ===<br />
<br />
Minutes from Edinburgh, Oct 2018:<br />
https://docs.google.com/document/d/1YDAHjIOXCIgvSZVOKCYLxa8h26dkruX8zspoge7zCpk/<br />
<br />
Minutes from Portland, Mar 2018:<br />
https://docs.google.com/document/d/1h_otwcH-6ej4URB5vER-7FpaPthrji3TpJWf5jAKRIk/edit?usp=sharing<br />
<br />
Minutes from Prague, Oct 2017:<br />
https://docs.google.com/document/d/1R_pV_PumhZ9a8_aRDTuW7wBjqNwIDuau7FGr6sYYRu0/edit?usp=sharing<br />
<br />
Minutes from Portland, Feb 2017:<br />
https://docs.google.com/document/d/1ECCfBwdLUaW3I23RATWCU3kGnSh04Kv0DkH1_KfiLVA/edit?usp=sharing</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDEM_2018&diff=10313OEDEM 20182018-06-28T22:09:00Z<p>Rpurdie: </p>
<hr />
<div>== Location and Time ==<br />
<br />
Sunday, 21 October 2018 (before ELCE [October 22-24])<br><br />
Exact location TBA<br><br />
Expectation is to finish by 1800<br />
<br />
== Logistics ==<br />
<br />
Yes, we know it is Sunday. Best we could do this year.<br />
<br />
<br />
== Remote conference link ==<br />
<br />
<br />
== Planning to Attend ==<br />
<br />
* Philip Balister (Crofton)<br />
* Denys Dmytriyenko (denix)<br />
* Marco Cavallini (mckoan)<br />
* Jan Lübbe (shoragan)<br />
* Peter Kjellerstedt (Saur)<br />
* Jeff Osier-Mixon (Jefro)<br />
* Scott Murray (smurray)<br />
* Ruslan Bilovol<br />
* Phil Blundell<br />
* Ross Burton (rburton)<br />
* Richard Purdie (RP)<br />
<br />
== Agenda Items ==<br />
<br />
=== OE Developers Meeting ===<br />
<br />
== Minutes ==<br />
<br />
SHARED MINUTES AT<br />
<br />
ACTIONS identified in meeting:<br />
<br />
=== Prior minutes ===<br />
<br />
Minutes from Portland, Mar 2018:<br />
https://docs.google.com/document/d/1h_otwcH-6ej4URB5vER-7FpaPthrji3TpJWf5jAKRIk/edit?usp=sharing<br />
<br />
Minutes from Prague, Oct 2017:<br />
https://docs.google.com/document/d/1R_pV_PumhZ9a8_aRDTuW7wBjqNwIDuau7FGr6sYYRu0/edit?usp=sharing<br />
<br />
Minutes from Portland, Feb 2017:<br />
https://docs.google.com/document/d/1ECCfBwdLUaW3I23RATWCU3kGnSh04Kv0DkH1_KfiLVA/edit?usp=sharing</div>Rpurdiehttps://www.openembedded.org/index.php?title=2018_05_General_Meeting&diff=102572018 05 General Meeting2018-05-15T14:46:38Z<p>Rpurdie: /* Planning to attend */</p>
<hr />
<div>== Purpose ==<br />
The board would like to have another general meeting among OpenEmbedded members to discuss current events and hear any concerns.<br />
<br />
== Date and Time ==<br />
2017-05-21 @ 8am US-CDT(UTC-06:00)/3pm CET(UTC+01:00)<br />
<br />
[https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180521T1400 get the date/time in your timezone]<br />
<br />
[https://www.timeanddate.com/countdown/generic?p0=1440&iso=20180521T14 countdown]<br />
<br />
== Shared Minutes/Notes ==<br />
TBD<br />
<br />
== Teleconference Information ==<br />
<br />
Meeting will be held as a teleconference with a IRC channel to allow for background discussion and trouble shooting of audio.<br />
<br />
IRC: #oe-meeting on freenode<br />
<br />
'''Dial-in Conference'''<br />
<br />
WebEx<br />
<br />
https://montavista.webex.com/montavista/j.php?MTID=m0e22cedefc81fb61717657aaf9311c7b<br />
<br />
'''Monday, May 21, 2018'''<br />
<br />
6:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 1 hr<br />
<br />
'''Meeting number (access code):''' 809 423 572<br />
<br />
'''Meeting password''': bgiaq292<br />
<br />
'''Audio connection:'''<br />
<br />
1-866-469-3239 Call-in toll-free number (US/Canada)<br />
<br />
1-650-429-3300 Call-in toll number (US/Canada)<br />
<br />
Global call-in numbers: [https://montavista.webex.com/cmp3300/webcomponents/widget/globalcallin/globalcallin.do?siteurl=montavista&serviceType=MC&eventID=686011287&tollFree=1]<br />
Show toll-free dialing restrictions: [https://www.webex.com/pdf/tollfree_restrictions.pdf]<br />
<br />
== Tentative Agenda ==<br />
# Current events<br />
# Concerns<br />
# General discussion<br />
<br />
== Planning to attend ==<br />
* Denys Dmytriyenko (denix)<br />
* Sean Hudson (darknighte)<br />
* Paul Barker (paulbarker)<br />
* Ross Burton (rburton)<br />
* Richard Purdie (RP)</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDAM_2018&diff=10135OEDAM 20182018-02-23T17:18:23Z<p>Rpurdie: /* Planning to Attend */</p>
<hr />
<div>== Location and Time ==<br />
<br />
Sunday, 11 March 2018 (before ELC [March 12-14])<br><br />
Board meeting to start at 09:30<br />
Developer's meeting to start at 10:30<br />
Expectation is to finish by 1800<br />
<br />
Lunch is provided<br />
<br />
Location: Mentor Graphics Headquarters, Wilsonville, OR<br />
Carpooling is encouraged, see below<br />
<br />
Yes, we know it is Sunday. Best we could do this year.<br />
<br />
== Planning to Attend ==<br />
<br />
Carpool note: Please add a {#} after your name if you plan to drive and can take # of people in your car other than yourself<br />
<br />
* Jeff Osier-Mixon "Jefro" {4}<br />
* Philip Balister (Crofton)<br />
* Denys Dmytriyenko (denix)<br />
* Sean Hudson (darknighte)<br />
* Manjukumar Matha (manju)<br />
* Joshua Watt (JPEWhacker)<br />
* Zachary Booth<br />
* Jim Lodes<br />
* Armin Kuster (Armpit){15}<br />
* Scott Murray (smurray)<br />
* Tim Orling (moto-timo)<br />
* Alejandro Hernandez (aehs29)<br />
* Christopher Clark<br />
* Behan Webster (behanw)<br />
* Marek Vasut (Marex)<br />
* Taras Kondratiuk<br />
* Bill Mills<br />
* Ricardo Salveti (rsalveti)<br />
* Khem Raj (khem)<br />
* Tom King (ka6sox)<br />
* Rich Persaud<br />
* Michael Halstead (halstead)<br />
* Stephano Cetola (stephano) {1 + truck bed }<br />
* Richard Purdie (RP)<br />
<br />
== Agenda Items ==<br />
<br />
=== OE Board ===<br />
E.v status<br />
<br />
=== OE Developers Meeting ===<br />
# Discuss meta-oe release process<br />
# World build monitoring and automatic notifications<br />
<br />
== Minutes ==<br />
<br />
<br />
<br />
=== Prior minutes ===<br />
<br />
Minutes from Prague, Oct 2017:<br />
https://docs.google.com/document/d/1R_pV_PumhZ9a8_aRDTuW7wBjqNwIDuau7FGr6sYYRu0/edit?usp=sharing<br />
<br />
Minutes from Portland, Feb 2017:<br />
https://docs.google.com/document/d/1ECCfBwdLUaW3I23RATWCU3kGnSh04Kv0DkH1_KfiLVA/edit?usp=sharing</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDEM_2017&diff=9709OEDEM 20172017-09-05T21:32:49Z<p>Rpurdie: /* Attendees */</p>
<hr />
<div>== Location and Time ==<br />
<br />
Sunday, 22 October 2017<br><br />
(before ELC-E [Oct 23-25])<br />
<br />
Yes, we know it is Sunday. Best we could do this year.<br />
<br />
Hilton Prague - Prague, Czech Republic<br />
Start at 0900<br />
<br />
== Attendees ==<br />
<br />
* Jeff Osier-Mixon "Jefro"<br />
* Behan Webster (behanw)<br />
* Philip Balister (Crofton)<br />
* Martin Jansa (JaMa)<br />
* Scott Murray (smurray)<br />
* Peter Kjellerstedt (Saur)<br />
* Armin Kuster (Armpit)<br />
* Marco Cavallini (mckoan)<br />
* Paul Barker (paulbarker)<br />
* Myunghun Chun<br />
* Changhyeok Bae (chbae)<br />
* Adrian Ratiu (aratiu)<br />
* Josef Holzmayr (LetoThe2nd)<br />
* Jan Leupold<br />
* Anders Darander <br />
* Sean Hudson (darknighte)<br />
* Tim Orling (moto-timo)<br />
* Ricardo Ribalda (ribalda)<br />
* Nicolas Dechesne (ndec)<br />
* Richard Purdie (RP)<br />
<br />
NOTE: we will make every effort to provide a web/phone link for remote attendees<br />
<br />
== Agenda Items ==<br />
<br />
# Stack Overflow report (From someone who regularly watches stackoverflow)<br />
# Demos for FOSDEM and other events. Good chance to (discretely) show your companies work. (Philip)<br />
<br />
== Minutes ==<br />
<br />
=== OEDEM: ===</div>Rpurdiehttps://www.openembedded.org/index.php?title=2017_General_Meeting&diff=94272017 General Meeting2017-05-01T10:39:36Z<p>Rpurdie: </p>
<hr />
<div>== Purpose ==<br />
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.<br />
<br />
== Date and Time ==<br />
'''!!!Tentative!!!''' 2017-05-03 @ 8am US-CDT(UTC-06:00)/3pm CET(UTC+01:00)<br />
<br />
Here's a link to the time:<br />
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+2017+General+Meeting&iso=20170503T08&p1=24&ah=1<br />
<br />
Countdown link:<br />
https://www.timeanddate.com/countdown/generic?p0=24&iso=20170503T08&msg=OpenEmbedded%202017%20General%20Meeting<br />
<br />
<br />
== Conference Information ==<br />
<br />
Meeting will be held as a teleconference with a IRC channel to allow for background discussion and trouble shooting of audio.<br />
<br />
IRC: #oe-meeting on freenode<br />
<br />
'''Dial-in Conference # 8964521'''<br />
<br />
{| class="wikitable"<br />
!colspan="3"|Dial-in Information<br />
|-<br />
| Country<br />
| Toll Free Number(s)<br />
| Toll Number(s)<br />
|-<br />
|UNITED STATES(USA)<br />
|8006375822<br />
|6477233937<br />
9172102607<br />
|-<br />
|-<br />
|ARGENTINA(ARG)<br />
|8008000140<br />
|01159843238<br />
|-<br />
|AUSTRALIA(AUS)<br />
|1800706813<br />
|0390084306<br />
|-<br />
|AUSTRIA(AUT)<br />
|080088665126<br />
1800455064<br />
|<br />
|-<br />
|BELGIUM(BEL)<br />
|080039126<br />
|027924568<br />
|-<br />
|BRAZIL(BRA)<br />
|08000201594<br />
|<br />
|-<br />
|BULGARIA(BGR)<br />
|008001201150<br />
|<br />
|-<br />
|CANADA(CAN)<br />
|8006375822<br />
|6477233937<br />
|-<br />
|CHILE(CHL)<br />
|12300201190<br />
|225994308<br />
|-<br />
|CHINA NORTH(CHN)<br />
|108007140888<br />
|<br />
|-<br />
|CHINA SOUTH(CHS)<br />
|108001400863<br />
|<br />
|-<br />
|CHINA UNIFIED(CHU)<br />
|8008195002<br />
|4006201003<br />
|-<br />
|CZECH REPUBLIC(CZE)<br />
|800701563<br />
|234147032<br />
|-<br />
|DENMARK(DNK)<br />
|80703176<br />
|36910500<br />
|-<br />
|EGYPT(EGY)<br />
|08000000216<br />
|<br />
|-<br />
|FINLAND(FIN)<br />
|0800114187<br />
0800773408<br />
|0923194205<br />
|-<br />
|FRANCE(FRA)<br />
|0800941758<br />
|<br />
|-<br />
|GERMANY(DEU)<br />
|08001014542<br />
|069710448206<br />
|-<br />
|HONG KONG(HKG)<br />
|800903520<br />
|30508648<br />
|-<br />
|HUNGARY(HUN)<br />
|0680018377<br />
|<br />
|-<br />
|INDIA(IND)<br />
|0008001006237<br />
0008006501628<br />
<br />
18002660806<br />
|<br />
|-<br />
|IRELAND(IRL)<br />
|1800760168<br />
1800944117<br />
|014360203<br />
|-<br />
|ISRAEL(ISR)<br />
|1809245898<br />
|<br />
|-<br />
|ITALY(ITA)<br />
|800785295<br />
|<br />
|-<br />
|JAPAN(JPN)<br />
|00531160557<br />
00531190046<br />
|0345899489<br />
|-<br />
|MALAYSIA(MYS)<br />
|1800814332<br />
|<br />
|-<br />
|MEXICO(MEX)<br />
|0018005148003<br />
|5547772297<br />
|-<br />
|MOROCCO(MAR)<br />
|002110011 8553458162<br />
|<br />
|-<br />
|NETHERLANDS(NLD)<br />
|08002658235<br />
|0207940366<br />
|-<br />
|NEW ZEALAND(NZL)<br />
|0800453014<br />
|049094653<br />
|-<br />
|NORWAY(NOR)<br />
|80056416<br />
|21033210<br />
|-<br />
|PAKISTAN(PAK)<br />
|<br />
|4238108701<br />
|-<br />
|PHILIPPINES(PHL)<br />
|180011100869<br />
|<br />
|-<br />
|POLAND(POL)<br />
|008001114760<br />
800702736<br />
|223060765<br />
|-<br />
|PORTUGAL(PRT)<br />
|800780647<br />
|<br />
|-<br />
|ROMANIA(ROM)<br />
|0800400060<br />
0800400906<br />
|215291724<br />
|-<br />
|RUSSIAN FEDERATION(RUS)<br />
|81080025401012<br />
|4959952645<br />
|-<br />
|SAUDI ARABIA(SAU)<br />
|8008149944<br />
|<br />
|-<br />
|SINGAPORE(SGP)<br />
|8001011714<br />
8001205024<br />
|64944153<br />
|-<br />
|SLOVAKIA(SVK)<br />
|0800606530<br />
|<br />
|-<br />
|SOUTH KOREA(KOR)<br />
|00308140655<br />
|<br />
|-<br />
|SPAIN(ESP)<br />
|900947050<br />
|<br />
|-<br />
|SWEDEN(SWE)<br />
|0201400572<br />
|0114501530<br />
|-<br />
|SWITZERLAND(CHE)<br />
|0800561819<br />
0800705314<br />
|0434569423<br />
|-<br />
|TAIWAN(TWN)<br />
|0809090682<br />
|<br />
|-<br />
|UNITED ARAB EMIRATES(ARE)<br />
|8000176692<br />
|<br />
|-<br />
|UNITED KINGDOM(GBR)<br />
|08006920143<br />
|2070840301<br />
|-<br />
|}<br />
<br />
<br />
== Tentative Agenda ==<br />
# Meeting Schedule<br />
## The board would like to propose a quarterly meeting schedule with alternating online and face-to-face meetings.<br />
# Membership<br />
## Grandfathered all existing members in good standing<br />
## New members<br />
# TSC<br />
## Grandfathered from old organization<br />
# Online voting<br />
# Elections<br />
# Future plans/purpose for the organization<br />
# Technical topics<br />
<br />
== Planning to attend ==<br />
* Sean Hudson (irc:darknighte)<br />
* Denys Dmytriyenko (denix)<br />
* Bruce Ashfield (zeddii*)<br />
* Armin Kuster (armpit)<br />
* Mark Hatle (fray)<br />
* Tom Rini (Tartarus)<br />
* Trevor Woerner (tlwoerner)<br />
* Ross Burton (rburton)<br />
* Stephano Cetola (stephano)<br />
* Richard Purdie (RP)</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDAM_2017&diff=9311OEDAM 20172017-02-20T03:17:13Z<p>Rpurdie: </p>
<hr />
<div>== Location and Time ==<br />
<br />
Monday February 20 2017<br />
<br />
Location:<br/><br />
Mentor Graphics<br/><br />
8005 Boeckman Rd<br/><br />
Wilsonville, OR 97070<br/><br />
Phone: (800) 547-3000<br/><br />
9am-5pm<br/><br />
<br />
(Before ELC [Feb 21-23] and Yocto Project Developer Day [Feb 24])<br />
<br />
Current transportation plan is meet in the Hilton Lobby at 0800. From there we will use Lyft/Uber/other in as efficient way as possible.<br />
<br />
== Attendees ==<br />
<br />
* Armin Kuster (armpit)<br />
* Philip Balister (Crofton)<br />
* Trevor Woerner (tlwoerner)<br />
* Denys Dmytriyenko (denix)<br />
* Stephano Cetola<br />
* Matthew McClintock<br />
* Tim Orling (moto-timo)<br />
* James Perkins (jamesp)<br />
* Patrick Ohly (pohly)<br />
* Richard Purdie (RP)<br />
* Mark Hatle (fray)<br />
* Jan-Simon Möller (dl9pf)<br />
* Derek Straka<br />
* Scott Murray (scottm)<br />
* Ken Sharp<br />
* Behan Webster (behanw)<br />
* Brian Avery (bavery)<br />
* Saul Wold (sgw)<br />
<br />
== Agenda Items ==<br />
<br />
* Review items from last meeting in Berlin (Please add remarks)<br />
* Proposal (Patrick): "production" vs. "development" builds and features<br />
* Proposal (Patrick): stateless distro<br />
* Proposal (Patrick): GPLv3 handling - remove recipes for obsolete components, replace with adaptive recipe and image configurations (like disabling readline support)<br />
* Proposal (Patrick): remove openembedded-devel@lists.openembedded.org Reply-To?<br />
* Discuss recruiting new layer maintainers for meta-oe and what a maintainer does.<br />
<br />
=== Berlin AR's ===<br />
<br />
==== LTS ====<br />
<br />
Yocto-Compatibility requires pushing patches upstream, but Yocto doesn't handle QA for old releases<br />
A lot of work for the software vendors<br />
rp: have new/separate LTS tree for older releases<br />
crofton: how to coordinate between ppl who want this, collect interest in the wiki<br />
add maintainer information to the layer repos?<br />
rp: write a proposal?<br />
→ enough interest to set this up<br />
<br />
action: Armin will start conversation on the Architecture list <br />
'''Not completed<br />
'''<br />
<br />
==== Windriver ‘setup’ Demo ====<br />
Conclusion: We want it in OE instead of Yocto (unanimous) <br />
Mark: Once able to contribute, talk to halstead for new repo.<br />
'''Repo published. OE has not taken over'''<br />
<br />
Notes: Layer Index was recently updated and this was required before progress can be made on promoting this tool.<br />
<br />
I would like to talk about the next steps at the OEDAM, now that everything is public.<br />
<br />
==== Devtool and other stuff (10:04) ====<br />
Sysroot-Contamination<br />
rp: solution “sysroot per recipe”<br />
<br />
<br />
==== Suggestion for improvement of how to handle site and user configuration. ====<br />
Conclusion: Saur will implement the BBPATH_EXTRA and discuss it on the list.<br />
<br />
==== BSPs and layer name recommendations ====<br />
RP: We can do this by … For Compatible v2 we want to raise the bar. Sanity check for things that keep breaking.<br />
Conclusion: Jan-Simon will start a script check the basic stuff, RP should add the checksum checks.<br />
<br />
==== OTA ====<br />
RP: This discussion needs to continue beyond OEDEM<br />
<br />
<br />
==== Layer Quality ====<br />
Conclusion: We need to get the word out and get suggestions.<br />
<br />
<br />
==== Make perl and python distro features? [Saur] ====<br />
Conclusion: No change.<br />
<br />
<br />
==== Support for meson build system? [Saur] ====<br />
Conclusion: Patches welcome, talk to Ross.<br />
<br />
<br />
==== The use of ${COREBASE}/LICENSE in LIC_FILES_CHKSUM. [Saur] ====<br />
Conclusion: RP: This needs to go to the ML<br />
<br />
<br />
==== Discuss merging duplicate classes and recipes (metadata) ====<br />
Conclusion: Duplicate recipes and machines need to be brought up with the maintainers.<br />
<br />
Conclusion: Mark, RP, Chris and others should look to create a proposal about resolving the confusion over layer order/priority/etc.<br />
<br />
<br />
==== Changes to deploy_image ====<br />
Conclusion: Document<br />
<br />
<br />
==== Discussion on mesa and splitting libgbm ====<br />
Conclusion: RP: Topic should be discussed with Ross on mailing list.<br />
<br />
==== Discussion of recipe maintainers for oe-core and beyond ====<br />
RP: This list is a Yocto initiative. They try to get more involvement from the members. There is an incentive to get more ppl involved (recipe reporting system):<br />
<br />
== Minutes ==</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDAM_2017&diff=9301OEDAM 20172017-02-16T23:47:19Z<p>Rpurdie: /* Attendees */</p>
<hr />
<div>== Location and Time ==<br />
<br />
Monday February 20 2017<br />
<br />
Location:<br/><br />
Mentor Graphics<br/><br />
8005 Boeckman Rd<br/><br />
Wilsonville, OR 97070<br/><br />
Phone: (800) 547-3000<br/><br />
9am-5pm<br/><br />
<br />
(Before ELC [Feb 21-23] and Yocto Project Developer Day [Feb 24])<br />
<br />
== Attendees ==<br />
<br />
* Armin Kuster (armpit)<br />
* Philip Balister (Crofton)<br />
* Trevor Woerner (tlwoerner)<br />
* Denys Dmytriyenko (denix)<br />
* Stephano Cetola<br />
* Matthew McClintock<br />
* Tim Orling (moto-timo)<br />
* James Perkins (jamesp)<br />
* Patrick Ohly (pohly)<br />
* Richard Purdie (RP)<br />
* Mark Hatle (fray)<br />
* Jan-Simon Möller (dl9pf)<br />
* Derek Straka<br />
* Scott Murray (scottm)<br />
* Ken Sharp<br />
* Behan Webster (behanw)<br />
* Brian Avery (bavery)<br />
<br />
== Agenda Items ==<br />
<br />
* Review items from last meeting in Berlin (Please add remarks)<br />
* Proposal (Patrick): stateless distro<br />
* Proposal (Patrick): GPLv3 handling - remove recipes for obsolete components, replace with adaptive recipe and image configurations (like disabling readline support)<br />
* Proposal (Patrick): remove openembedded-devel@lists.openembedded.org Reply-To?<br />
<br />
=== Berlin AR's ===<br />
<br />
==== LTS ====<br />
<br />
Yocto-Compatibility requires pushing patches upstream, but Yocto doesn't handle QA for old releases<br />
A lot of work for the software vendors<br />
rp: have new/separate LTS tree for older releases<br />
crofton: how to coordinate between ppl who want this, collect interest in the wiki<br />
add maintainer information to the layer repos?<br />
rp: write a proposal?<br />
→ enough interest to set this up<br />
<br />
action: Armin will start conversation on the Architecture list <br />
'''Not completed<br />
'''<br />
<br />
==== Windriver ‘setup’ Demo ====<br />
Conclusion: We want it in OE instead of Yocto (unanimous) <br />
Mark: Once able to contribute, talk to halstead for new repo.<br />
'''Repo published. OE has not taken over'''<br />
<br />
Notes: Layer Index was recently updated and this was required before progress can be made on promoting this tool.<br />
<br />
I would like to talk about the next steps at the OEDAM, now that everything is public.<br />
<br />
==== Devtool and other stuff (10:04) ====<br />
Sysroot-Contamination<br />
rp: solution “sysroot per recipe”<br />
<br />
<br />
==== Suggestion for improvement of how to handle site and user configuration. ====<br />
Conclusion: Saur will implement the BBPATH_EXTRA and discuss it on the list.<br />
<br />
==== BSPs and layer name recommendations ====<br />
RP: We can do this by … For Compatible v2 we want to raise the bar. Sanity check for things that keep breaking.<br />
Conclusion: Jan-Simon will start a script check the basic stuff, RP should add the checksum checks.<br />
<br />
==== OTA ====<br />
RP: This discussion needs to continue beyond OEDEM<br />
<br />
<br />
==== Layer Quality ====<br />
Conclusion: We need to get the word out and get suggestions.<br />
<br />
<br />
==== Make perl and python distro features? [Saur] ====<br />
Conclusion: No change.<br />
<br />
<br />
==== Support for meson build system? [Saur] ====<br />
Conclusion: Patches welcome, talk to Ross.<br />
<br />
<br />
==== The use of ${COREBASE}/LICENSE in LIC_FILES_CHKSUM. [Saur] ====<br />
Conclusion: RP: This needs to go to the ML<br />
<br />
<br />
==== Discuss merging duplicate classes and recipes (metadata) ====<br />
Conclusion: Duplicate recipes and machines need to be brought up with the maintainers.<br />
<br />
Conclusion: Mark, RP, Chris and others should look to create a proposal about resolving the confusion over layer order/priority/etc.<br />
<br />
<br />
==== Changes to deploy_image ====<br />
Conclusion: Document<br />
<br />
<br />
==== Discussion on mesa and splitting libgbm ====<br />
Conclusion: RP: Topic should be discussed with Ross on mailing list.<br />
<br />
==== Discussion of recipe maintainers for oe-core and beyond ====<br />
RP: This list is a Yocto initiative. They try to get more involvement from the members. There is an incentive to get more ppl involved (recipe reporting system):<br />
<br />
== Minutes ==</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDAM_2017&diff=9231OEDAM 20172017-01-19T13:31:58Z<p>Rpurdie: /* Attendees */</p>
<hr />
<div>== Location and Time ==<br />
<br />
Monday February 20 2017<br />
<br />
Location TBA<br />
<br />
(Before ELC [Feb 21-23] and Yocto Project Developer Day [Feb 24])<br />
<br />
== Attendees ==<br />
<br />
* Armin Kuster (armpit)<br />
* Philip Balister (Crofton)<br />
* Trevor Woerner (tlwoerner)<br />
* Denys Dmytriyenko (denix)<br />
* Stephano Cetola<br />
* Matthew McClintock<br />
* Tim Orling (moto-timo)<br />
* James Perkins (jamesp)<br />
* Patrick Ohly (pohly)<br />
* Richard Purdie (RP)<br />
<br />
== Agenda Items ==<br />
<br />
* Review items from last meeting in Berlin (Please add remarks)<br />
<br />
=== Berlin AR's ===<br />
<br />
==== LTS ====<br />
<br />
Yocto-Compatibility requires pushing patches upstream, but Yocto doesn't handle QA for old releases<br />
A lot of work for the software vendors<br />
rp: have new/separate LTS tree for older releases<br />
crofton: how to coordinate between ppl who want this, collect interest in the wiki<br />
add maintainer information to the layer repos?<br />
rp: write a proposal?<br />
→ enough interest to set this up<br />
<br />
action: Armin will start conversation on the Architecture list <br />
'''Not completed<br />
'''<br />
<br />
==== Windriver ‘setup’ Demo ====<br />
Conclusion: We want it in OE instead of Yocto (unanimous) <br />
Mark: Once able to contribute, talk to halstead for new repo.<br />
'''Repo published. OE has not taken over'''<br />
<br />
==== Devtool and other stuff (10:04) ====<br />
Sysroot-Contamination<br />
rp: solution “sysroot per recipe”<br />
<br />
<br />
==== Suggestion for improvement of how to handle site and user configuration. ====<br />
Conclusion: Saur will implement the BBPATH_EXTRA and discuss it on the list.<br />
<br />
==== BSPs and layer name recommendations ====<br />
RP: We can do this by … For Compatible v2 we want to raise the bar. Sanity check for things that keep breaking.<br />
Conclusion: Jan-Simon will start a script check the basic stuff, RP should add the checksum checks.<br />
<br />
==== OTA ====<br />
RP: This discussion needs to continue beyond OEDEM<br />
<br />
<br />
==== Layer Quality ====<br />
Conclusion: We need to get the word out and get suggestions.<br />
<br />
<br />
==== Make perl and python distro features? [Saur] ====<br />
Conclusion: No change.<br />
<br />
<br />
==== Support for meson build system? [Saur] ====<br />
Conclusion: Patches welcome, talk to Ross.<br />
<br />
<br />
==== The use of ${COREBASE}/LICENSE in LIC_FILES_CHKSUM. [Saur] ====<br />
Conclusion: RP: This needs to go to the ML<br />
<br />
<br />
==== Discuss merging duplicate classes and recipes (metadata) ====<br />
Conclusion: Duplicate recipes and machines need to be brought up with the maintainers.<br />
<br />
Conclusion: Mark, RP, Chris and others should look to create a proposal about resolving the confusion over layer order/priority/etc.<br />
<br />
<br />
==== Changes to deploy_image ====<br />
Conclusion: Document<br />
<br />
<br />
==== Discussion on mesa and splitting libgbm ====<br />
Conclusion: RP: Topic should be discussed with Ross on mailing list.<br />
<br />
==== Discussion of recipe maintainers for oe-core and beyond ====<br />
RP: This list is a Yocto initiative. They try to get more involvement from the members. There is an incentive to get more ppl involved (recipe reporting system):<br />
<br />
== Minutes ==</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDEM_2016&diff=8955OEDEM 20162016-09-09T18:16:39Z<p>Rpurdie: /* Attendees */</p>
<hr />
<div>NOTE: for the OpenEmbedded General Assembly 2016, held the same day at the same location, see the page [[Berlin, 2016]]<br />
<br />
== Location and Time ==<br />
<br />
Friday, October 14 2016<br><br />
(after ELC-E [Oct 11-13])<br />
<br />
Specific location in Berlin will be announced later<br />
<br />
== Attendees ==<br />
<br />
Khem Raj "khem"<br />
<br />
Armin Kuster "Armpit"<br />
<br />
Marco Cavallini "mckoan"<br />
<br />
Pierre-Jean Texier "pjtexier"<br />
<br />
Koen Kooi "koen"<br />
<br />
Anders Darander<br />
<br />
Sean Hudson "darknighte"<br />
<br />
Peter Kjellerstedt "Saur"<br />
<br />
Josef Holzmayr "LetoThe2nd"<br />
<br />
Vicentiu Neagoe<br />
<br />
Nicolas Dechesne "ndec"<br />
<br />
Denys Dmytriyenko "denix"<br />
<br />
Philip Balister "Crofton"<br />
<br />
Jan Lübbe "shoragan"<br />
<br />
Enrico Jörns<br />
<br />
Jeff Osier-Mixon "Jefro"<br />
<br />
Andrea Galbusera "gizero"<br />
<br />
Richard Purdie "RP"<br />
<br />
== Agenda Items ==<br />
<br />
OpenEmbedded eV General Assembly [[Berlin,_2016]]<br />
<br />
1) LTS<br />
2) BSPs and layer name recommendations<br />
<br />
== Minutes ==</div>Rpurdiehttps://www.openembedded.org/index.php?title=Berlin,_2016&diff=8953Berlin, 20162016-09-09T18:15:46Z<p>Rpurdie: /* Attendance */</p>
<hr />
<div><br />
= '''e.V. General Assembly (GA) Meeting for 2016''' =<br />
<br />
NOTE: for the OpenEmbedded Developer's European Meeting (OEDEM) 2016, held the same day at the same location, see the page [[OEDEM 2016]]<br />
<br />
==Location ==<br />
<br />
Berlin, Germany<br />
<br />
October 14, 2015 at 0900 - 1000<br />
<br />
== Agenda: General Assembly ==<br />
<br />
* Treasurer report<br />
* Update on eV status<br />
<br />
== Forms ==<br />
<br />
* Proxy form [[File:Proxy_instructions-oe.pdf]]<br />
<br />
== Attendance ==<br />
<br />
* Andrei Gherzan (agherzan)<br />
* Jeff Osier-Mixon (jefro)<br />
* Marco Cavallini (mckoan)<br />
* Anders Darander<br />
* Andrea Galbusera (gizero)<br />
* Richard Purdie (RP)</div>Rpurdiehttps://www.openembedded.org/index.php?title=User:JedOcn908632331&diff=8645User:JedOcn9086323312016-04-08T15:28:53Z<p>Rpurdie: Blanked the page</p>
<hr />
<div></div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDAM_2016&diff=8627OEDAM 20162016-04-02T16:38:58Z<p>Rpurdie: </p>
<hr />
<div>== Location and Time ==<br />
<br />
Friday April 8 2016 <br />
<br />
Catamaran Resort & Hotel<br><br />
3999 Mission Boulevard<br><br />
San Diego, CA 92109<br><br />
858-539-8727<br />
<br />
transportation will be provided, TBA<br />
(after ELC [Apr 4-6] and Yocto Project Developer Day [Apr 7])<br />
<br />
NOTE: this event is NOT going to be at the Marriott Marquis as previously announced<br />
<br />
== Attendees ==<br />
Armin Kuster (Armpit)<br><br />
Behan Webster (behanw)<br><br />
Denys Dmytriyenko (denix)<br><br />
Jan-Simon Möller (dl9pf)<br><br />
Philip Balister (Crofton|work)<br><br />
Sean Hudson (darknighte)<br><br />
Tim Orling (Moto-timo)<br><br />
Trevor Woerner<br><br />
Tom King (ka6sox)<br><br />
Mark Hatle (fray)<br><br />
Jeff Osier-Mixon (jefro)<br><br />
Frederick Ollinger (Follinge)<br><br />
Marc Villanueva (Tentative)<br><br />
Rudolf Streif (rstreif)<br><br />
Gratian Crisan<br><br />
Alejandro Hernandez (aehs29)<br><br />
Belén Barros Pena (belen)<br><br />
Scott Murray (smurray)<br><br />
Koen Kooi (koen)<br><br />
George McCollister (georgem)<br />
<br />
== Agenda Items ==<br />
<br />
* Review items from last meeting in Dublin (Please add remarks)<br />
<br />
===BSPs & Layer Index===<br />
* oe driving toward machine readable files, can also drive from layer<br />
test (yp compat) side - KK<br />
* publicize defs of each list? discuss on members list - where to<br />
overall architecture discussions belong<br />
* TSC to add new mailing list specifically about project<br />
architecture, no patches, and determine list name [Done]<br />
* KK bring discussion to new mailing list<br />
<br />
===BSP standards - standards exist,coming soon are methods for comparing===<br />
a given layer with the standard<br />
* need wiki documentation for TSC to ratify<br />
* document distro vs. machine policies, other best practices<br />
<br />
===BSP layer availability===<br />
* encourage board vendors to provide a BSP, make it easier to do so<br />
* ask yp ab to talk to linux.com [PB] - community issue<br />
* look at digi manual[http://www.digi.com/resources/documentation/digidocs/90001945-13/default.htm#task/yocto/t_customize_root_file_system_yocto.htm%3FTocPath%3DDigi%2520Embedded%2520Yocto%7CSystem%2520development%7CFirst%2520steps%7C_____3] (i.e. "just add bsp changes in local.conf"):<br />
<br />
===meta-yocto to meta-poky===<br />
* RP to take action on the YP side, possibly not for 2.0 [Done, rename happened]<br />
* formalize lowercase as mandatory requirement for overrides, look for other options in the future [Done]<br />
<br />
===Layer Index feature requests discussed with layer index build feedback>>===<br />
* ask for cycles from employers to work on these issues<br />
* make people aware, help with triage, provide resources<br />
<br />
===Security===<br />
* need a method for tracking CVs<br />
<br />
===Systemd===<br />
complaints: more package config, comments; look at packaging to have<br />
minimal systemd even with options available<br />
* need someone with time available to work on it<br />
* need to get systemd feedback, people using systemd talk to package maintainer<br />
* file systemctl wrapper bug<br />
<br />
===Advocacy===<br />
* board to discuss advocacy/community, invite jefro to meetings<br />
Potential OE Day at ELCE next year<br />
* board: do a proper cfp<br />
<br />
== Minutes ==</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDEM_2015&diff=7933OEDEM 20152015-10-09T06:57:13Z<p>Rpurdie: /* Attendees */</p>
<hr />
<div>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.<br />
<br />
== Location and Time ==<br />
<br />
[http://www.thegibsonhotel.ie/ The Gibson Hotel]<br><br />
Point Village<br><br />
Dublin 1, Ireland<br><br />
+353 1 681 5000<br />
<br />
9am - 5pm (note: times may change)<br />
<br />
== OpenEmbedded eV General Assembly ==<br />
<br />
We have a short administrative meeting before starting the Developer meeting. All are welcome for this.<br />
<br />
* Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project.<br />
* Define a method for identifying lapsed memberships.<br />
* Proxy form [[File:Proxy_instructions-oe.pdf]]<br />
<br />
== Agenda ==<br />
<br />
* Metadata<br />
** OVERRIDE syntax: is it time to reconsider _?<br />
** meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)<br />
<br />
* BSPs (tlwoerner)<br />
** Standards for BSP behavior. (Crofton)<br />
** feedback on layerindex to indicate BSP:<br />
*** last successful compile (feedback from outside builders?)<br />
*** last successful boot<br />
*** master branch parsability (perhaps ties into bugzilla 7792?)<br />
** several BSP layers to choose from for some boards, none for others (linux.com SBC survey)<br />
** guidelines/requirements for setting up a new BSP on layerindex<br />
*** bugzilla<br />
*** mailing list (use general mailing list(s) for patches?)<br />
*** git.yoctoproject.org/<yourbsplayer><br />
** making sure BSP layers only touch the variables/settings they should touch<br />
*** should a BSP layer ever use = ?<br />
** does/should a BSP produce artifacts that are easy to install to SD cards? (Crofton)<br />
<br />
*Processes<br />
** LayerIndex feature requests (tlwoerner)<br />
** build feedback (autobuilders and off-site)<br />
** Autobuilder failures (Bluelightening)<br />
<br />
*Systemd<br />
** Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info)<br />
** Can we get systemd's first-boot support to work? It is currently disabled in the systemd recipe by touching /etc/machine-id. (Saur)<br />
** How to make it easy to setup a system "the systemd way"? New DISTRO_FEATURE or IMAGE_FEATURE? (Saur)<br />
*** Link /bin -> /usr/bin, /lib -> /usr/lib, etc.<br />
*** Change ${systemd_unitdir} to /usr/lib.<br />
*** Make the systemctl wrapper install in ${systemd_unitdir} rather than ${systemconf}/systemd.<br />
**** This should also happen when installing a package in runtime.<br />
<br />
*Advocacy<br />
** There are still a lot of projects (too many?) not using OE (tlwoerner)<br />
** why aren't more projects using OE?<br />
** how can we get more people using OE?<br />
** who should we be targeting? (build people (obviously), kernel devs? user-space devs?)<br />
<br />
== Attendees ==<br />
<br />
If you plan to attend, please list your name below.<br />
<br />
# Jeff Osier-Mixon (jefro)<br />
# Philip Balister (Crofton)<br />
# Trevor Woerner (tlwoerner)<br />
# Anders Darander (andersd)<br />
# Marco Cavallini (mckoan)<br />
# Koen Kooi (koen)<br />
# Alexandre Belloni (abelloni)<br />
# Armin Kuster (armpit)<br />
# Belén Barros Pena (belen)<br />
# Peter Kjellerstedt (Saur)<br />
# Alejandro del Castillo (adelcast)<br />
# Denys Dmytriyenko (denix)<br />
# Sean Hudson (darknighte)<br />
# Nathan Rossi (nrossi)<br />
# Mark Hatle (fray)<br />
# Nicolas Dechesne (ndec)<br />
# Paul Eggleton (bluelightning)<br />
# Andrei Gherzan (agherzan)<br />
# Felipe F. Tonello (ftonello)<br />
# Changhyeok Bae (chbae)<br />
# Saul Wold (sgw)<br />
# Ashish Shrivastava<br />
# Pascal Bach (bachp)<br />
# Richard Purdie (RP)</div>Rpurdiehttps://www.openembedded.org/index.php?title=OEDAM_2015&diff=7675OEDAM 20152015-03-27T16:06:02Z<p>Rpurdie: /* Attendees */</p>
<hr />
<div><br />
== Location and Time ==<br />
<br />
March 27-28 (after ELC and Yocto Project Developer Day)<br />
<br />
2315 North 1st Street, San Jose, CA 95131 <br />
<br />
Google maps suggests getting off light rail at the Component Station.<br />
<br />
Start at 0900 each day.<br />
<br />
https://goo.gl/maps/1pRGR<br />
<br />
Now that people are already claiming to attend by Google Hangout, I will announce our intention to also webcast via Google Hangout ;)<br />
<br />
== Attendees ==<br />
<br />
* Philip Balister (Crofton)<br />
* Denys Dmytriyenko (denix)<br />
* Armin Kuster (Armpit)<br />
* Martin Jansa (JaMa) - 50%<br />
* Michael Halstead (halstead) - Friday only<br />
* Jeff Osier-Mixon (jefro)<br />
* Paul Eggleton (bluelightning)<br />
* Steve Arnold (nerdboy/mr_science)<br />
* Stephanie Lockwood-Childs (wormo/sjl) - via hangout<br />
* Ron Lockwood-Childs (speedy1) - via hangout<br />
* Herb Kuta<br />
* Tim Orling (moto-timo)<br />
* Sean Hudson (darknighte)<br />
* Bruce Ashfield (zedd) - probably<br />
* Mark Hatle (fray)<br />
* Sona Sarmadi<br />
* Changhyeok Bae<br />
* Belén Barros Pena (belen) - via hangout<br />
* Richard Purdie (RP) - via hangout<br />
<br />
== Agenda Items ==<br />
<br />
* Progress on items identified during OEDAM 2014<br />
* Development cycle<br />
* Patch review tools, improving the patch process<br />
* Tests<br />
* Removing the oe-core and meta-oe repos on github. These repos are now called openembedded-core and meta-openembedded/<br />
* People still use OE-classic from time to time. Should we remove the repo?<br />
* Security processes<br />
* Stack Overflow support<br />
* Community Development / Team Building (please add more examples/ideas... almond flour cake is always good...)<br />
** Intro / crash course events<br />
** Coordinated bug day sprints<br />
** Other group/meetup activities</div>Rpurdiehttps://www.openembedded.org/index.php?title=Dusseldorf,_2014&diff=7469Dusseldorf, 20142014-10-14T14:09:30Z<p>Rpurdie: /* Attendance */</p>
<hr />
<div>==Location ==<br />
<br />
Congress Centre Düsseldorf, Düsseldorf, Germany<br />
<br />
October 14, 2014 at 1300 - 1500 in room 111 (room changed, was 10 before).<br />
<br />
== Agenda ==<br />
<br />
* Financial report<br />
* Election of new members<br />
* Discussion about future of e.V. (started in 2013)<br />
<br />
== Forms ==<br />
<br />
* Proxy form [[File:Proxy_instructions-oe.pdf]]<br />
<br />
== Attendance ==<br />
* Leon 'likewise' Woestenberg<br />
* Denys 'denix' Dmytriyenko<br />
* Sean 'darknighte' Hudson<br />
* 'Khem' Raj<br />
* Andrea 'g1zer0' Galbusera<br />
* Marco 'mckoan' Cavallini - (proxy for Andrea 'ant_work' Adami)<br />
* Martin 'JaMa' Jansa<br />
* Mark 'fray' Hatle<br />
* Henning "woglinde" Heinold<br />
* Anders Darander<br />
* Richard Purdie (proxy for Paul Eggleton + David Stewart)<br />
* Koen Kooi (proxy Graeme)<br />
<br />
Non members present and elected to become members <br />
<br />
* Nicolas Dechesne<br />
<br />
Non members not present but elected to become members <br />
<br />
* Trevor Woerner<br />
* Gary Thomas<br />
* Tim Orling<br />
* Apelete Seketeli<br />
<br />
== Meeting notes ==<br />
Meeting opened 13:05<br />
Atendees Documented<br />
Financial Summary Presented<br />
* Various forms had to be filed<br />
* Challenges due to lack of German address and language barriers<br />
* SPI Account created with one donation<br />
* No other changes to accounts<br />
* Treasures report approved<br />
New member vote, all except gary, all in favour<br />
New member vote for Gary, two objections all others in favour<br />
Note member expiration as agenda for next board meeting, feedback to members within one month<br />
Discussion about e.V. structure and whether it still works for the project<br />
Boards recommends replacing the e.V. with something else, exact proposal to be determined in 18 months<br />
Three things which were needed resulting in the e.V. (which are still needed):<br />
* Financial<br />
* Ownership (e.g. domain names)<br />
* Decision making ability (which implies membership list)<br />
Financial issues covered by SPI, others open question<br />
Ideally involve OE membership more<br />
No objections for board looking into this<br />
Next GA needs proposals to vote on, in advance for proxy instructions<br />
Koen resigns from TSC<br />
Note board needs to deal with TSC elections<br />
Discussion about the role of the TSC<br />
Officially Closed 14:05<br />
<br />
== Financial Summary ==<br />
* OpenEmbedded e.V. bank accounts hold EUR 1731. SPI account holds EUR 127.<br />
* Overhead due to lack of German address and language barriers, we now have a German volunteer that provides us with a German address for tax declarations etc. and proxies postal documents.<br />
* Exempt from taxes over 2010, 2011 and 2012.<br />
* Spending were USD 50 (Philip?) on hosting, not yet declared.<br />
* Received EUR 128 worth of donations via SPI http://www.spi-inc.org/donations/<br />
* Treasures report approved<br />
<br />
== Action Items ==<br />
<br />
[[Category:General_Assemblies]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=Dusseldorf,_2014&diff=7461Dusseldorf, 20142014-10-14T12:03:22Z<p>Rpurdie: /* Meeting notes */</p>
<hr />
<div>==Location ==<br />
<br />
Congress Centre Düsseldorf, Düsseldorf, Germany<br />
<br />
October 14, 2014 at 1300 - 1500 in room 111 (room changed, was 10 before).<br />
<br />
== Agenda ==<br />
<br />
* Financial report<br />
* Election of new members<br />
* Discussion about future of e.V. (started in 2013)<br />
<br />
== Forms ==<br />
<br />
* Proxy form [[File:Proxy_instructions-oe.pdf]]<br />
<br />
== Attendance ==<br />
* Leon<br />
* Philip "Crofton" Balister<br />
* Denys 'denix' Dmytriyenko<br />
* Sean 'darknighte' Hudson<br />
* 'Khem' Raj<br />
* Andrea 'g1zer0' Galbusera<br />
* Marco 'mckoan' Cavallini - (proxy for Andrea 'ant_work' Adami)<br />
* Martin 'JaMa' Jansa<br />
* Mark 'fray' Hatle<br />
* Henning "woglinde" Heinold<br />
* Anders Darander<br />
* Leon Woestenberg<br />
* Richard Purdie (proxy for Paul Eggleton + David Stewart)<br />
* Koen Kooi (proxy Graeme)<br />
<br />
Non members present and elected to become members <br />
<br />
* Nicolas Dechesne<br />
<br />
Non members not present but elected to become members <br />
<br />
* Trevor Woerner<br />
* Gary Thomas<br />
<br />
* Tim Orling<br />
* (need name from Crofton)<br />
<br />
== Meeting notes ==<br />
Meeting opened 13:05<br />
Atendees Documented<br />
Financial Summary Presented<br />
* Various forms had to be filed<br />
* Challenges due to lack of German address and language barriers<br />
* SPI Account created with one donation<br />
* No other changes to accounts<br />
* Treasures report approved<br />
New member vote, all except gary, all in favour<br />
New member vote for Gary, two objections all others in favour<br />
Note member expiration as agenda for next board meeting, feedback to members within one month<br />
Discussion about e.V. structure and whether it still works for the project<br />
Boards recommends replacing the e.V. with something else, exact proposal to be determined in 18 months<br />
Three things which were needed resulting in the e.V. (which are still needed):<br />
* Financial<br />
* Ownership (e.g. domain names)<br />
* Decision making ability (which implies membership list)<br />
Financial issues covered by SPI, others open question<br />
Ideally involve OE membership more<br />
No objections for board looking into this<br />
Next GA needs proposals to vote on, in advance for proxy instructions<br />
Koen resigns from TSC<br />
Note board needs to deal with TSC elections<br />
Discussion about the role of the TSC<br />
Officially Closed 14:05<br />
<br />
== Action Items ==<br />
<br />
[[Category:General_Assemblies]]</div>Rpurdiehttps://www.openembedded.org/index.php?title=Dusseldorf,_2014&diff=7439Dusseldorf, 20142014-10-14T11:25:04Z<p>Rpurdie: /* Attendance */</p>
<hr />
<div>==Location ==<br />
<br />
Congress Centre Düsseldorf, Düsseldorf, Germany<br />
<br />
October 14, 2014 at 1300 - 1500 in room 111 (room changed, was 10 before).<br />
<br />
== Agenda ==<br />
<br />
* Financial report<br />
* Election of new members<br />
* Discussion about future of e.V. (started in 2013)<br />
<br />
== Forms ==<br />
<br />
* Proxy form [[File:Proxy_instructions-oe.pdf]]<br />
<br />
== Attendance ==<br />
* Leon<br />
* Philip "Crofton" Balister<br />
* Denys 'denix' Dmytriyenko<br />
* Sean 'darknighte' Hudson<br />
* 'Khem' Raj<br />
* Andrea 'g1zer0' Galbusera<br />
* Marco 'mckoan' Cavallini - (proxy for Andrea 'ant_work' Adami)<br />
* Martin 'JaMa' Jansa<br />
* Mark 'fray' Hatle<br />
* Henning "woglinde" Heinold<br />
* Anders Darander<br />
* Leon Woestenberg<br />
* Richard Purdie (proxy for Paul Eggleton + David Stewart)<br />
* Koen Kooi (proxy Graeme)<br />
<br />
Non members present and elected to become members <br />
<br />
* Nicolas Dechesne<br />
<br />
Non members not present but elected to become members <br />
<br />
* Trevor Woerner<br />
* Gary Thomas<br />
<br />
* Tim Orling<br />
* (need name from Crofton)<br />
<br />
== Meeting notes ==<br />
Meeting opened 13:05<br />
Atendees Documented<br />
Financial Summary Presented<br />
* Various forms had to be filed<br />
* Challenges due to lack of German address and language barriers<br />
* SPI Account created with one donation<br />
* No other changes to accounts<br />
* Treasures report approved<br />
<br />
== Action Items ==</div>Rpurdiehttps://www.openembedded.org/index.php?title=Dusseldorf,_2014&diff=7437Dusseldorf, 20142014-10-14T11:22:51Z<p>Rpurdie: /* Attendance */</p>
<hr />
<div>==Location ==<br />
<br />
Congress Centre Düsseldorf, Düsseldorf, Germany<br />
<br />
October 14, 2014 at 1300 - 1500 in room 111 (room changed, was 10 before).<br />
<br />
== Agenda ==<br />
<br />
* Financial report<br />
* Election of new members<br />
* Discussion about future of e.V. (started in 2013)<br />
<br />
== Forms ==<br />
<br />
* Proxy form [[File:Proxy_instructions-oe.pdf]]<br />
<br />
== Attendance ==<br />
* Leon<br />
* Philip "Crofton" Balister<br />
* Denys 'denix' Dmytriyenko<br />
* Sean 'darknighte' Hudson<br />
* 'Khem' Raj<br />
* Andrea 'g1zer0' Galbusera<br />
* Marco 'mckoan' Cavallini - (proxy for Andrea 'ant_work' Adami)<br />
* Martin 'JaMa' Jansa<br />
* Mark 'fray' Hatle<br />
* Henning "woglinde" Heinold<br />
* Anders Darander<br />
* Leon Woestenberg<br />
* Richard Purdie (proxy for Paul Eggleton + David Stewart)<br />
<br />
Non members present and elected to become members <br />
<br />
* Nicolas Dechesne<br />
<br />
Non members not present but elected to become members <br />
<br />
* Trevor Woerner<br />
* Gary Thomas<br />
<br />
* Tim Orling<br />
* (need name from Crofton)<br />
<br />
== Meeting notes ==<br />
Meeting opened 13:05<br />
Atendees Documented<br />
Financial Summary Presented<br />
* Various forms had to be filed<br />
* Challenges due to lack of German address and language barriers<br />
* SPI Account created with one donation<br />
* No other changes to accounts<br />
* Treasures report approved<br />
<br />
== Action Items ==</div>Rpurdiehttps://www.openembedded.org/index.php?title=Dusseldorf,_2014&diff=7435Dusseldorf, 20142014-10-14T11:14:25Z<p>Rpurdie: /* Meeting notes */</p>
<hr />
<div>==Location ==<br />
<br />
Congress Centre Düsseldorf, Düsseldorf, Germany<br />
<br />
October 14, 2014 at 1300 - 1500 in room 111 (room changed, was 10 before).<br />
<br />
== Agenda ==<br />
<br />
* Financial report<br />
* Election of new members<br />
* Discussion about future of e.V. (started in 2013)<br />
<br />
== Forms ==<br />
<br />
* Proxy form [[File:Proxy_instructions-oe.pdf]]<br />
<br />
== Attendance ==<br />
* Leon<br />
* Philip "Crofton" Balister<br />
* Denys 'denix' Dmytriyenko<br />
* Sean 'darknighte' Hudson<br />
* 'Khem' Raj<br />
* Andrea 'g1zer0' Galbusera<br />
* Marco 'mckoan' Cavallini - (proxy for Andrea 'ant_work' Adami)<br />
* Martin 'JaMa' Jansa<br />
* Mark 'fray' Hatle<br />
* Henning "woglinde" Heinold<br />
* Anders Darander<br />
* Leon<br />
* Richard Purdie (proxy for Paul Eggleton + David Stewart)<br />
<br />
== Meeting notes ==<br />
Meeting opened 13:05<br />
Atendees Documented<br />
Financial Summary Presented<br />
* Various forms had to be filed<br />
* Challenges due to lack of German address and language barriers<br />
* SPI Account created with one donation<br />
* No other changes to accounts<br />
* Treasures report approved<br />
<br />
== Action Items ==</div>Rpurdiehttps://www.openembedded.org/index.php?title=Dusseldorf,_2014&diff=7433Dusseldorf, 20142014-10-14T11:08:33Z<p>Rpurdie: /* Attendance */</p>
<hr />
<div>==Location ==<br />
<br />
Congress Centre Düsseldorf, Düsseldorf, Germany<br />
<br />
October 14, 2014 at 1300 - 1500 in room 111 (room changed, was 10 before).<br />
<br />
== Agenda ==<br />
<br />
* Financial report<br />
* Election of new members<br />
* Discussion about future of e.V. (started in 2013)<br />
<br />
== Forms ==<br />
<br />
* Proxy form [[File:Proxy_instructions-oe.pdf]]<br />
<br />
== Attendance ==<br />
* Leon<br />
* Philip "Crofton" Balister<br />
* Denys 'denix' Dmytriyenko<br />
* Sean 'darknighte' Hudson<br />
* 'Khem' Raj<br />
* Andrea 'g1zer0' Galbusera<br />
* Marco 'mckoan' Cavallini - (proxy for Andrea 'ant_work' Adami)<br />
* Martin 'JaMa' Jansa<br />
* Mark 'fray' Hatle<br />
* Henning "woglinde" Heinold<br />
* Anders Darander<br />
* Leon<br />
* Richard Purdie (proxy for Paul Eggleton + David Stewart)<br />
<br />
== Meeting notes ==<br />
<br />
== Action Items ==</div>Rpurdiehttps://www.openembedded.org/index.php?title=Edinburgh,_2013&diff=6493Edinburgh, 20132013-10-25T18:05:52Z<p>Rpurdie: </p>
<hr />
<div>==Location ==<br />
<br />
<br />
<br />
Edinburgh International Conference Centre, Edinburgh, UK<br />
<br />
October 25, 2013 at 1830 - 1930 in Harris 1.<br />
<br />
== Agenda ==<br />
<br />
* Financial report<br />
* Election of new members<br />
<br />
== Forms ==<br />
<br />
* Proxy form [[File:Proxy_instructions-oe.pdf]]<br />
<br />
== Attendence Record ==<br />
<br />
(Proxies are in brackets)<br />
<br />
* Marco Cavallini 'mckoan' (proxying for Eric Bénard 'ericben')<br />
* Paul Eggleton 'bluelightning' (proxying for Andrea Adami 'ant')<br />
* Philip Balister 'Crofton'<br />
* Richard Purdie 'RP'<br />
* Martin Jansa 'JaMa' (Simon Busch 'morphis')<br />
* Denys Dmytriyenko 'denix'<br />
* Koen Kooi 'koen' ( Khem Raj 'khem')<br />
* Anders Darander<br />
* Mark Hatle 'fray' (Otavio Salvador 'otavio')<br />
* Sean Hudson 'darknighte'<br />
* Saul Wold 'sgw'<br />
* Stefan Schmidt<br />
* Leon<br />
* David Stewart<br />
* Jefro<br />
* Soctt Garman<br />
<br />
Non members present and elected to become members<br />
<br />
* Jack Mitchell<br />
* Andrea Galbusera<br />
* Ross Burton<br />
<br />
Non members not present but elected to become members<br />
<br />
* Bruce Ashfield<br />
* Ulf S<br />
<br />
<br />
== Meeting notes ==<br />
<br />
Meeting opened 18:35<br />
Attendees Documented<br />
Financially Summary Presented<br />
* Euro 1731<br />
* Taxes had to be filed, issues due to board transition<br />
* German language issues and documents required to be at a German <br />
address. Lots of overhead<br />
* No spending in last financial year<br />
* No donations received either<br />
* Switched to SPI for finance<br />
Financial Report Approved<br />
Discussion of expenditure<br />
Things membership generally in favour of:<br />
- travel sponsorship preferred <br />
- ship event box for conferences<br />
- financial availability for emergency hardware<br />
- promotion at events<br />
Things membership generally not in favour of:<br />
- promotion in e.g. coffee breaks<br />
Discussion about future of e.V. and whether SPI (as an example) would make sense<br />
- nobody against dissolving e.V. in principle<br />
- Feeling that board should investigate and consult members and come up with a proposal<br />
Meeting Ended 19:20</div>Rpurdie