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 regresstions 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 aggregatoin - 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 => ask community if anyone else wnats to step in or if anyone wants to step down => vote everyone together board to do these things within the next month

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 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 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 daliy workflow, write email aggregate - yp tech writers? - 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 decisinos 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

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

pb => 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 & pu tinto oe-core don't want to upstream due to requring 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 upgradabilty 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 biult already, like surveymonkey

pb 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:

OEDAM

— local.conf generation, comment it!

---

— 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

———

— 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

—— +1 Future

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