2011-02-14 Agenda

[Stefan Schmidt]

Hello.

Please find the agenda attached. I put together all the items we listed here and
the requests from other people on the ml.

Format could be improved, but I'm undecided how we could best avoid overlaping
items without loosing the original proposal. Anyway, its a start.

We agreed on IRC as meeting place IIRC. Who can take care of preapring a channel
for us? My IRC-foo is to weak for this. :)

regards
Stefan Schmidt
-------------- next part --------------
Agenda 2011-02-14 meeting
-------------------------

01) Agree on meeting date, time and meeting lead. [Proposed: Stefan]

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]