Preliminary agenda for 2011-02-29 TSC meeting

[Tom Rini <tom_rini@mentor.com>]

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 <tom_rini@mentor.com>
Organization: Mentor Graphics Corporation
To: tsc@lists.openembedded.org

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]