OEDAM 2014

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.

Contact Jefro with any questions.

Location & Time

May 2-3, 2014
9am - 5pm

Ettus Research / National Instruments
4600 Patrick Henry Drive
Santa Clara, CA 95054 USA

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
• next + 1 release
• quality of meta-oe and what to do with it: http://lists.openembedded.org/pipermail/openembedded-devel/2014-March/094893.html
• lune to replace sato?
• developer community - outreach/recruiting/mentoring, new developer documentation, process and QA tools
• image deployment/update best practices (shared yocto issue)
• feedback on Toaster, the web interface for BitBake (some background in this thread https://lists.yoctoproject.org/pipermail/yocto/2014-April/018956.html)
• infrastructure sync

Registered Attendees

• Philip Balister (Crofton)
• Richard Purdie (RP)
• Mark Hatle (fray)
• Khem Raj (khem)
• Martin Jansa (jama)
• Armin Kuster (akuster)
• Jeff Osier-Mixon (jefro)
• Alejandro del Castillo
• Tom King (ka6sox)
• Steve Arnold (mr_science/nerdboy)
• Herb Kuta
• Trevor Woerner (tlwoerner)
• Sean Hudson (darknighte)
• Denys Dmytriyenko (denix)
• Toby Flynn
• Adam Bell
• Belen Barros Pena (belen)
• Brian Hutchinson
• Tim Orling (moto-timo)
• Michael Halstead (halstead)
• <your name here>

Minutes

Actual Attendance

• armin kuster
• tim orling
• herb kuta
• martin jansa
• toby flynn
• steve arnold
• adam bell
• mark hatle
• sean hudson
• philip balister
• denys dmitriyenko
• alan bennett
• trevor woerner
• michael halstead
• belen barros pena
• bill mills
• khem raj
• alejandro del castillo
• jefro

on call:

• richard purdie
• paul eggleton
• saul wold
• bruce ashfield

Agenda

We worked out a detailed agenda as the first task on Friday morning.

Fri am:

• introductions
• Lava
• ongoing role of the TSC
• Why is embedded still hard? & RP's email

Fri pm:

• unfinished business from this morning
• Lune to replace Sato
• increasing BSP quantity & quality
• next+1 release
• online voting
• best practices - image deployment, default config

Sat:

• unfinished business from Friday
• wiki/website organization
• meta-oe quality
• developer community outreach
• bug scrub

offline:

• toaster feedback
• infrastructure sync

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

3 stages:

• building
• testing (potentially lava)
• aggregation & publishing data (toaster?)

lava has ways to report results, suspect regressions
drilldown capability
lava difficult to connect inside/outside firewalls

error reporting tool in 1.6
standard output push to bug reporting tool like this
like a failure pastebin
can mine data & look for trends

porting 1.6 requires resources
2k tests in 1.6, more tests less necessary than integration

parallel work, not for 1.7
nice to have simplified install complete with lava, hw pieces, additional test pieces
interface for aggregation - porting mechanism
built on error reporting system

action items:

• autobuilder assets tested in lava, apply to ab output (alan -> beth, michael)
• 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

maintainer = quality

• philip: for yp users: best practice read martin's emails about broken recipes

disable broken layers?
has to be a way to tell people who don't read emails
move or remove on 2nd iteration
blacklist recipe inside itself
add to default inherit

• increase pain for stuff that just fails

highlight qa fails, cheerlead & encourage people to look at
more review comments helps
collect stats
explain what using stats for

advertise e.g. meta-selinux

• extra fields on layer index (maintainers, readme file)
• philip to send to list re updates to README files, paul to see if he can parse things out of it
• place to put results if attached to autobuilder: dont have to advocate right away, best practices on what to bulid against - 1.4, 1.5, master, etc
• guidance to new maintainers

Philip:

• working demos & starting points, e.g. qt demo
  

cinematic
working on a set of hardware, not just one
also document how I made the demo - no reason for handwaving

devday - splitting by function, auto/iot/medical
getting a number of vendors interested in helping with

• pb to agitate on list for demo with recipes, no bsps - non arch specific

lune

came from openwebos
rewritten to be in qt5
great for phones, tablets, internet of 5
need qt5 in oe-core
many demos
html5
luna is webos specific. this is lune os

general consensus - yes, worth making it work for oe demos
bmills would love to see solutoin that does not require hw acceleration
good demo that can build
not good for qemu

2 things
need sane demo that looks better than sato
better demo for high end hardware

node.js is another option
lune uses v8 or node

• jama to do initial work, will post for help when needed
• not to replace completely & put into oe-core, don't want to upstream due to requiring change in qt

next+1 release

khem: meta-oe in yocto (1.8? no, 4.04)
poky, oe-core YP compatible

improve deployment
currently board specific, maybe my board is different
also installer - config for 1st boot

common pieces - same sd card formatting several different products
so spit out sd image small then enlarged, awesome
solves 80% of installation needs
deployment config file
no sudo
WIC
target: 1.7

upgrade methods that don't use package feeds
autobuilder & tester feeds to upgrade
can't rely on distros to alert
khem - images want upgradability
eg internal storage and an SD card
dual identical partitions for failover

best practices, industry examples
need good samples
=> please document this problem if you have solved it
in-service updates
other option - atomic package feeds

plans for clang on oe
fray's secondary toolchain layer
layer availalbe, not in oe-core

html5 applications to become first class citizens
oe? oe-core? bill: layer, but well supported
also for processors without hw accel
scale down to dumb framebuffers

lava
steve: deployed jenkins to apache

cryptographically signed sstate cache
secure development life cycles

online voting & other board issues

drupal site for yocto project
registered members can vote
code is built already, like surveymonkey

Philip: any sane system is great

• sean to drive voting system

more regular developer meetings
build a sense of community
need advance notice - 2-3 months
find space

devday - trainers, overlap with plumbers

funding discussion - ongoing

Mark Hatle's notes

Complaints about local.conf files from 3rd parties...

— local.conf generation, comment it!

solution use format/comments similar to existing local.conf and local.conf.extended so new developers can translate their work.

---

Friday Morning discussion, couple of key points to remember as we move forward with oe development:

— Document workflows (based on RPs email)
— Reuse SDK toolchain
— External SRC workflow
— manual adjust (opt-out) of dep change
— feed based assembly for app dev
— Generate a ‘package’ from the SDK, add to feed and deploy

---

Friday Afternoon discussion, making embedded easier. Few key things we can do..

— Git/SCM workflow/best practices
— SCM rate of change is an indication of quality
— OE Stats/Recipe usage stats
— layer index — maintainer info, submit patches, auto builder, test results, …
— working demos

---

Saturday Next+1 Future discussion...

— deployment (wic — partitions… , network fs)
— heterogeneous systems (GPU, DSP, multi arch)
— HTML5 apps become first class citizens