daily pastebin goal
21%
SHARE
TWEET

OEDAM 2015 Minutes

a guest May 11th, 2015 266 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. mark hatle
  2. michael halstead
  3. bill mills
  4. paul eggleton
  5. denys dmitryenko
  6. sean hudson
  7. armin kuster
  8. jefro
  9. tim orling
  10. philip balister
  11. sona sarmadi
  12. martin jansa
  13. ken sharp?
  14. stephen arnold
  15. changhyeok bae
  16. herb kuta
  17. benjamin esquivel
  18. grant likely
  19.  
  20. phone:
  21. richard purdie
  22. belen barros pena
  23. beth flanagan
  24. bruce ashfield
  25. ____________________________________________________________
  26. agenda:
  27.  
  28. Progress on items identified during OEDAM 2014
  29. Development cycle
  30. Patch review tools, improving the patch process
  31. Tests
  32. Removing the oe-core and meta-oe repos on github. These repos are now called openembedded-core and meta-openembedded/
  33. People still use OE-classic from time to time. Should we remove the repo?
  34. Security processes
  35. Stack Overflow support
  36. Community Development / Team Building (please add more examples/ideas... almond flour cake is always good...)
  37.         Intro / crash course events
  38.         Coordinated bug day sprints (openhatch, opw)
  39.         Other group/meetup activities
  40.         community metrics
  41.         website
  42.         tsc meetings
  43. Infrastructure
  44. Layer maintenance
  45. ____________________________________________________________
  46. last year
  47.  
  48. lava
  49.   bill not actively pushing
  50.         kernel ci can use lava, not required
  51.         focus on getting people to agree on tests
  52.         suggest letting kernel ci process go for a while, take lessons from experience
  53.         ti test team uses lava for more than tests
  54.   paul kernel ci easier to use
  55.   bill gone through dispatcher refactoring
  56. =>  not sure where in that cycle, can find out
  57.         cleaned up dispatche easier to come in with new board
  58. =>  if doing kernel work, engage in kernel ci
  59.   paul qa team gave up on lava, reconsidered
  60.     after several weeks got test results feeding into lava
  61.         hard to see the state of e.g. ptests
  62.         ui doesn't show comparison summaries
  63.   bill
  64.         if spending effort to use lava, perhaps weekly call
  65.   paul
  66.     difficult to get feedback through community/ml/irc
  67.         conclusion that lava can't really give what we need
  68.         cluttered interface
  69.         we will be looking to do something simpler with a proper dashboard
  70.         will look again at kernelci
  71.   pb
  72.         continue watching
  73.  
  74. ongoing role of tsc
  75.   pb
  76.         failure to run election - koen willing to be replaced
  77.   dd
  78.         figure out who can vote - board sorting out members, need to not miss more than 2 ga meetings
  79.         might want consider updating rules
  80.   pb notify how to reinstate people
  81.   sh can vote in
  82.   pb ask people who dropped if they want back in
  83.         like to get koen swapped out - martin willing to replace
  84.        
  85. why is embedded still hard
  86.   pb made progress on making it marginally easier this year
  87.  
  88. layer quality
  89.   pb need to talk more this year - look at minutes from last year
  90.  
  91. lune
  92.   replacement for setup image, ref demo
  93. > talk about improving demos
  94.  
  95. next +1
  96.   pb sure we did everything
  97.  
  98. local.conf from third parties
  99.   mark
  100.  
  101. ____________________________________________________________
  102. security
  103.  
  104. sona
  105.         testing security patches high priority
  106.         not one place to go to see all security issues
  107.         propose security mailing list for monitoring & patching, discussing policy
  108. fray
  109.         team has done fixes for older versions of yp & oe
  110.         wr monitors open source vendor security list
  111.         "publicly closed list" info private for short time, then public
  112.         agree not to share until public disclosure time
  113.         pull down cves on regular basis, look for components in wr products (or yp)
  114.         sort & mark applicability
  115.         regularly publish cvs announcements
  116.         always backport, don't upgrade version #s to avoid customers having to recertify
  117. sh      same issues
  118. pe      don't have resources in open source project to do backports that commercial has
  119. fray already doing some of the work, can rely on commercial
  120.         important to tell people what you know are potential problems
  121.         give community opportunity to fix
  122. rp      backport is a good model, openssl is an exception
  123. bm      need to tell people to upgrade at least annually or work with osv
  124. fray support current dev plus two releases - essentially 1year
  125.         kernel max 2 yrs, but really only as much as people are willing to patch
  126.         don't have resources to go more than 1yr
  127. pb      doing best we can with resources we have
  128.         could encourage members to support each other in this regard
  129.         via proposed mailing list
  130. rp      can improve by targeting cve-based patches in clear & consistent way
  131.         standardise to make it easier/possible to find these
  132. fray standardized format - regularize with cve numbers
  133. rp      1 - document policy in patch sub guidelines, 2 - updating repo with existing cve, 3 - gatekeeper adopting policy
  134. fray filenames
  135. sh      get it documented, get people used to it, enforce
  136. pb      promote yocto project security page & mailing list, not embargoed - discuss w/redundancy
  137.         why another list?
  138. jom     create social currency around posting first patch etc.
  139. fray coordination important
  140.         would love to get cves fixed even if they don’t apply directly to my customers
  141. pb      we all win
  142. fray    establish processes - whom to contact from outside etc
  143. sa      not tracking security bugs specially?
  144. rp      do have a security field in bugzilla
  145. fray    just need to make sure we have a stated process
  146. sona    important to establish relevance
  147.         for every cve I take I build core images, etc. before sending patch
  148.         takes time
  149. fray    deal with reactive issues first
  150. pb      discuss architecture at AB meeting
  151.         need to focus on building stuff, makes sense to drive discussion into YP security group
  152. sh      don’t want to restrict people’s flexibility
  153.         from oe perspective, need to make sure flexibility is on opposite pivot from security
  154. gl      counter view - being able to have well thought out security arch & default
  155.         doesn’t change ability for people to go do their own thing
  156.         will become more important to establish end to end architecture, boot - updates
  157. bm      insanity checking on packages?
  158.         many people use dto building images with blank root passwords etc
  159. pe      default in dev mode, don’t get warnings, switch to production get security warnings as well as annoying qa warnings
  160. gl      ship with blade guards that the user can remove
  161. pb      not going to ship in known buggy mode
  162. rp      need to be consistent - can’t have system that beats up for doing certain things and allows others
  163. sh      agreed - developer workflow never disabled sometimes
  164.         many exploits available because dev workflow items still active
  165. sona    happened at enea
  166. pb - we have a plan, document, etc..
  167.  
  168. =>      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
  169. ____________________________________________________________
  170. Infrastructure
  171. mh - talked about various pieces of infrastructure
  172. rp - some concern about shared patch tool, will discuss later
  173.  
  174. pb - github obsolete repository removal - june 30th (abbreviated repos go away)
  175. pe - do we have any notice on oe-classic (openembedded) that it’s obsolete?
  176. pb - will make sure it’s somehow tagged as obsolete
  177. rp - rename to openembedded-classic or openembedded-obsolete (set to RO)
  178. pb - improve text for casual observers, mark as RO end of June?
  179. sh - we should do it now
  180. pe - be sure to mark both github and git.openembedded.org
  181. 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…
  182.  
  183. Martin:
  184. PB: We need to remove obsolete repos from github?
  185. In 2 months? Maybe too slow, lets try to target July 4th :).
  186. SH suggests to insert bugs.
  187.  
  188. What to do with oe-classic.
  189. People are still using it, some people are sending security patches.
  190. 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.
  191. PB will update the description and make it read-only asap. This does apply to github.com as well as git.openembedded.org.
  192.  
  193. What to do with pull-requests or issues created on github.com. Can we disable them?
  194.  
  195. ____________________________________________________________
  196. Layer Maintenance
  197.  
  198. meta-oe build status is much better
  199. Heavy use of blacklisting bad recipes.
  200. (pe) Add blacklist information/msg to layer index
  201. (pb) sublayers appear to be working well
  202. (ak) how about adding maintainer.inc (per recipe maintainers, etc)
  203.  
  204. Layer index
  205. (fray) layer quality is the only thing I remember being asked about
  206. (sean/pb/pe) who would make that decision, etc..  no clear answer
  207. (fray) requested user annotations (very low priority ask from someone)
  208. (pe) owner the of the layer and admins can already add annotations
  209. (martin) if no release layers or master branch is “old” it could be annotated as possibly old
  210. (fray) would be nice if the layer entry on the index included what branches it contains
  211. (bill) can layer index somehow add architecture/build [can it build], other info?
  212. (sean) immediate concern detection of dead layers
  213. (fray/bill) if there was a way to add a comment (and have it reviewed) that would be useful..
  214. Martin:
  215. PNBLACKLISTs are used aggressively, status is better than last time.
  216. PE will update layer index app to parse PNBLACKLIST and show it in the UI as well.
  217.  
  218. Separate layers work fine, help to spread the load on maintainers.
  219.  
  220. MH: Can we provide more information about layer dependencies?
  221. 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.
  222.  
  223. PB: How to reflect layer quality in layer index?
  224.  
  225. MJ: Detect missing release branches in layer index.
  226. SH&PE: Visual information in layer index when the last commit is very old.
  227. MH: Show it also in the main page for given layers.
  228.  
  229. 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.
  230.  
  231. PE: Some maintenance on layer index tool, it could be more integrated with recipe tool to show more information. See
  232. 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.
  233.  
  234. How to correctly poke people when you start depending on some layer which is no longer maintained.
  235.  
  236. Sending e-mail when layer index decides that some layer is deprecated.
  237.  
  238. 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.
  239.  
  240. (pe) recipe reporting system coming for oe-core, shows how current, how regularly maintainers, when upgrades are likely due, etc.
  241.  
  242. recipes.yoctoproject.org
  243.  
  244. (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
  245.  
  246. (martin) when the layer index thinks a layer is old/deprecated it should send an email to the maintainer, etc about the determination
  247.  
  248. [lunch]
  249.  
  250. on hangout some information about testing results, etc. (rp and belen), add recipe failures to layer index?
  251.  
  252. (rp) what is really needed is a ‘success’ reporting system
  253.  
  254.  
  255. ____________________________________________________________
  256. Improving demos
  257. (pb) sdr demo, would be nice to have different demos for future shows
  258. (pe) best demo is something that is a shipping product
  259.  
  260.  
  261. Demo
  262.  
  263. (fray) replace sato, I would like something like an HTML5 interface, maybe luna based..  reservations about QT and/or X11..
  264.  
  265. (rp) change sato to newer GTK interfaces, add games for better interactive experience, etc.  Add an HTML5 browser or similar.
  266.  
  267. (bill) demo environment, what is good for a developer vs what makes a good demo?
  268. Good demos show more of a ‘real’ application
  269.  
  270. 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
  271.  
  272. Sean, Bill, Fray, Armin, Stephen Arnold, Ross B (volunteered by RP) & jefro
  273.  
  274. Martin:
  275. 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.
  276. 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.
  277. PB: Showing Toaster on the real build, e.g. building the demo image running on HW shown next to Toaster demo.
  278.  
  279. MH: We need remove sato, it's giving bad impression to people. Last year we were looking into Luneui.
  280. Follow-up later after development process.
  281. 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.
  282.  
  283. PB: we should migrate from sato to some more interesting demos, but nobody in room sign-up to demo work group :).
  284. Bill: lets talk about it for an hour per month to get some progress
  285. List for people interested in demo SH, Armin, MH, Jeff, Bill, Ross.
  286.  
  287. _______________________________________
  288. Patch review process
  289.  
  290. RP      flow process for oe-core patches -
  291. J=>     verify with rp after meeting
  292.         collect 30-40 batch, hoovering off mailing list
  293.         work in batches
  294. bm      how often does this happen?
  295. rp      3-4 times/week
  296.         scripts to process mailboxes
  297.         manual process for checking & signing off
  298.         works with v1/v2, doesn’t work with others
  299. tim & fray illustrate some aberrations in the process
  300. fray    suggests reminder for patches that may get pushed to next release
  301. tim     intentionally waited for end of release process
  302. gl      to RP: anyone you trust to delegate responsibilities to
  303. rp      some contribs put in series of patches eg bruce 5-10 at a time
  304.         x has different level of testing from y
  305.         depend on maintainers
  306. gl      expect to see more delegation as project matures
  307.         accepting git tree merges direct, or always touch patches?
  308. rp      usually very rarely actually touch the patch
  309.         usually dumping into tree, if fail then go back to submitter
  310.         & relatively self contained, so not much merge conflict eg like the kernel
  311.         use git workflow, tend to rebase to reset history
  312.         oe contributors ok to send in patches, aggregating & testing not interesting to people
  313. tim     martin recommends people use ci
  314. pb      bad habits of testing patches only on machine we have in front of us
  315. gl      automated sanity test on merged tree, kicks email back to submitter & maintainer
  316. rp      full tree builds take a long time, difficult to automate
  317.         autobuilder public logs, errors
  318.         can’t tolerate gerritt
  319.         patchwork does provide a lot of what we need - problems difficult to update our patches
  320.         interested to compare rp’s scripts to patchwork
  321. sa      possible to use github
  322. gl      every maintainer reading every patch tends not to scale
  323.         github doesn’t resolve who are the people involved
  324.         multiple git repos become powerful when multiple maintainers need to access master
  325. rp      problem to solve is not review process, but giving contributors feedback on what happened to their patches
  326. bm      supposed to get this feedback from patchwork
  327. pe      on intel graphics driver use patchwork, putting resources into improving patchwork
  328. sh      resource issue, process issue, tools issue?
  329. pb      improve tool to match our process
  330. rp      by improving tool we improve process
  331. sh      tool seems to be the one that makes most sense
  332. bm      agreed
  333. rp      tool improvement is the one we have the most chance of success with
  334. mj      pw doesn’t give much advantage (described process)
  335. sh      improve pw to automate processes that are now manual
  336. pe      currently just collects patches, work to improve pw not onerous
  337. dd      some work already going on in community
  338. =>      pe plans to try to find someone to do this work
  339.         agree that it doesn’t work now for our needs
  340.  
  341. Martin:
  342. PB: people are still sometimes complaining and annoyed by patches being missed or in unknown state.
  343. Happens to our own patches as well, so it's real problem.
  344. 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.
  345.  
  346. 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.
  347.  
  348. 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.
  349.  
  350. We need some notification when the patch is pushed back to next development cycle or for few weeks.
  351.  
  352. 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.
  353.  
  354. 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.
  355.  
  356. 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.
  357.  
  358. Timo: How to improve CI and encourage people following the same CI testing before submitting the patches.
  359. PB: we all have the bad habbit of testing it on the MACHINE we're working with.
  360. 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.
  361. 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.
  362. PB: logs from autobuilder should be more promoted, there are also logs in error reporting system (http://errors.yoctoproject.org)
  363. 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.
  364. SA: Possible to move some of this project to github so it's more visible.
  365. RP: I don't see how this would help when most of the review is happening on mailing list.
  366. 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.
  367. 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.
  368. 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.
  369.  
  370. SH: We have 3 issues: resources, tool, process
  371.  
  372. Timo: it's also about the quality of the patches, if we can immediately report obvious issues back to contributor.
  373.  
  374. MJ: Patchwork isn't giving me anything, I have to maintain it manually.
  375.  
  376. PE: The work which needs to be done on patchwork is not that huge, we just don't have anyone to work on it.
  377.  
  378. 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.
  379.  
  380. SH: what action item we can get from this?
  381. PE: I'll try to find someone to work on this.
  382.  
  383. Agreement is that it currently doesn't work for us at all.
  384.  
  385. PB: How to encourage how to more properly/completely test the changes people are contributing.
  386. 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.
  387.  
  388. 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.
  389.  
  390. SH: Can we open autobuilder to more people to submit jobs?
  391. 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.
  392.  
  393. 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
  394.  
  395. 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.
  396. AI: Michael will check if it's possible with current autobuilder.
  397.  
  398. MJ: we can still test it in batches, to save work for individual contributors
  399.  
  400. PE: Running self-tests in bitbake on autobuilder
  401. RP: We should just enable it on autobuilder, now it's executed manually but periodically, it's ready to be enabed now
  402. Michael: No concerns yet, does it need anything special
  403. PE: Do we want to split it into quick and full suite, because full suite takes long.
  404. RP: Yes that would be useful.
  405.  
  406. 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.
  407. MH: Depends on class of patches, some type of changes are easier to test, something we cannot ever expect community to submit tests for.
  408. PE: It should be mostly for new utilities for example.
  409. 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.
  410. PE: Or test cases for read-only-rootfs or tiny. PE is collecting the list of areas where we need the testing the most.
  411.  
  412. 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.
  413. PE: I can convert the list into list of bugzilla improvement tickets.
  414. 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.
  415.  
  416. Martin:
  417. 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.
  418. PB: someone is already using OE for building OS used in medial devices with all the ceritificactions.
  419. 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.
  420. MH: Is Smart for RPM still the best RPM packages? Currently looking for Smart maintainer, it could be someone from Yocto or OE.
  421. MJ: Opkg is also without Maintainer ATM after Paul stepped down.
  422. PB: Someone from NI already volunteered to take over the maintainership from Paul. NI planing to add new feature to support their goals.
  423. DD: Which version for RPM we're using.
  424. 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.
  425.  
  426. Conclusion we need to concentrate on package managers and package feeds.
  427.  
  428. 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.
  429. DD: Useful to build multiple MACHINEs with single bitbake call.
  430. HK: LGE is interested in faster multi-MACHINE builds.
  431. PE: Yes there is interest, 2 people asked about it on ELC.
  432. 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.
  433. SH: There are also heterogenous CPU architectures where people want to create it with single build.
  434.  
  435. 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.
  436. 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.
  437. 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.
  438. 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.
  439.  
  440. HK: Another issue we need to resolve is creating separate partitions for the same top-level image.
  441. RP: Have you tried to use wic.
  442.  
  443. = Development cycle II by PE =
  444. Scheme for milestones, releases.
  445. MH: Some people asked for 5 milestones, but for unknown reasons.
  446. 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.
  447. Can we apply something from Agile to resolve this issue?
  448. 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.
  449. 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.
  450. 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.
  451. 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
  452. PE: Do we need separate release process for OE, or do we continue to just follow Yocto release cycle.
  453. 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.
  454. Armin: Is there clearly defined code-freeze date? It's not show on schedule page.
  455. PE: Can we consider google calendar for the sharing the important release dates?
  456. PB: Yes, but only in addition to the e-mail.
  457.  
  458. Armin: Is cut-off date the same as code freeze
  459. PE: Discussion about the terminology for freeze date.
  460.  
  461. PB: Yocto project technical meeting, very terse agenda and minutes.
  462. MH: Usually relatively short
  463. PE: Useful mostly for people who prefer to attend the conference call instead of watching the mailing list.
  464. RP: It would be useful to have the summary from the meeting having in written form and send it to ML as well.
  465. Jefro: Someone else could be taking the notes during these meetings.
  466.  
  467. = Source mirror =
  468. 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.
  469. AI: PB or Michael will update DNS record when we're ready (a month)
  470.  
  471.  
  472. _______________________________________
  473. Tests
  474.  
  475. (Friday 2pm)
  476. rp      autobuilder provides a lot of these features regarding testing
  477. (discussion of using autobuilder) also automated testing of qemu images, ptests
  478. =>      michael look into using autobuilders for priority patches
  479.  
  480. pe      oe self test doesn’t run on autobuilder, takes too long
  481. how can we find more resources and/or cut tests
  482. stuff you wouldn’t get from a build
  483. rp      running bitbake in different contexts
  484.  
  485. 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
  486. 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)
  487. pe      did for devtool, extra work but very useful
  488.         building up a list where I think we need better tests
  489.         eg regression tests for rootfs
  490. fray    help with people going into existing systems
  491. pb      some people may need mentoring
  492. tim     like me - started looking for ptest for package I’m uploading
  493.  
  494. _______________________________________
  495. Development cycle
  496.  
  497. long-term package feeds/sdk
  498.  
  499. pe      does current dev cycle work
  500. fray    cross btw testing and dev cycle
  501.         users doing package based installs - no testing in the community
  502. pe      open enhancement to do that
  503. fray    need way to match what’s on dev system to sdk
  504.         just been discussed at this point\
  505.         someone creates an image, running in field, they upgrade packages on that
  506.         at some point have to resync sdk to that image
  507.         need to create sysroot & repo (binary package feeds?)
  508. pe      not all usage models are
  509. fray    used to be cgl type systems, now showing up in smaller systems
  510. pe      more worried about whether they have patching, sdk is easier to manage
  511. fray    oe may not solve this, but provisioning server needs to know what’s on a device
  512.         create custom sdk based on a provisioning script
  513.         traditional image model doesn’t match any more
  514. jom     could potentially do from manifest
  515. fray    or src on dev, but app may not have src
  516.         mostly networking devices
  517.         say process up to x standard - if safety critical, no chance on linux
  518. (discussion about certification issues)
  519.         becoming an expectation
  520.  
  521. using smart for rpm
  522.  
  523. fray    smart maintainer looking for a new maintainer
  524.         yp or look for something else like dnf
  525. herb    lg interested in support for multiple partitions
  526. fray    filesystem changeset field upgrades
  527.         big co’s coming up with various solutions
  528. (discussion about paul & alejandro)
  529. fray    if want basic package mgmt on small device, opkg is only answer
  530.         large device rpm is right answer
  531.         rpm more metadata, more validation
  532.  
  533. development cycle
  534.  
  535.  
  536. rp      bitbake implicit knowledge of MACHINE variable?
  537.  
  538. herb    abi checker tool, use for shared state determination
  539. herb    exclude machine from dependencies
  540. herb    opengl interface same, diff implementation shouldn’t pollute callers making them machine dependent
  541. fray    pain to rectify
  542. rp      check from input - have to have the output to run tool against in order to generate checksum
  543.         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
  544. rp      depends on problem trying to solve. currently shared state sensitive to change
  545.         could integrate with PR server
  546. herb    don’t use package feeds or PR server - when fix bug in low level component, rebuild system when don’t need to.
  547. fray    wish simple way to tag “my change causes this item to rebuild, but checksum returned is same until I change it”
  548. herb    fetch, unpack, patch, abi check
  549. rp      whitelist dependency in shared state code - if gl library, nothing has dep on gl lib itself
  550.         generate <<>> manually into package
  551. herb    maybe second run of bitbake
  552. fray    lots of nodding going on
  553.  
  554.  
  555. herb    prefer common way to handle packages into multiple partitions
  556. pe      could do in separate builds and combine at end
  557. rp/pe   look at wic tool
  558.  
  559. [break]
  560.  
  561. <revise agenda>
  562.  
  563. development cycle
  564.  
  565. pe      4 milestones
  566. suggestions for improvement
  567.         defined within YP but does OE have that? technically no, but practically yes
  568. fray    asked annually - 4 cycles working very well
  569.         some people would like one more - same cycle components but 5
  570. rp      supposed to have 5, planning supposed to happen in conjunction with the release
  571.         4 makes release more manageable
  572. fray    option is 1st one has no release
  573. rp      reality is that planning happens after release
  574. fray    milestone 0 could be planning
  575. (discussion of agile and waterfall)
  576. pe      occasionally hear cramming things into meet deadline
  577.         haven’t figured out a way to do that better, may not immediately be one
  578. fray    for an open source project I don’t think we could do better
  579. pe      release has some expected level of functionality, rush to complete at end
  580. rp      people sometimes do tend to hold things until the last minute
  581.         “there’ll be an RC2, right?”
  582. pe      usually functionality, not security or bugs
  583. rp      eg khem wanted a binutils update
  584.         really came to release point and just couldn’t, too much risk, would break build
  585.         if say develop tooling and it is late and we extend..
  586.         create list of things that will be accepted
  587. pb      remind people early when dates are coming up
  588. fray    release info easy to find, but people don’t look
  589. pe      yp or oe releases? oe just piggybacks yp release - different conversation
  590. pb      remind list, take this type of patches to x point, y type after etc
  591.         include boilerplate of what this means & put on list
  592. pe      we could point to the how-to-submit-patch page
  593. =>      pe update web page to talk about timing for submissions, describe process
  594. ak      is there a code freeze?
  595. pe      schedule page, lists candidates but not freeze dates (or other submission dates)
  596. fray    anything we can do to get rid of the excuse to be lazy
  597. pb      exactly
  598.  
  599. pb      yp technical meeting, terse minutes
  600.         would be great if minutes
  601. pe      in general that meeting is good for people not on the mailing list, RP does a readout
  602. =>      J ask sjolley to write RP’s readout into the minutes and send out
  603.  
  604.  
  605. oe source mirror
  606.  
  607. pe      upstream sources have gone missing for recipes in meta-oe and other layers curated by oe
  608.         meanwhile no one can build resources, other things break
  609.         great idea to collect sources
  610.         martin & tom have done that, so almost there
  611.         eg backup strategy
  612.         then everything martin builds on autobuilder won’t have that issue
  613.  
  614. adjourn until 10am pdt
  615.  
  616.  
  617. _______________________________________
  618. Community
  619.  
  620. Martin:
  621. Organizing bug scrub weekends, do we want to do it tomorrow. Deferred to tomorrow.
  622.  
  623.  
  624.  
  625. _______________________________________
  626. _______________________________________
  627. SAT 28 MAR 2015
  628. mark
  629. paul
  630. sona
  631. sean
  632. armin
  633. martin
  634. tim
  635. philip
  636. ken
  637. stephen
  638. jefro
  639. richard on phone
  640. changhyeok on hangout
  641. _______________________________________
  642. # packages (armin)
  643.  
  644. ak      should there be a limit on # packages
  645. pb      oe is sort of a dumping ground, want to be more organized
  646.         with new layer structure, no limit on packages, but good to keep in chunks
  647.         martin building world for some def of world, set of layers he considers to be worldlike
  648. fray    oecore has self imposed feature limit rather than numerical limit
  649. rp      poky/sato gives us something to test
  650. ?>      could move meta-sato into meta-poky
  651. fray    people do use sato for demos whether or not it is appropriate
  652. rp      would like to see <<>> instead of sato
  653. pb      eg someday x11 may go away, maybe not in my lifetime but I want oe to last longer than my lifetime
  654. =>      keep talking within tsc, scrub oe-core to see where the line is - “right-sizing” oe-core
  655. all     discussion cycled back - strong interest in revising and many alternative options discussed, but no owner yet
  656. _______________________________________
  657. documentation
  658.  
  659. =>      pb to mention to ab the need for more technical documentation
  660.  
  661. =>      jefro to schedule meeting about demos, test images, sato, etc
  662.         identify problem, role of sato, suitable alternatives, usage cases
  663. _______________________________________
  664. OE eV structure
  665. changing ev structure to streamline, possibly bringing to us and dissolving ev - sean working on it
  666. may be longer than GA
  667.  
  668. spi is working well
  669.  
  670. next oedam after elc in san diego in 1yr, possible oedem after elce
  671.  
  672. --
  673. patch queue maintenance
  674. ak      maint branches not spilt out
  675. pe      should be able to do stuff like that with patchwork
  676. =>      pe add for oe-core, automate - part of patchwork
  677.  
  678. _______________________________________
  679. Community
  680. Intro / crash course events
  681. sa      makerspace in goleta want yp crash course
  682.         would like to push more
  683. all     agreement
  684. =>      jefro to investigate materials & things for websites
  685.  
  686. Coordinated bug day sprints (openhatch, opw)
  687. jefro   bite size bugs needed
  688. rp      bugzilla - initial triage group meets weekly
  689. =>      remind stephen to add message onto bug list to let people know about the triage group
  690.         also bug page on wiki
  691. fray    https://wiki.yoctoproject.org/wiki/Bug_Triage
  692. pe      tried to set up a bug day w/tsc meeting, got very little participation
  693. ->      pb/pe set up bug day morning US/afternoon UK/EU, possibly separate event for asia
  694. ->      jefro investigate webinar format
  695.         training future maintainers
  696. sh      janitors list
  697. pe      misbranded
  698.  
  699. website, wiki
  700. sh      need consensus, jack mitchell needed
  701. pb      need to edit wiki
  702.         need to point to yp wiki
  703. pe      identified things, made oe classic read-only
  704.         now can remove things
  705. =>      jefro to organize board, admin issue
  706.  
  707. tsc meetings
  708.         communication piece gone away, valuable
  709. fray    let’s do one every 2 months and identify issues & communicate
  710.         remind people ahead of time
  711. pb      a lot of oe issues revolve around communication
  712.         would like to see the tsc is improve workflow theme & track through year
  713.         give a goal
  714.         this year we concluded good job on layer quality
  715.         next year improve workflow
  716.         tsc can be org that monitors progress through year
  717. rp      which things need commnicating
  718. fray    afraid a lot of comm is one way, lacking ability to listen
  719. out of 6 public meetings on #oe only had a few instances
  720. organized time to have a discussion on irc
  721. =>      jefro to organize meetings
  722. rp      worried that tsc will go do work themselves
  723. pb      not asking to fix, asking to report back
  724. rp      yocto project has processes and resources
  725. pb      ..though contribution is uneven
  726.  
  727. community metrics
  728. =>      jefro   talk to board
  729.  
  730. Other group/meetup activities
  731.  
  732. _______________________________________
  733. tshirts
RAW Paste Data
Top