[oe] TSC agenda items for the next meeting
stefan at datenfreihafen.org
Mon Feb 14 10:48:10 CET 2011
On Sun, 2011-02-13 at 11:50, Koen Kooi wrote:
> The new TSC is holding a meeting next week and we wanted to see if
> anyone wants to suggest items we put in the agenda for the meeting.
> If you have such items, please let us know by replying to this mail.
All items brought up here until now should be available in the final agenda now.
Please see the attchment for it.
Sometimes items may cover parts of the same topic. I did not work them into one
to keep the original text of the submitters. Not sure if this is a good way to
deal with this overlaps.
With 18 items this is a lot of topics and I'm not ure we can cover this all in
one meeting. We are aiming for weekly but shorter meetings to keep thins moving
and not pilling up to much.
-------------- 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:
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)
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.
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
- 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:
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)
18) What immediate infrastructure changes are needed to work on integrating
better with Yocto. [Proposed: Tom King]
More information about the Openembedded-devel