The OpenEmbedded Project is holding a developers meeting May 2-3, 2014, in Santa Clara, CA. This meeting is co-located with the Embedded Linux Conference North America. All active OpenEmbedded developers are invited to attend.

+

The OpenEmbedded Project held a developers meeting May 2-3, 2014, in Santa Clara, CA. This meeting was co-located with the Embedded Linux Conference North America. All active OpenEmbedded developers were invited to attend.

Contact [mailto:jefro@jefro.net Jefro] with any questions.

Contact [mailto:jefro@jefro.net Jefro] with any questions.

Line 8:

Line 8:

May 2-3, 2014<br>

May 2-3, 2014<br>

−

time TBD

+

9am - 5pm

[https://www.google.com/maps/preview#!q=4600+Patrick+Henry+Dr+Santa+Clara%2C+CA+95054+&data=!1m4!1m3!1d9724!2d-121.985724!3d37.3978139!4m15!2m14!1m13!1s0x808fc9d0bdf38417%3A0x8ca7d9c558968760!3m8!1m3!1d2439!2d-80.4013806!3d37.1440125!3m2!1i1366!2i589!4f13.1!4m2!3d37.3978139!4d-121.985724 Ettus Research / National Instruments]<br>

[https://www.google.com/maps/preview#!q=4600+Patrick+Henry+Dr+Santa+Clara%2C+CA+95054+&data=!1m4!1m3!1d9724!2d-121.985724!3d37.3978139!4m15!2m14!1m13!1s0x808fc9d0bdf38417%3A0x8ca7d9c558968760!3m8!1m3!1d2439!2d-80.4013806!3d37.1440125!3m2!1i1366!2i589!4f13.1!4m2!3d37.3978139!4d-121.985724 Ettus Research / National Instruments]<br>

4600 Patrick Henry Drive<br>

4600 Patrick Henry Drive<br>

Santa Clara, CA 95054 USA

Santa Clara, CA 95054 USA

−

−

Lunches will be provided by the [http://yoctoproject.org Yocto Project Community Office]

== Goals ==

== Goals ==

Line 20:

Line 18:

* Have fun.

* Have fun.

* Get useful work done that benefits from high bandwidth interactions.

* Get useful work done that benefits from high bandwidth interactions.

−

* Get more people involved wit the project at a higher level.

+

* Get more people involved with the project at a higher level.

== Working Agenda ==

== Working Agenda ==

−

This agenda is flexible, and meant to reflect the important issues in the OE community. Please feel free to contribute agenda items.

+

This agenda is flexible, and meant to reflect the important issues in the OE community. Please feel free to contribute agenda items. We will finalize the agenda after introduction to maximize use of people's time.

−

* bug scrub

+

* Introductions. Be prepared to tell us who you are and how you use OpenEmbedded (and the Yocto Project)

+

* The Yocto Project is supposed to make Embedded easy. What is still hard?

+

* bug scrub (also bug collecting/wrangling)

* ongoing role of the OE TSC

* ongoing role of the OE TSC

* wiki/website organization

* wiki/website organization

Line 32:

Line 32:

* increasing the amount of hardware that works out of the box with oe-core + layers

* increasing the amount of hardware that works out of the box with oe-core + layers

* next + 1 release

* next + 1 release

−

* attract new developers and help them out to next level

+

* quality of meta-oe and what to do with it: http://lists.openembedded.org/pipermail/openembedded-devel/2014-March/094893.html

OpenEmbedded Developers America Meeting

The OpenEmbedded Project held a developers meeting May 2-3, 2014, in Santa Clara, CA. This meeting was co-located with the Embedded Linux Conference North America. All active OpenEmbedded developers were invited to attend.

Location & Time

Goals

Have fun.

Get useful work done that benefits from high bandwidth interactions.

Get more people involved with the project at a higher level.

Working Agenda

This agenda is flexible, and meant to reflect the important issues in the OE community. Please feel free to contribute agenda items. We will finalize the agenda after introduction to maximize use of people's time.

Introductions. Be prepared to tell us who you are and how you use OpenEmbedded (and the Yocto Project)

The Yocto Project is supposed to make Embedded easy. What is still hard?

bug scrub (also bug collecting/wrangling)

ongoing role of the OE TSC

wiki/website organization

online voting

increasing the amount of hardware that works out of the box with oe-core + layers

Lava

no board farm, possible to set up distributed board farm
worried about documentation
long term aggregate many, for now just a handful of hardware
linaro can help define lava piece
define what to certify, then push results
simple data: configuration and red/green (yellow?) on layer+config+hw basis

take some tests performed in 1.6 and bring into lava (ti/bill, steve nerdboy)

define requirements for aggregation system (sean)

Ongoing role of the TSC

needed someone to set direction
fulfilled original charter
board & happy with TSC - responsive
still needed?
new public meeting + as needed format is not much work
hardest thing is topics

jefro to help with topics

need to do more? less?
denys - people would like to see more diversity
heavy on yocto project
members have worked to isolate roles
community requests yes keep going, yes keep elections
if contentious issue, group that can vote
like RP not being overwhelmed & provide contrast
community meetings very useful
some concern about uniformity/affiliations but trust exists
mark: call us on it if you think we are deciding for intel/wr/whoever

board to do these things within the next month:

ask community if anyone else wants to step in or if anyone wants to step down

vote everyone together

mark asked about discussion re dissolving ev, moving it elsewhere, etc
no movement planned right now
have account for donations

Why is embedded still hard

i.e. best practices

learning curve
oe and yp trying to make embedded easier
many tasks involved
finding changes/errors involves many steps
locked sstate coming
just documentation issue? no, but that is where to begin
many people don't want to know about build systems, they want magic to happen
system integrateors are very happy with yp
app developers don't care
- app developers don't (or shouldn't) care about using all of bitbake/oe
- they should care about compiling, debugging, and even deployment of their application

figure out steps, maybe yp does - white papers, best practices, disseminate
what do i hav eto do day to day to get it done
encapsulate problem

capture daily workflow, write email

aggregate - yp tech writer

external source class stuff
narcissus good at making images, but can make images that don't work
much discussion about details

document personal workflows as best we can & categorize

DEPENDS overloaded? khem

document workflows based on rp's email

based on workflows, determine how extermal toolchains to be used

dependency tree

? feed based assembly for the yocto autobuilders

install built toolchain as toolchain (steve)

generate RPMs - external source workflow

eclipse

take to list

Increasing layer quality

have a lot of layers, some better maintained than others
monitor maintainers
where to file bugs
MAINTAINER file should include where to send patches, report problems
eg on github use github issues system or to mailing list
possibly on yp bugzilla?

RP:
no new bugs in yp bugzilla, policy is not supporting bugs for outside projects
unless someone from that project joins the triage team

quality of any layer, esp oe layers, bring it up to the tsc & main maintainer if one exists
document:
1. maintainer makes right technical decisions for layer - rp is the boss
2. must respond on ml within reasonable time, longer than 2 weeks is too long
3. if cant do maintainership along with other paid work, find someone