OEDAM 2015 Minutes

mark hatle
michael halstead
bill mills
paul eggleton
denys dmitryenko
sean hudson
armin kuster
jefro
tim orling
philip balister
sona sarmadi
martin jansa
ken sharp?
stephen arnold
changhyeok bae
herb kuta
benjamin esquivel
grant likely

phone:
richard purdie
belen barros pena
beth flanagan
bruce ashfield
____________________________________________________________
agenda:

Progress on items identified during OEDAM 2014
Development cycle
Patch review tools, improving the patch process
Tests
Removing the oe-core and meta-oe repos on github. These repos are now called openembedded-core and meta-openembedded/
People still use OE-classic from time to time. Should we remove the repo?
Security processes
Stack Overflow support
Community Development / Team Building (please add more examples/ideas... almond flour cake is always good...)
	Intro / crash course events
	Coordinated bug day sprints (openhatch, opw)
	Other group/meetup activities
	community metrics
	website
	tsc meetings
Infrastructure
Layer maintenance
____________________________________________________________
last year

lava
  bill not actively pushing
	kernel ci can use lava, not required
	focus on getting people to agree on tests
	suggest letting kernel ci process go for a while, take lessons from experience
	ti test team uses lava for more than tests
  paul kernel ci easier to use
  bill gone through dispatcher refactoring
=>  not sure where in that cycle, can find out
	cleaned up dispatche easier to come in with new board
=>  if doing kernel work, engage in kernel ci
  paul qa team gave up on lava, reconsidered
    after several weeks got test results feeding into lava
	hard to see the state of e.g. ptests
	ui doesn't show comparison summaries
  bill
	if spending effort to use lava, perhaps weekly call
  paul
    difficult to get feedback through community/ml/irc
	conclusion that lava can't really give what we need
	cluttered interface
	we will be looking to do something simpler with a proper dashboard
	will look again at kernelci
  pb
	continue watching

ongoing role of tsc
  pb
	failure to run election - koen willing to be replaced
  dd
	figure out who can vote - board sorting out members, need to not miss more than 2 ga meetings
	might want consider updating rules
  pb notify how to reinstate people
  sh can vote in
  pb ask people who dropped if they want back in
	like to get koen swapped out - martin willing to replace

why is embedded still hard
  pb made progress on making it marginally easier this year

layer quality
  pb need to talk more this year - look at minutes from last year

lune
  replacement for setup image, ref demo
> talk about improving demos

next +1
  pb sure we did everything

local.conf from third parties
  mark

____________________________________________________________
security

sona
	testing security patches high priority
	not one place to go to see all security issues
	propose security mailing list for monitoring & patching, discussing policy
fray
	team has done fixes for older versions of yp & oe
	wr monitors open source vendor security list
	"publicly closed list" info private for short time, then public
	agree not to share until public disclosure time
	pull down cves on regular basis, look for components in wr products (or yp)
	sort & mark applicability
	regularly publish cvs announcements
	always backport, don't upgrade version #s to avoid customers having to recertify
sh	same issues
pe	don't have resources in open source project to do backports that commercial has
fray already doing some of the work, can rely on commercial
	important to tell people what you know are potential problems
	give community opportunity to fix
rp	backport is a good model, openssl is an exception
bm	need to tell people to upgrade at least annually or work with osv
fray support current dev plus two releases - essentially 1year
	kernel max 2 yrs, but really only as much as people are willing to patch
	don't have resources to go more than 1yr
pb	doing best we can with resources we have
	could encourage members to support each other in this regard
	via proposed mailing list
rp	can improve by targeting cve-based patches in clear & consistent way
	standardise to make it easier/possible to find these
fray standardized format - regularize with cve numbers
rp	1 - document policy in patch sub guidelines, 2 - updating repo with existing cve, 3 - gatekeeper adopting policy
fray filenames
sh	get it documented, get people used to it, enforce
pb	promote yocto project security page & mailing list, not embargoed - discuss w/redundancy
	why another list?
jom	create social currency around posting first patch etc.
fray coordination important
	would love to get cves fixed even if they don’t apply directly to my customers
pb	we all win
fray	establish processes - whom to contact from outside etc
sa	not tracking security bugs specially?
rp	do have a security field in bugzilla
fray	just need to make sure we have a stated process
sona	important to establish relevance
	for every cve I take I build core images, etc. before sending patch
	takes time
fray	deal with reactive issues first
pb	discuss architecture at AB meeting
	need to focus on building stuff, makes sense to drive discussion into YP security group
sh	don’t want to restrict people’s flexibility
	from oe perspective, need to make sure flexibility is on opposite pivot from security
gl	counter view - being able to have well thought out security arch & default
	doesn’t change ability for people to go do their own thing
	will become more important to establish end to end architecture, boot - updates
bm	insanity checking on packages?
	many people use dto building images with blank root passwords etc
pe	default in dev mode, don’t get warnings, switch to production get security warnings as well as annoying qa warnings
gl	ship with blade guards that the user can remove
pb	not going to ship in known buggy mode
rp	need to be consistent - can’t have system that beats up for doing certain things and allows others
sh	agreed - developer workflow never disabled sometimes
	many exploits available because dev workflow items still active
sona	happened at enea
pb - we have a plan, document, etc..

=>	sona discussed offline with mark and will investigate how to upload a database of cves, possibly to the top level of the git tree so it is publicly accessible
____________________________________________________________
Infrastructure
mh - talked about various pieces of infrastructure
rp - some concern about shared patch tool, will discuss later

pb - github obsolete repository removal - june 30th (abbreviated repos go away)
pe - do we have any notice on oe-classic (openembedded) that it’s obsolete?
pb - will make sure it’s somehow tagged as obsolete
rp - rename to openembedded-classic or openembedded-obsolete (set to RO)
pb - improve text for casual observers, mark as RO end of June?
sh - we should do it now
pe - be sure to mark both github and git.openembedded.org
multiple - want to make sure it’s all set as a mirror in github to avoid people thinking github is the development, submitting pull requests to github, etc…

Martin:
PB: We need to remove obsolete repos from github?
In 2 months? Maybe too slow, lets try to target July 4th :).
SH suggests to insert bugs.

What to do with oe-classic.
People are still using it, some people are sending security patches.
First step is to rename to openembedded-classic to make sure it's clear what it is, PB suggests openembedded-obsoleted, RP openembedded-classic-deprecated. Definitely make it read-only.
PB will update the description and make it read-only asap. This does apply to github.com as well as git.openembedded.org.

What to do with pull-requests or issues created on github.com. Can we disable them?

____________________________________________________________
Layer Maintenance

meta-oe build status is much better
Heavy use of blacklisting bad recipes.
(pe) Add blacklist information/msg to layer index
(pb) sublayers appear to be working well
(ak) how about adding maintainer.inc (per recipe maintainers, etc)

Layer index
(fray) layer quality is the only thing I remember being asked about
(sean/pb/pe) who would make that decision, etc..  no clear answer
(fray) requested user annotations (very low priority ask from someone)
(pe) owner the of the layer and admins can already add annotations
(martin) if no release layers or master branch is “old” it could be annotated as possibly old
(fray) would be nice if the layer entry on the index included what branches it contains
(bill) can layer index somehow add architecture/build [can it build], other info?
(sean) immediate concern detection of dead layers
(fray/bill) if there was a way to add a comment (and have it reviewed) that would be useful..
Martin:
PNBLACKLISTs are used aggressively, status is better than last time.
PE will update layer index app to parse PNBLACKLIST and show it in the UI as well.

Separate layers work fine, help to spread the load on maintainers.

MH: Can we provide more information about layer dependencies?
Some people are complaining about too many layers, other people are complaining about too many recipes in some layers, so we need to continue trying to find good compromise.

PB: How to reflect layer quality in layer index?

MJ: Detect missing release branches in layer index.
SH&PE: Visual information in layer index when the last commit is very old.
MH: Show it also in the main page for given layers.

Bill: more information in README file like MACHINEs, IMAGEs where it should work etc, PE: this will probably quickly stale, Bill we can use this information to test the layer. Conclusion: it would be nice, but no resources to do this. Bill: maybe some system where to send annotations (blames) to layer maintainers, so that it can be shown in layer index. Low priority, but some "Leave comment" button could be useful. PB: Maybe "Like" button.

PE: Some maintenance on layer index tool, it could be more integrated with recipe tool to show more information. See
http://recipes.yoctoproject.org, the code currently lives in poky-contrib [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=alimon/RRS]. PE still needs to do the work to get this merged into the layer index codebase.

How to correctly poke people when you start depending on some layer which is no longer maintained.

Sending e-mail when layer index decides that some layer is deprecated.

Follow-up from Hangouts, Belen, Trevor, Richard talking about some reporting from nightly builds to layer index to provide some kind of quality. RP suggests "success reporting system" next to existing "error reporting system", Belen suggesting some integration with Toaster. RP: we need more new blood to work on items like this.

(pe) recipe reporting system coming for oe-core, shows how current, how regularly maintainers, when upgrades are likely due, etc.

recipes.yoctoproject.org

(multiple) if a layer is older, the people who need it should have the incentive to fork/take over the older work and update it

(martin) when the layer index thinks a layer is old/deprecated it should send an email to the maintainer, etc about the determination

[lunch]

on hangout some information about testing results, etc. (rp and belen), add recipe failures to layer index?

(rp) what is really needed is a ‘success’ reporting system


____________________________________________________________
Improving demos
(pb) sdr demo, would be nice to have different demos for future shows
(pe) best demo is something that is a shipping product


Demo

(fray) replace sato, I would like something like an HTML5 interface, maybe luna based..  reservations about QT and/or X11..

(rp) change sato to newer GTK interfaces, add games for better interactive experience, etc.  Add an HTML5 browser or similar.

(bill) demo environment, what is good for a developer vs what makes a good demo?
Good demos show more of a ‘real’ application

would like at least a once a month technical meeting to try to come up with a common ground and get people working on some of these items

Sean, Bill, Fray, Armin, Stephen Arnold, Ross B (volunteered by RP) & jefro

Martin:
PB: good improvement on meta-sdr demo images, useful for different HW shown in Yocto booth. Suggestion to use more accessible demo, so that you don't have to explain how software radio works.
PE: Now when we have Toaster able running the builds, we should use that more to demo the build system itself. We need more powerful HW than Paul's laptop, having the database already populated etc.
PB: Showing Toaster on the real build, e.g. building the demo image running on HW shown next to Toaster demo.

MH: We need remove sato, it's giving bad impression to people. Last year we were looking into Luneui.
Follow-up later after development process.
Discussion about different people doing demo for different purpose, someone wants to sell HW and the demo UI is just to show features of given HW, someone else wants to show how simple it is to use the build system to build demo image and modify it. HTML5 could help to demo reasonable UI for developers who are just want to blink some lights on real HW and they aren't good UI developers. RP says that someone else should drive creation of the demos, then we can discuss which demos would be good to have in oe-core.

PB: we should migrate from sato to some more interesting demos, but nobody in room sign-up to demo work group :).
Bill: lets talk about it for an hour per month to get some progress
List for people interested in demo SH, Armin, MH, Jeff, Bill, Ross.

_______________________________________
Patch review process

RP	flow process for oe-core patches -
J=>	verify with rp after meeting
	collect 30-40 batch, hoovering off mailing list
	work in batches
bm	how often does this happen?
rp	3-4 times/week
	scripts to process mailboxes
	manual process for checking & signing off
	works with v1/v2, doesn’t work with others
tim & fray illustrate some aberrations in the process
fray	suggests reminder for patches that may get pushed to next release
tim	intentionally waited for end of release process
gl	to RP: anyone you trust to delegate responsibilities to
rp	some contribs put in series of patches eg bruce 5-10 at a time
	x has different level of testing from y
	depend on maintainers
gl	expect to see more delegation as project matures
	accepting git tree merges direct, or always touch patches?
rp	usually very rarely actually touch the patch
	usually dumping into tree, if fail then go back to submitter
	& relatively self contained, so not much merge conflict eg like the kernel
	use git workflow, tend to rebase to reset history
	oe contributors ok to send in patches, aggregating & testing not interesting to people
tim	martin recommends people use ci
pb	bad habits of testing patches only on machine we have in front of us
gl	automated sanity test on merged tree, kicks email back to submitter & maintainer
rp	full tree builds take a long time, difficult to automate
	autobuilder public logs, errors
	can’t tolerate gerritt
	patchwork does provide a lot of what we need - problems difficult to update our patches
	interested to compare rp’s scripts to patchwork
sa	possible to use github
gl	every maintainer reading every patch tends not to scale
	github doesn’t resolve who are the people involved
	multiple git repos become powerful when multiple maintainers need to access master
rp	problem to solve is not review process, but giving contributors feedback on what happened to their patches
bm	supposed to get this feedback from patchwork
pe	on intel graphics driver use patchwork, putting resources into improving patchwork
sh	resource issue, process issue, tools issue?
pb	improve tool to match our process
rp	by improving tool we improve process
sh	tool seems to be the one that makes most sense
bm	agreed
rp	tool improvement is the one we have the most chance of success with
mj	pw doesn’t give much advantage (described process)
sh	improve pw to automate processes that are now manual
pe	currently just collects patches, work to improve pw not onerous
dd	some work already going on in community
=>	pe plans to try to find someone to do this work
	agree that it doesn’t work now for our needs

Martin:
PB: people are still sometimes complaining and annoyed by patches being missed or in unknown state.
Happens to our own patches as well, so it's real problem.
RP: life cycle of oe-core patches, ML, people can review and feedback on them, if nobody screams immediately the patch is queued to MUT in batches 30-50 changes, when MUT discovers the issues, remove some patches, rinse and repeat until the builds are green. If there is a lot of issues, the intake slows down. There is also delay, because the issues aren't reported immediately until it's clear that it's really the patch which is causing the issues.

3-4 batches per week, RP has some scripts to help him with preparing the patches for batch, sometimes the scripts don't work 100% and need some manual interaction. Scripts don't work well with backports to release branches.

Timo: sometimes it happens when the patch is submitted in bad time (like close to release) and then it's forgoten before the branches are open for new developement again.

We need some notification when the patch is pushed back to next development cycle or for few weeks.

RP: we already have master-next-1.9 branch for queuing the patch for next release, so we're trying to learn from the mistakes and improve the process.

Is there some way for people to prepare bigger pull-request and then getting them merged based on trust to person submitting the pull-request. RP: it's mostly about submitting patches from people who are know to work in different area, like patches from Khem for toolchain or kernel pull request from Bruce.

RP: Usually I don't need to touch the patches itself, in most cases just cherry-pick them and lately only a few conflicts, because the patches are usually well contained. E.g. for toaster the pull-requests are usually merged atomically.

Timo: How to improve CI and encourage people following the same CI testing before submitting the patches.
PB: we all have the bad habbit of testing it on the MACHINE we're working with.
Kernel has the same issue for long time, someone merging many branches and clever scripts to throw out branches and bisecting the changes causing issues.
RP: this is a bit complicated because of build time, so we cannot automatically trigger it for every patch, because it takes few hours to discover that something went wrong.
PB: logs from autobuilder should be more promoted, there are also logs in error reporting system (http://errors.yoctoproject.org)
RP: tried gerrit and hate it, patchwork should help a lot with current work flow, it would be nice to hook RP's mailbox scripts with patchwork. It would be nice to have more information about given patches. Possibly some way of syncing "status" from RP's mailbox to status in patchwork.
SA: Possible to move some of this project to github so it's more visible.
RP: I don't see how this would help when most of the review is happening on mailing list.
This doesn't help with huge patches and how to split them into smaller chunks managed by different maintainers, github throwing technology on this problem doesn't help with this "workflow"/"maintainership" issue.
This would work with multiple repositories being the only way to get patches into some area and these repos having dedicated maintainers and then RP just merging whole pull-requests from these trusted sub-trees.
PE: intel graphics group is using patchwork internally and they are improving the patchwork to better support tracking status of the patches, so if we continue to use patchwork we'll eventually get these improvements as well.

SH: We have 3 issues: resources, tool, process

Timo: it's also about the quality of the patches, if we can immediately report obvious issues back to contributor.

MJ: Patchwork isn't giving me anything, I have to maintain it manually.

PE: The work which needs to be done on patchwork is not that huge, we just don't have anyone to work on it.

Ongoing issue of patchwork is that it doesn't pick any other interaction on ML, so when you have existing workflow in ML, then you shouldn't need to duplicate any status update flow in patchwork.

SH: what action item we can get from this?
PE: I'll try to find someone to work on this.

Agreement is that it currently doesn't work for us at all.

PB: How to encourage how to more properly/completely test the changes people are contributing.
RP: Many people submit patches which break multiarch, because they never run multiarch builds or now that they even exist.People can install autobuilder with 3 lines, but problem is the resource to build and test all the combinations.

Identifying people who can do some pre-screening of patches, so that the patches are already tested by selected people who get access to powerfull build machines.

SH: Can we open autobuilder to more people to submit jobs?
RP: Maybe yes if we have more hw and e.g. release builds are separated from it. Or how to re-use existing resources people have and not use. It's also important to integrate more runtime testing like ptest and qemu* builds now can be booted automatically and run the runtime tests with just one line in local.conf.

Michael: maybe there is some hw we can use if there is clear priority that some builds can be executed only when anything else is running

It can work on some agreement about how much resources you should use, you get account and if you abuse it, your account will get disabled.
AI: Michael will check if it's possible with current autobuilder.

MJ: we can still test it in batches, to save work for individual contributors

PE: Running self-tests in bitbake on autobuilder
RP: We should just enable it on autobuilder, now it's executed manually but periodically, it's ready to be enabed now
Michael: No concerns yet, does it need anything special
PE: Do we want to split it into quick and full suite, because full suite takes long.
RP: Yes that would be useful.

PE: Change of practise, we already have bitbake self test, oe self test, ptest and runtime tests. I would like to add functionality tests together with implementation of new features. It requires extra work, but with project this size we need to do soon.
MH: Depends on class of patches, some type of changes are easier to test, something we cannot ever expect community to submit tests for.
PE: It should be mostly for new utilities for example.
RP: Good example are tests for bitbake fetcher or datastore where we have a lot of corner cases. Missing tests are for example in shared state signatures, there are some tests in bitbake itself, but not covering many real-world cases.
PE: Or test cases for read-only-rootfs or tiny. PE is collecting the list of areas where we need the testing the most.

PB: It would be helpful to have couple of simple tasks which can be brought to Yocto AB and ask other members to contribute engineers to implement some of these. Just to increase participation from other companies.
PE: I can convert the list into list of bugzilla improvement tickets.
Timo: I can volunteer, it's great place to start getting more deep into the tools. It would be good for package maintainers to look harder if the component already provides ptest or other test infrastracture to properly enable it in recipes as well.

Martin:
MH: we have some people using package management and trying to upgrade from 1.5 to 1.9 for example, we're not testing the upgrade-path well enough. Also we need to think about syncing development SDKs with package based upgrades on devices already running in field. More and more people are moving to package based upgrades. We need universal solution how to create matching SDK based on what is on the device and not all of the packages had to be built and deployed together with initial image.
PB: someone is already using OE for building OS used in medial devices with all the ceritificactions.
MH: Certification is too complicated for full blown Linux OS, because sometimes you need to audit each component line by line, sometimes even auditing some parts of compiler used to build it.
MH: Is Smart for RPM still the best RPM packages? Currently looking for Smart maintainer, it could be someone from Yocto or OE.
MJ: Opkg is also without Maintainer ATM after Paul stepped down.
PB: Someone from NI already volunteered to take over the maintainership from Paul. NI planing to add new feature to support their goals.
DD: Which version for RPM we're using.
MH: RPM5 since the beginning of oe-core and it's default packaging format for Yocto. Maybe we should look into DNF (RedHat replacement for yum), they are also looking into RPM5 so it would be useful to get in touch with DNF. RPM5 is completely GPL so you can use openssl, RPM4 isn't completely GPL so you can use different crypto backends, but not openssl.

Conclusion we need to concentrate on package managers and package feeds.

RP: Another problem is that people can expect to run builds on multiple machines and bitbake doesn't have any knowledge about other machines or building for different target MACHINEs and making sure we can reuse common set of packages.
DD: Useful to build multiple MACHINEs with single bitbake call.
HK: LGE is interested in faster multi-MACHINE builds.
PE: Yes there is interest, 2 people asked about it on ELC.
MH: People have multiple boards with different SOC, but the same ARM core and they want to share armv7a packages across them and just build BSP and application specific bits and share the rest.
SH: There are also heterogenous CPU architectures where people want to create it with single build.

HK: Polluting the MACHINE dependency in MACHINE-independent component. When application isn't MACHINE dependent but uses MACHINE_ARCH library. Maybe integrating something like ABI-checker which can verify that the interface of these 2 MACHINE_ARCH is identical then shouldn't require the application to rebuild.
RP: The problem is that the current code counts all the signatures just from input variables, cannot prune the dependencies after building the object and running the ABI checker.
RP: One of the problem is that amount of packages which are rebuilt with newer version in many cases unnecessary, because sstate is very sensitive for changes, we can have additional tooling which will compare resulting binaries and mask those which doesn't need to be upgraded on target.
RP: It's possible already by running e.g. ABI-checker outside bitbake and then excluding the dependency in bitbake variable and replace it with single variable which says what ABI version it is.

HK: Another issue we need to resolve is creating separate partitions for the same top-level image.
RP: Have you tried to use wic.

= Development cycle II by PE =
Scheme for milestones, releases.
MH: Some people asked for 5 milestones, but for unknown reasons.
RP: Adding another milestone will just generate more load on people doing releases and there is also time needed for planing what to do in the milestone.
Can we apply something from Agile to resolve this issue?
In theory we should have defined time boxes and at the end of each we have production quality, so we shouldn't need "stabilization" period at the end before the release.
The biggest issue is how to ease the period just before release, when people are rushing to meet deadline, while also trying not to take any big changes from comunity which can distabilize the builds.
RP: Many people are keeping the patches for the last minute and then trying to get it in, which sometimes still takes couple of iterations and AB runs.
RP: There is list of features which will be included in the release. e.g. developer workflow improvements were on the list and it either has to be merged or the release has to be postponed, binutils upgrade on the other hand is risky and it can be postponed after the release, because we didn't promissed to deliver it on the feature list
PE: Do we need separate release process for OE, or do we continue to just follow Yocto release cycle.
PB: More information about the status of the release so that people know which kind of patches will be accepted at given time and what will probably get postponed, just because there is a milestone build coming up.
Armin: Is there clearly defined code-freeze date? It's not show on schedule page.
PE: Can we consider google calendar for the sharing the important release dates?
PB: Yes, but only in addition to the e-mail.

Armin: Is cut-off date the same as code freeze
PE: Discussion about the terminology for freeze date.

PB: Yocto project technical meeting, very terse agenda and minutes.
MH: Usually relatively short
PE: Useful mostly for people who prefer to attend the conference call instead of watching the mailing list.
RP: It would be useful to have the summary from the meeting having in written form and send it to ML as well.
Jefro: Someone else could be taking the notes during these meetings.

= Source mirror =
MJ: Tom and me already have the sources from bitbake world builds in new location, we need to move existing sources from sources.openembedded.org to this location and when we're ready we'll just update DNS records to point to new location.
AI: PB or Michael will update DNS record when we're ready (a month)


_______________________________________
Tests

(Friday 2pm)
rp	autobuilder provides a lot of these features regarding testing
(discussion of using autobuilder) also automated testing of qemu images, ptests
=>	michael look into using autobuilders for priority patches

pe	oe self test doesn’t run on autobuilder, takes too long
how can we find more resources and/or cut tests
stuff you wouldn’t get from a build
rp	running bitbake in different contexts

pe	bitbake selftest, oe selftest, runtime kits - like to see adding tests for any new functionality when we add that functionality, so start with a baseline - know it works when checked in
fray	don’t think can get from community members, good requirement for large-scale features added by YP maintainers -- a reasonable requirement for contributions that add or make major modifications to functionality (i.e. image creation)
pe	did for devtool, extra work but very useful
	building up a list where I think we need better tests
	eg regression tests for rootfs
fray	help with people going into existing systems
pb	some people may need mentoring
tim	like me - started looking for ptest for package I’m uploading

_______________________________________
Development cycle

long-term package feeds/sdk

pe	does current dev cycle work
fray	cross btw testing and dev cycle
	users doing package based installs - no testing in the community
pe	open enhancement to do that
fray	need way to match what’s on dev system to sdk
	just been discussed at this point\
	someone creates an image, running in field, they upgrade packages on that
	at some point have to resync sdk to that image
	need to create sysroot & repo (binary package feeds?)
pe	not all usage models are
fray	used to be cgl type systems, now showing up in smaller systems
pe	more worried about whether they have patching, sdk is easier to manage
fray	oe may not solve this, but provisioning server needs to know what’s on a device
	create custom sdk based on a provisioning script
	traditional image model doesn’t match any more
jom	could potentially do from manifest
fray	or src on dev, but app may not have src
	mostly networking devices
	say process up to x standard - if safety critical, no chance on linux
(discussion about certification issues)
	becoming an expectation

using smart for rpm

fray	smart maintainer looking for a new maintainer
	yp or look for something else like dnf
herb	lg interested in support for multiple partitions
fray	filesystem changeset field upgrades
	big co’s coming up with various solutions
(discussion about paul & alejandro)
fray	if want basic package mgmt on small device, opkg is only answer
	large device rpm is right answer
	rpm more metadata, more validation

development cycle


rp	bitbake implicit knowledge of MACHINE variable?

herb	abi checker tool, use for shared state determination
herb 	exclude machine from dependencies
herb	opengl interface same, diff implementation shouldn’t pollute callers making them machine dependent
fray	pain to rectify
rp	check from input - have to have the output to run tool against in order to generate checksum
	want to turn to server and say do you have this or should we rebuild it? can’t do that if have to resolve output
rp	depends on problem trying to solve. currently shared state sensitive to change
	could integrate with PR server
herb	don’t use package feeds or PR server - when fix bug in low level component, rebuild system when don’t need to.
fray	wish simple way to tag “my change causes this item to rebuild, but checksum returned is same until I change it”
herb	fetch, unpack, patch, abi check
rp	whitelist dependency in shared state code - if gl library, nothing has dep on gl lib itself
	generate <<>> manually into package
herb	maybe second run of bitbake
fray	lots of nodding going on


herb	prefer common way to handle packages into multiple partitions
pe	could do in separate builds and combine at end
rp/pe	look at wic tool

[break]

<revise agenda>

development cycle

pe	4 milestones
suggestions for improvement
	defined within YP but does OE have that? technically no, but practically yes
fray	asked annually - 4 cycles working very well
	some people would like one more - same cycle components but 5
rp	supposed to have 5, planning supposed to happen in conjunction with the release
	4 makes release more manageable
fray	option is 1st one has no release
rp	reality is that planning happens after release
fray	milestone 0 could be planning
(discussion of agile and waterfall)
pe	occasionally hear cramming things into meet deadline
	haven’t figured out a way to do that better, may not immediately be one
fray	for an open source project I don’t think we could do better
pe	release has some expected level of functionality, rush to complete at end
rp	people sometimes do tend to hold things until the last minute
	“there’ll be an RC2, right?”
pe	usually functionality, not security or bugs
rp	eg khem wanted a binutils update
	really came to release point and just couldn’t, too much risk, would break build
	if say develop tooling and it is late and we extend..
	create list of things that will be accepted
pb	remind people early when dates are coming up
fray	release info easy to find, but people don’t look
pe	yp or oe releases? oe just piggybacks yp release - different conversation
pb	remind list, take this type of patches to x point, y type after etc
	include boilerplate of what this means & put on list
pe	we could point to the how-to-submit-patch page
=>	pe update web page to talk about timing for submissions, describe process
ak	is there a code freeze?
pe	schedule page, lists candidates but not freeze dates (or other submission dates)
fray	anything we can do to get rid of the excuse to be lazy
pb	exactly

pb	yp technical meeting, terse minutes
	would be great if minutes
pe	in general that meeting is good for people not on the mailing list, RP does a readout
=>	J ask sjolley to write RP’s readout into the minutes and send out


oe source mirror

pe 	upstream sources have gone missing for recipes in meta-oe and other layers curated by oe
	meanwhile no one can build resources, other things break
	great idea to collect sources
	martin & tom have done that, so almost there
	eg backup strategy
	then everything martin builds on autobuilder won’t have that issue

adjourn until 10am pdt


_______________________________________
Community

Martin:
Organizing bug scrub weekends, do we want to do it tomorrow. Deferred to tomorrow.



_______________________________________
_______________________________________
SAT 28 MAR 2015
mark
paul
sona
sean
armin
martin
tim
philip
ken
stephen
jefro
richard on phone
changhyeok on hangout
_______________________________________
# packages (armin)

ak	should there be a limit on # packages
pb	oe is sort of a dumping ground, want to be more organized
	with new layer structure, no limit on packages, but good to keep in chunks
	martin building world for some def of world, set of layers he considers to be worldlike
fray	oecore has self imposed feature limit rather than numerical limit
rp	poky/sato gives us something to test
?>	could move meta-sato into meta-poky
fray	people do use sato for demos whether or not it is appropriate
rp	would like to see <<>> instead of sato
pb	eg someday x11 may go away, maybe not in my lifetime but I want oe to last longer than my lifetime
=>	keep talking within tsc, scrub oe-core to see where the line is - “right-sizing” oe-core
all	discussion cycled back - strong interest in revising and many alternative options discussed, but no owner yet
_______________________________________
documentation

=>	pb to mention to ab the need for more technical documentation

=>	jefro to schedule meeting about demos, test images, sato, etc
	identify problem, role of sato, suitable alternatives, usage cases
_______________________________________
OE eV structure
changing ev structure to streamline, possibly bringing to us and dissolving ev - sean working on it
may be longer than GA

spi is working well

next oedam after elc in san diego in 1yr, possible oedem after elce

--
patch queue maintenance
ak	maint branches not spilt out
pe	should be able to do stuff like that with patchwork
=>	pe add for oe-core, automate - part of patchwork

_______________________________________
Community
Intro / crash course events
sa	makerspace in goleta want yp crash course
	would like to push more
all	agreement
=>	jefro to investigate materials & things for websites

Coordinated bug day sprints (openhatch, opw)
jefro	bite size bugs needed
rp	bugzilla - initial triage group meets weekly
=>	remind stephen to add message onto bug list to let people know about the triage group
	also bug page on wiki
fray	https://wiki.yoctoproject.org/wiki/Bug_Triage
pe	tried to set up a bug day w/tsc meeting, got very little participation
->	pb/pe set up bug day morning US/afternoon UK/EU, possibly separate event for asia
->	jefro investigate webinar format
	training future maintainers
sh	janitors list
pe	misbranded

website, wiki
sh	need consensus, jack mitchell needed
pb	need to edit wiki
	need to point to yp wiki
pe	identified things, made oe classic read-only
	now can remove things
=>	jefro to organize board, admin issue

tsc meetings
	communication piece gone away, valuable
fray	let’s do one every 2 months and identify issues & communicate
	remind people ahead of time
pb	a lot of oe issues revolve around communication
	would like to see the tsc is improve workflow theme & track through year
	give a goal
	this year we concluded good job on layer quality
	next year improve workflow
	tsc can be org that monitors progress through year
rp	which things need commnicating
fray	afraid a lot of comm is one way, lacking ability to listen
out of 6 public meetings on #oe only had a few instances
organized time to have a discussion on irc
=>	jefro to organize meetings
rp	worried that tsc will go do work themselves
pb	not asking to fix, asking to report back
rp	yocto project has processes and resources
pb	..though contribution is uneven

community metrics
=>	jefro	talk to board

Other group/meetup activities

_______________________________________
tshirts