Preliminary agenda for 2011-02-29 TSC meeting

[Koen Kooi]

Op 25 feb 2011, om 23:19 heeft Tom Rini het volgende geschreven:

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


13) DISTRO_FEATURES and libc stuff (basically the xattr fallout)