Preliminary agenda for 2011-02-21 TSC meeting

[Koen Kooi]

Hi,

I've taken the liberty to compile a preliminary agenda for tomorrows meeting. Attentive readers will see that it's the same as last weeks, but with 01) replaced.

regards,

Koen

Agenda 2011-02-21 meeting
-------------------------

01) Agree on meeting chair

02) Setup oe-core repo and import yocto with history but without bitbake.
    Decide who will take this action item. [Proposed: Koen, Khem]

03) Discuss how we get OE metadata into the oe-core repo without loosing to
    much histroy and credits of the original authors. [Proposed: Stefan]

04) Access model for OE core and other layers [Proposed: Koen]

05) Guidelines for layers, e.g. encourage distro layers or not [Proposed: Koen]

06) Timeline for changes, e.g. OE releases, yocto milestones, etc [Proposed:
    Koen]

07) Definition of OE core [Proposed: Koen]

08) OE goals and guarantees for OE-core, which distros and machines to we
    recommend and 'test'? [Proposed: Koen]

09) Quickly discuss if we are fine with having the IRC meeting (read-only) open
    for interested community member. (Interest expressed from several ones)
    [Proposed: Stefan]

10) Definitive guidelines for creating board support packages. This should address:
    1) Where to define toolchains and versions.
    2) How to create kernel bb files. (Per board, or per kernel version)
    3) Same for u-boot, how to pin u-boot versions for BSP's.

    Basically, we should identify all the BSP's issues that create
    discussions on the list and work out a best practices document so we can
    have more consistency.

    A similar set of guidelines defining what a a distro's responsibility
    would also be good. [Proposed: Philip Balister]

11) Re-inforcement of the "don't delete all old versions" policy, make sure
    this is in the wiki somewhere. [Proposed: Graeme]

12) Rough Yocto integration plan. [Proposed: Graeme]

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

14) 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

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

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

17) Discuss future of our infrastructure (oestats, autobuilder,run-time testing)
    [Proposed: Yury]

18) What immediate infrastructure changes are needed to work on integrating
    better with Yocto. [Proposed: Tom King]