Difference between revisions of "OEDAM"

From Openembedded.org
Jump to: navigation, search
(Why is embedded still hard)
 
(2 intermediate revisions by 2 users not shown)
Line 124: Line 124:
 
== Lava ==
 
== Lava ==
  
no board farm, possible to set up distributed board farm
+
no board farm, possible to set up distributed board farm<br>
worried about documentation
+
worried about documentation<br>
long term aggregate many, for now just a handful of hardware
+
long term aggregate many, for now just a handful of hardware<br>
linaro can help define lava piece
+
linaro can help define lava piece<br>
define what to certify, then push results
+
define what to certify, then push results<br>
simple data: configuration and red/green (yellow?) on layer+config+hw basis
+
simple data: configuration and red/green (yellow?) on layer+config+hw basis<br>
3 stages
+
 
  building
+
3 stages:<br>
  testing (potentially lava)
+
* building
  aggregation & publishing data (toaster?)
+
* testing (potentially lava)
lava has ways to report results, suspect regresstions
+
* aggregation & publishing data (toaster?)
drilldown capability
+
 
 +
lava has ways to report results, suspect regressions<br>
 +
drilldown capability<br>
 
lava difficult to connect inside/outside firewalls
 
lava difficult to connect inside/outside firewalls
  
error reporting tool in 1.6
+
error reporting tool in 1.6<br>
standard output push to bug reporting tool like this
+
standard output push to bug reporting tool like this<br>
like a failure pastebin
+
like a failure pastebin<br>
 
can mine data & look for trends
 
can mine data & look for trends
  
porting 1.6 requires resources  
+
porting 1.6 requires resources <br>
 
2k tests in 1.6, more tests less necessary than integration
 
2k tests in 1.6, more tests less necessary than integration
  
parallel work, not for 1.7:
+
parallel work, not for 1.7<br>
nice to have simplified install complete with lava, hw pieces, additional test pieces
+
nice to have simplified install complete with lava, hw pieces, additional test pieces<br>
interface for aggregatoin - porting mechanism
+
interface for aggregation - porting mechanism<br>
  built on error reporting system
+
built on error reporting system
  
 
action items:
 
action items:
Line 158: Line 160:
 
== Ongoing role of the TSC ==
 
== Ongoing role of the TSC ==
  
needed someone to set direction
+
needed someone to set direction<br>
fulfilled original charter
+
fulfilled original charter<br>
board & happy with TSC - responsive
+
board & happy with TSC - responsive<br>
still needed?
+
still needed?<br>
new public meeting + as needed format is not much work
+
new public meeting + as needed format is not much work<br>
hardest thing is topics
+
hardest thing is topics<br>
 
* jefro to help with topics
 
* jefro to help with topics
need to do more? less?
+
need to do more? less?<br>
denys - people would like to see more diversity
+
denys - people would like to see more diversity<br>
heavy on yocto project
+
heavy on yocto project<br>
members have worked to isolate roles
+
members have worked to isolate roles<br>
community requests yes keep going, yes keep elections
+
community requests yes keep going, yes keep elections<br>
if contentious issue, group that can vote
+
if contentious issue, group that can vote<br>
like RP not being overwhelmed & provide contrast
+
like RP not being overwhelmed & provide contrast<br>
community meetings very useful
+
community meetings very useful<br>
some concern about uniformity/affiliations but trust exists
+
some concern about uniformity/affiliations but trust exists<br>
mark: call us on it if you think we are deciding for intel/wr/whoever
+
mark: call us on it if you think we are deciding for intel/wr/whoever<br>
=> 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
+
board to do these things within the next month:
no movement planned right now
+
* 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
 
have account for donations
  
_____________________________________________________________________________________________
+
== Why is embedded still hard ==
Why is embedded still hard
+
best practices
+
  
learning curve
+
i.e. best practices
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
+
learning curve<br>
=> based on workflows, determine how extermal toolchains to be used
+
oe and yp trying to make embedded easier<br>
=> dependency tree
+
many tasks involved <br>
=? feed based assembly for the yocto autobuilders
+
finding changes/errors involves many steps<br>
=> install built toolchain as toolchain (steve)
+
locked sstate coming<br>
=> generate RPMs
+
just documentation issue? no, but that is where to begin<br>
  -? external source workflow
+
many people don't want to know about build systems, they want magic to happen<br>
=> eclipse
+
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>
  
=> take to list
+
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
increasing layer quality
+
 
 +
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>
  
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
 
maintainer = quality
  
=> pb for yp users: best practice read martin's emails about broken recipes
+
* philip: for yp users: best practice read martin's emails about broken recipes
disable broken layers?
+
disable broken layers?<br>
has to be a way to tell people who don't read emails
+
has to be a way to tell people who don't read emails<br>
move or remove on 2nd iteration
+
move or remove on 2nd iteration<br>
blacklist recipe inside itself
+
blacklist recipe inside itself<br>
  add to default inherit
+
add to default inherit
=> increase pain for stuff that just fails
+
 
highlight qa fails, cheerlead & encourage people to look at
+
* increase pain for stuff that just fails
more review comments helps
+
highlight qa fails, cheerlead & encourage people to look at<br>
collect stats
+
more review comments helps<br>
explain what using stats for
+
collect stats<br>
 +
explain what using stats for<br>
  
 
advertise e.g. meta-selinux
 
advertise e.g. meta-selinux
  
=> extra fields on layer index (maintainers, readme file)
+
* extra fields on layer index (maintainers, readme file)
=> philip to send to list re updates to README files
+
* philip to send to list re updates to README files, paul to see if he can parse things out of it
  paul to see if he can parse things out of it
+
* place to put results if attached to autobuilderdont have to advocate right awaybest practices on what to bulid against - 1.4, 1.5, master, etc
=> place to put results if attached to autobuilder
+
* guidance to new maintainers
  dont have to advocate right away
+
  best practices on what to bulid against - 1.4, 1.5, master, etc
+
=> guidance to new maintainers
+
  
pb
+
Philip:
=> working demos & starting points, e.g. qt demo
+
* working demos & starting points, e.g. qt demo<br>
  cinematic
+
cinematic<br>
  working on a set of hardware, not just one
+
working on a set of hardware, not just one<br>
  also document how I made the demo - no reason for handwaving
+
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
+
  
_____________________________________________________________________________________________
+
devday - splitting by function, auto/iot/medical<br>
lune
+
getting a number of vendors interested in helping with
  
came from openwebos
+
* pb to agitate on list for demo with recipes, no bsps - non arch specific
rewritten to be in qt5
+
 
great for phones, tablets, internet of 5
+
== lune ==
need qt5 in oe-core
+
 
many demos
+
came from openwebos<br>
html5
+
rewritten to be in qt5<br>
luna is webos specific. this is  
+
great for phones, tablets, internet of 5<br>
lune os
+
need qt5 in oe-core<br>
general consensus - yes, worth making it work for oe demos
+
many demos<br>
bmills would love to see solutoin that does not require hw acceleration
+
html5<br>
good demo that can build  
+
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
 
not good for qemu
  
2 things
+
2 things<br>
need sane demo that looks better than sato
+
need sane demo that looks better than sato<br>
 
better demo for high end hardware
 
better demo for high end hardware
  
node.js is another option
+
node.js is another option<br>
 
lune uses v8 or node
 
lune uses v8 or node
  
=> jama to do initial work, will post for help when needed
+
* jama to do initial work, will post for help when needed
=> not to replace completely & pu tinto oe-core
+
* not to replace completely & put into oe-core, don't want to upstream due to requiring change in qt
don't want to upstream due to requring change in qt
+
  
_____________________________________________________________________________________________
+
== next+1 release ==
next+1 release
+
  
khem: meta-oe in yocto (1.8? no, 4.04)
+
khem: meta-oe in yocto (1.8? no, 4.04)<br>
 
poky, oe-core YP compatible
 
poky, oe-core YP compatible
  
improve deployment
+
improve deployment<br>
  currently board specific, maybe my board is different
+
currently board specific, maybe my board is different<br>
  also installer - config for 1st boot
+
also installer - config for 1st boot
common pieces - same sd card formatting several different products
+
 
so spit out sd image small then enlarged, awesome
+
common pieces - same sd card formatting several different products<br>
solves 80% of installation needs
+
so spit out sd image small then enlarged, awesome<br>
deployment config file
+
solves 80% of installation needs<br>
no sudo
+
deployment config file<br>
WIC
+
no sudo<br>
 +
WIC<br>
 
target: 1.7
 
target: 1.7
  
upgrade methods that don't use package feeds
+
upgrade methods that don't use package feeds<br>
autobuilder & tester feeds to upgrade
+
autobuilder & tester feeds to upgrade<br>
can't rely on distros to alert
+
can't rely on distros to alert<br>
khem - images want upgradabilty
+
khem - images want upgradability<br>
eg internal storage and an SD card
+
eg internal storage and an SD card<br>
  dual identical partitions for failover
+
dual identical partitions for failover<br>
best practices, industry examples
+
 
need good samples
+
best practices, industry examples<br>
=> please document this problem if you have solved it
+
need good samples<br>
in-service updates
+
=> please document this problem if you have solved it<br>
 +
in-service updates<br>
 
other option - atomic package feeds
 
other option - atomic package feeds
  
plans for clang on oe
+
plans for clang on oe<br>
fray's secondary toolchain layer
+
fray's secondary toolchain layer<br>
 
layer availalbe, not in oe-core
 
layer availalbe, not in oe-core
  
html5 applications to become first class citizens
+
html5 applications to become first class citizens<br>
oe? oe-core? bill: layer, but well supported
+
oe? oe-core? bill: layer, but well supported<br>
also for processors without hw accel
+
also for processors without hw accel<br>
 
scale down to dumb framebuffers
 
scale down to dumb framebuffers
  
lava
+
lava<br>
 
steve: deployed jenkins to apache
 
steve: deployed jenkins to apache
  
cryptographically signed sstate cache
+
cryptographically signed sstate cache<br>
 
secure development life cycles
 
secure development life cycles
_____________________________________________________________________________________________
 
online voting & other board issues
 
  
drupal site for yocto project
+
== online voting & other board issues ==
  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
+
drupal site for yocto project<br>
build a sense of community
+
registered members can vote<br>
  need advance notice - 2-3 months
+
code is built already, like surveymonkey
  find space
+
 
 +
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
 
devday - trainers, overlap with plumbers
  
 
funding discussion - ongoing
 
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>
  
  
Mark Hatle's notes:
+
----
  
OEDAM
 
  
— local.conf generation, comment it!
+
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>
  
— 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
 
  
——
+
Saturday Next+1 Future discussion...
+1 Future
+
  
— deployment (wic — partitions… , network fs)
+
— deployment (wic — partitions… , network fs)<br>
— heterogeneous systems (GPU, DSP, multi arch)
+
— heterogeneous systems (GPU, DSP, multi arch)<br>
— HTML5 apps become first class citizens
+
— HTML5 apps become first class citizens<br>

Latest revision as of 18:40, 13 May 2014

Contents

[edit] 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.

[edit] Location & Time

May 2-3, 2014
9am - 5pm

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

[edit] Goals

  • Have fun.
  • Get useful work done that benefits from high bandwidth interactions.
  • Get more people involved with the project at a higher level.

[edit] 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

[edit] 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>

[edit] Minutes

[edit] 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

[edit] 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

[edit] 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)

[edit] 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

[edit] 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

[edit] 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

[edit] 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

[edit] 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

[edit] 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

[edit] 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

Personal tools
Namespaces

Variants
Actions
Navigation
Categories
OE services
Toolbox