Difference between revisions of "OEDAM 2014"

From Openembedded.org
Jump to: navigation, search
m (Attendees)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
= OpenEmbedded Developers America Meeting =
 
= OpenEmbedded Developers America Meeting =
  
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 13: Line 13:
 
4600 Patrick Henry Drive<br>
 
4600 Patrick Henry Drive<br>
 
Santa Clara, CA 95054 USA
 
Santa Clara, CA 95054 USA
 
I am looking into providing coffee and tidbits in the mornings. I may wait until the day of the event to see how many people actually show up, so don't plan on a caffeine injection before 10am each day.
 
 
Lunches will be catered, restaurant TBD and I'm open to suggestions. Food trucks did not work out. The current plan is for catering by Old Ironsides Cafe on Friday, and possibly pizza on Saturday.
 
 
A fully hosted dinner party will be held at the Tied House Brewing Company in Mountain View, Friday May 2, 6pm-8pm. This venue is accessible by light rail or by car with free parking. If you can not make it to this event, please let [mailto:jefro@jefro.net Jefro] know.
 
 
All meals provided by the [http://yoctoproject.org Yocto Project Community Office]
 
 
Carpools for the Tied House:
 
 
* Jefro (room for 3 more)
 
* JaMa (room for 3 more)
 
  
 
== Goals ==
 
== Goals ==
Line 52: Line 39:
 
* infrastructure sync
 
* infrastructure sync
  
== Attendees ==
+
== Registered Attendees ==
  
 
* Philip Balister (Crofton)
 
* Philip Balister (Crofton)
Line 75: Line 62:
 
* Michael Halstead (halstead)
 
* Michael Halstead (halstead)
 
* <your name here>
 
* <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<br>
 +
worried about documentation<br>
 +
long term aggregate many, for now just a handful of hardware<br>
 +
linaro can help define lava piece<br>
 +
define what to certify, then push results<br>
 +
simple data: configuration and red/green (yellow?) on layer+config+hw basis<br>
 +
 +
3 stages:<br>
 +
* building
 +
* testing (potentially lava)
 +
* aggregation & publishing data (toaster?)
 +
 +
lava has ways to report results, suspect regressions<br>
 +
drilldown capability<br>
 +
lava difficult to connect inside/outside firewalls
 +
 +
error reporting tool in 1.6<br>
 +
standard output push to bug reporting tool like this<br>
 +
like a failure pastebin<br>
 +
can mine data & look for trends
 +
 +
porting 1.6 requires resources <br>
 +
2k tests in 1.6, more tests less necessary than integration
 +
 +
parallel work, not for 1.7<br>
 +
nice to have simplified install complete with lava, hw pieces, additional test pieces<br>
 +
interface for aggregation - porting mechanism<br>
 +
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<br>
 +
fulfilled original charter<br>
 +
board & happy with TSC - responsive<br>
 +
still needed?<br>
 +
new public meeting + as needed format is not much work<br>
 +
hardest thing is topics<br>
 +
* jefro to help with topics
 +
need to do more? less?<br>
 +
denys - people would like to see more diversity<br>
 +
heavy on yocto project<br>
 +
members have worked to isolate roles<br>
 +
community requests yes keep going, yes keep elections<br>
 +
if contentious issue, group that can vote<br>
 +
like RP not being overwhelmed & provide contrast<br>
 +
community meetings very useful<br>
 +
some concern about uniformity/affiliations but trust exists<br>
 +
mark: call us on it if you think we are deciding for intel/wr/whoever<br>
 +
 +
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<br>
 +
no movement planned right now<br>
 +
have account for donations
 +
 +
== Why is embedded still hard ==
 +
 +
i.e. best practices
 +
 +
learning curve<br>
 +
oe and yp trying to make embedded easier<br>
 +
many tasks involved <br>
 +
finding changes/errors involves many steps<br>
 +
locked sstate coming<br>
 +
just documentation issue? no, but that is where to begin<br>
 +
many people don't want to know about build systems, they want magic to happen<br>
 +
system integrateors are very happy with yp<br>
 +
app developers don't care<br>
 +
- app developers don't (or shouldn't) care about using all of bitbake/oe<br>
 +
- they should care about compiling, debugging, and even deployment of their application<br>
 +
 +
figure out steps, maybe yp does - white papers, best practices, disseminate<br>
 +
what do i hav eto do day to day to get it done<br>
 +
encapsulate problem<br>
 +
* capture daily workflow, write email
 +
 +
aggregate - yp tech writer
 +
 +
external source class stuff<br>
 +
narcissus good at making images, but can make images that don't work<br>
 +
much discussion about details<br>
 +
* 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<br>
 +
monitor maintainers<br>
 +
where to file bugs<br>
 +
MAINTAINER file should include where to send patches, report problems<br>
 +
eg on github use github issues system or to mailing list<br>
 +
possibly on yp bugzilla?
 +
 +
RP:<br>
 +
no new bugs in yp bugzilla, policy is not supporting bugs for outside projects<br>
 +
unless someone from that project joins the triage team<br>
 +
 +
quality of any layer, esp oe layers, bring it up to the tsc & main maintainer if one exists<br>
 +
document:<br>
 +
1. maintainer makes right technical decisions for layer - rp is the boss<br>
 +
2. must respond on ml within reasonable time, longer than 2 weeks is too long<br>
 +
3. if cant do maintainership along with other paid work, find someone<br>
 +
 +
maintainer = quality
 +
 +
* philip: for yp users: best practice read martin's emails about broken recipes
 +
disable broken layers?<br>
 +
has to be a way to tell people who don't read emails<br>
 +
move or remove on 2nd iteration<br>
 +
blacklist recipe inside itself<br>
 +
add to default inherit
 +
 +
* increase pain for stuff that just fails
 +
highlight qa fails, cheerlead & encourage people to look at<br>
 +
more review comments helps<br>
 +
collect stats<br>
 +
explain what using stats for<br>
 +
 +
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<br>
 +
cinematic<br>
 +
working on a set of hardware, not just one<br>
 +
also document how I made the demo - no reason for handwaving
 +
 +
devday - splitting by function, auto/iot/medical<br>
 +
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<br>
 +
rewritten to be in qt5<br>
 +
great for phones, tablets, internet of 5<br>
 +
need qt5 in oe-core<br>
 +
many demos<br>
 +
html5<br>
 +
luna is webos specific. this is lune os
 +
 +
general consensus - yes, worth making it work for oe demos<br>
 +
bmills would love to see solutoin that does not require hw acceleration<br>
 +
good demo that can build <br>
 +
not good for qemu
 +
 +
2 things<br>
 +
need sane demo that looks better than sato<br>
 +
better demo for high end hardware
 +
 +
node.js is another option<br>
 +
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)<br>
 +
poky, oe-core YP compatible
 +
 +
improve deployment<br>
 +
currently board specific, maybe my board is different<br>
 +
also installer - config for 1st boot
 +
 +
common pieces - same sd card formatting several different products<br>
 +
so spit out sd image small then enlarged, awesome<br>
 +
solves 80% of installation needs<br>
 +
deployment config file<br>
 +
no sudo<br>
 +
WIC<br>
 +
target: 1.7
 +
 +
upgrade methods that don't use package feeds<br>
 +
autobuilder & tester feeds to upgrade<br>
 +
can't rely on distros to alert<br>
 +
khem - images want upgradability<br>
 +
eg internal storage and an SD card<br>
 +
dual identical partitions for failover<br>
 +
 +
best practices, industry examples<br>
 +
need good samples<br>
 +
=> please document this problem if you have solved it<br>
 +
in-service updates<br>
 +
other option - atomic package feeds
 +
 +
plans for clang on oe<br>
 +
fray's secondary toolchain layer<br>
 +
layer availalbe, not in oe-core
 +
 +
html5 applications to become first class citizens<br>
 +
oe? oe-core? bill: layer, but well supported<br>
 +
also for processors without hw accel<br>
 +
scale down to dumb framebuffers
 +
 +
lava<br>
 +
steve: deployed jenkins to apache
 +
 +
cryptographically signed sstate cache<br>
 +
secure development life cycles
 +
 +
== online voting & other board issues ==
 +
 +
drupal site for yocto project<br>
 +
registered members can vote<br>
 +
code is built already, like surveymonkey
 +
 +
Philip: any sane system is great<br>
 +
* sean to drive voting system
 +
 +
more regular developer meetings<br>
 +
build a sense of community<br>
 +
need advance notice - 2-3 months<br>
 +
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!<br>
 +
 +
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)<br>
 +
— Reuse SDK toolchain<br>
 +
— External SRC workflow<br>
 +
— manual adjust (opt-out) of dep change<br>
 +
— feed based assembly for app dev<br>
 +
— Generate a ‘package’ from the SDK, add to feed and deploy<br>
 +
 +
 +
----
 +
 +
 +
Friday Afternoon discussion, making embedded easier.  Few key things we can do..
 +
 +
— Git/SCM workflow/best practices<br>
 +
— SCM rate of change is an indication of quality<br>
 +
— OE Stats/Recipe usage stats<br>
 +
— layer index — maintainer info, submit patches, auto builder, test results, …<br>
 +
— working demos<br>
 +
 +
 +
----
 +
 +
 +
Saturday Next+1 Future discussion...
 +
 +
— deployment (wic — partitions… , network fs)<br>
 +
— heterogeneous systems (GPU, DSP, multi arch)<br>
 +
— HTML5 apps become first class citizens<br>
 +
 +
[[Category:OEDEM]]

Latest revision as of 17:42, 12 August 2020

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