Please reply if you have any suggestions for new agenda items, thanks!
-------- Original Message -------- Subject: Preliminary agenda for 2011-02-29 TSC meeting Date: Fri, 25 Feb 2011 15:19:42 -0700 From: Tom Rini <[email protected]> Organization: Mentor Graphics Corporation To: [email protected] Hi all, I've taken the liberty to compile a preliminary agenda for the Feb 28 meeting (and yes, I edited Koen's message from last week as my starting point): Agenda 2011-02-28 meeting ------------------------- 01) Agree on meeting chair 02) Status report on oe-core 03) Status report on pull model, contrib repo and guidelines 04) Status report on board support layer guidelines 05) Status report on version retention policy and interaction with oe-core / meta-oe / $distro layers (This was: Re-inforcement of the "don't delete all old versions" policy, make sure this is in the wiki somewhere. [Proposed: Graeme]) 06) Status on Yocto / OpenEmbedded integration plan in oe-core 07) Start to think about the Policies section on wiki and whether it is relevant/correct now, and also what needs to change going forward to Yocto. [Proposed: Graeme] 08) Come to a set of minimal quality requirements for our recipes/packages (e.g. must fetch, minimal required headers etc). My proposal would be to use the yocto requirements as a starter 09) Splitting our metadata into multiple layers I can think of the following: - oe core layer (shared with yocto - oe layer (or oe extra's or whatever you want to call it; containing recipes that are generic, not in oe-core and considered to be of common use) - maybe oe-old or so layer (recipes that are not maintained any more) - layer per distro for distro specific stuff - layer per machine (or maybe soc family, I can imagine it makes sense to keep BB and BB-XM together; similarly for the kirkwoord variants) - vendor specific layers (if needed), e.g. ti (although maybe that stuff could also go into a machine layer) Rationale is that users can pull in only those layers that they need. [Proposed: Frans] 10) Consider a version based release mechanism yocto has a release model, intermediate versions are aiming to build but are considered to be less mature. If our core recipes follow this model, I can imagine it is a good strategy to follow in oe too. [Proposed: Frans] 11) Discuss future of our infrastructure (oestats, autobuilder,run-time testing) [Proposed: Yury] 12) What immediate infrastructure changes are needed to work on integrating better with Yocto. [Proposed: Tom King] _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
