TSC agenda items for the next meeting

TSC agenda items for the next meeting

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

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.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNV7d9MkyGM64RGpERAmPtAKCkcHyI3zTsPLl7EoEYBICnq+7VSgCfQ3/F
zaj+whHN6SofeY2+4Vyv17w=
=1+fn
-----END PGP SIGNATURE-----

Re: TSC agenda items for the next meeting

[Philip Balister]

On 02/13/2011 05:50 AM, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> 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.

I'd like to see 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.

Philip

Re: TSC agenda items for the next meeting

[Graeme Gregory]

On 13/02/2011 10:50, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> 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.
>
> regards,
>
> Koen
Re-inforcement of the "don't delete all old versions" policy, make sure 
this is in the wiki somewhere.

Rough Yocto integration plan.

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.

Graeme

Re: TSC agenda items for the next meeting

[Frans Meulenbroeks]

2011/2/13 Graeme Gregory <dp@xora.org.uk>:
> On 13/02/2011 10:50, Koen Kooi wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> 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.
>>
>> regards,
>>
>> Koen
>
> Re-inforcement of the "don't delete all old versions" policy, make sure this
> is in the wiki somewhere.

Not sure what you mean with re-inforcement and what policy you are referring to.
This topic has been discussed and decided by the TSC last may. See
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-May/020047.html
For now I haven't really heard reasons to deviate from it, and I think
there are more important things requiring the TSCs attention (like the
ones you mention below).
But I feel it is a good plan to make this policy more explicit in the
wiki, it is now somewhat hidden.

Then again if we work more towards releases the reasons for keeping
old versions might be less relevant.
and of course we could also decide to keep old versions in a separate layer.

What I QA wise would like to see is that all recipes (also old
versions) fetch and are building (for the archs/distros they are
intended for).
Non building recipes create a bad impression quite quickly.

Frans

>
> Rough Yocto integration plan.
>
> 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.
>
> Graeme
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: TSC agenda items for the next meeting

[Frans Meulenbroeks]

2011/2/13 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> 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.
>

- 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

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

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

Frans

Re: TSC agenda items for the next meeting

[Yury Bushmelev]

2011/2/13 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> 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.

- may be discuss future of our infrastructure (oestats, autobuilder,
run-time testing)

-- 
Yury Bushmelev

Re: TSC agenda items for the next meeting

[Stefan Schmidt]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

Hello.

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.

regards
Stefan Schmidt

[-- Attachment #2: TSC-2011-02-14-Agenda.txt --]
[-- Type: text/plain, Size: 3465 bytes --]

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]

Re: TSC agenda items for the next meeting

[Graeme Gregory]

On 14/02/2011 18:48, Stefan Schmidt wrote:
> Hello.
>
> 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.
>
> regards
> Stefan Schmidt
>
Thanks Stefan, that is a good list to keep you guys busy :-)

Graeme

Re: TSC agenda items for the next meeting

[Frans Meulenbroeks]

2011/2/14 Stefan Schmidt <stefan@datenfreihafen.org>:
> Hello.
>
> 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.
>
> regards
> Stefan Schmidt

Stefan, thanks for making and sharing the list.
If you feel crediting things is important you can add [Proposed:
Frans] to #14. Personally I don't care, but I noticed it was done for
all other items.
Guess with such a list you need to pull an all-nighter.

Good luck in discussing this and coming to wise decision

Frans.

PS: if I may coin an additional item:
#0:a quick prioritization of the points.

Re: TSC agenda items for the next meeting

[Stefan Schmidt]

Hello.

On Mon, 2011-02-14 at 14:33, Frans Meulenbroeks wrote:
> 2011/2/14 Stefan Schmidt <stefan@datenfreihafen.org>:
> >
> > 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.
> >
> Stefan, thanks for making and sharing the list.
> If you feel crediting things is important you can add [Proposed:
> Frans] to #14. Personally I don't care, but I noticed it was done for
> all other items.

Yeah, just an oversight. Sorry for that.

> Guess with such a list you need to pull an all-nighter.
> 
> PS: if I may coin an additional item:
> #0:a quick prioritization of the points.

And I feel that is what we indeed need to do. I don't think we are able to
discuss them all at the first meeting. But having weekly meetings should help us
to get the list down. (And hope it does not get filled up at the same pace. ;))

regards
Stefan Schmidt