openembedded-core git repository

openembedded-core git repository

[Graeme Gregory]

Hi, this email is sent as an ordinary member of OE.

It seems to be on a technical level we are agreed that we should split
parts of OE out into the so called openembedded-core which will have a
stricter commit access and higher QA requirements on changes.

I therefore think it is time to actually create the repository and let
the people who are interested in merging the good stuff from poky with
the good stuff from openembedded to create our "core". I don't think
there is any need to wait on the political part of the Yocto/OE
collaboration as its something we have agreed in principal to do anyway.

I would request then that the TSC drive this forward with the server
admins and create this repo so work can happen.

Graeme

Re: openembedded-core git repository

[Eric Bénard]

Hi,

On 19/01/2011 15:48, Graeme Gregory wrote:
> It seems to be on a technical level we are agreed that we should split
> parts of OE out into the so called openembedded-core which will have a
> stricter commit access and higher QA requirements on changes.
>
(this question may be stupid as I haven't yet read the other thread concerning 
Yocto/OE).
What is openembedded-core vs 
http://cgit.openembedded.net/cgit.cgi/meta-openembedded/ ?

Eric

Re: openembedded-core git repository

[Graeme Gregory]

On 19/01/2011 15:32, Eric Bénard wrote:
> Hi,
>
> On 19/01/2011 15:48, Graeme Gregory wrote:
>> It seems to be on a technical level we are agreed that we should split
>> parts of OE out into the so called openembedded-core which will have a
>> stricter commit access and higher QA requirements on changes.
>>
> (this question may be stupid as I haven't yet read the other thread
> concerning Yocto/OE).
> What is openembedded-core vs
> http://cgit.openembedded.net/cgit.cgi/meta-openembedded/ ?
>
It is the distilling of toolchains/classes/basic tools from OE/poky to a
small tightly controlled repository with tighter access controls with
the aim that making a minimal image out of this repo should always work
(tm). Basically the minimal subset of OE that is still useful.

meta-openembedded then builds on this to give the rest of OE that we see
now.

Graeme

Re: openembedded-core git repository

[Frans Meulenbroeks]

2011/1/19 Graeme Gregory <dp@xora.org.uk>:
> Hi, this email is sent as an ordinary member of OE.
>
> It seems to be on a technical level we are agreed that we should split
> parts of OE out into the so called openembedded-core which will have a
> stricter commit access and higher QA requirements on changes.
>
> I therefore think it is time to actually create the repository and let
> the people who are interested in merging the good stuff from poky with
> the good stuff from openembedded to create our "core". I don't think
> there is any need to wait on the political part of the Yocto/OE
> collaboration as its something we have agreed in principal to do anyway.
>
> I would request then that the TSC drive this forward with the server
> admins and create this repo so work can happen.
>
> Graeme

Graeme,

Seems  a fine plan to me.
Do we already have an idea what would be the starting base?
And do we already have an idea on the QA requirements we want to impose on this?
Lastly we might try to define some common understanding what is core
and what not.

I did some experiments with poky and found that some of the recipes I
needed were missing; some of them might perhaps become part of core
(e.g. i2ctools, squashfstools, libftdi, fastcgi), whereas others are
quite unlikely to end up in core (e.g. urjtag). For the latter we must
find another home (e.g. meta-openembedded), where hopefully we can
also raise the QA bar somewhat.

I'll happily contribute to raise the quality bar. However, if the goal
is shuffling recipes without significant QA improvement or if QA
improvement is optional, I'll probably pass.

Frans.

Re: openembedded-core git repository

[Graeme Gregory]

On 19/01/2011 15:33, Frans Meulenbroeks wrote:
> 2011/1/19 Graeme Gregory <dp@xora.org.uk>:
>> Hi, this email is sent as an ordinary member of OE.
>>
>> It seems to be on a technical level we are agreed that we should split
>> parts of OE out into the so called openembedded-core which will have a
>> stricter commit access and higher QA requirements on changes.
>>
>> I therefore think it is time to actually create the repository and let
>> the people who are interested in merging the good stuff from poky with
>> the good stuff from openembedded to create our "core". I don't think
>> there is any need to wait on the political part of the Yocto/OE
>> collaboration as its something we have agreed in principal to do anyway.
>>
>> I would request then that the TSC drive this forward with the server
>> admins and create this repo so work can happen.
>>
>> Graeme
> Graeme,
>
> Seems  a fine plan to me.
> Do we already have an idea what would be the starting base?
> And do we already have an idea on the QA requirements we want to impose on this?
> Lastly we might try to define some common understanding what is core
> and what not.
>
> I did some experiments with poky and found that some of the recipes I
> needed were missing; some of them might perhaps become part of core
> (e.g. i2ctools, squashfstools, libftdi, fastcgi), whereas others are
> quite unlikely to end up in core (e.g. urjtag). For the latter we must
> find another home (e.g. meta-openembedded), where hopefully we can
> also raise the QA bar somewhat.
>
> I'll happily contribute to raise the quality bar. However, if the goal
> is shuffling recipes without significant QA improvement or if QA
> improvement is optional, I'll probably pass.
>

Well I would hope that openembedded-core has a pull model similar to
poky/yocto but that is I think ultimately upto TSC members (with
consultation with membership). Hopefully they shall give their opinions
on the issue soon.

I would say the obvious starting point is poky, then merge OE
improvements into that. I think this would be less work than stripping
down OE to core level.

I think all the tools you have mentioned are bad examples of stuff to go
into core except possibly squashfs. Core should be purely enough to get
a busybox minimal image build in ext2/3/jffs/ubi given a machine.conf.
Basically enough to do board bringup and no more (with package
management capabilities). If core was recipes people "needed" it wouldnt
really be core fastcgi is pretty specialised bit of software.

Core should probably have a build bot which crunches a standard set of
tests on each commit so unlike OE currently people don't wake up to bad
day of debugging OE.

Graeme

Re: openembedded-core git repository

[Khem Raj]

On Wed, Jan 19, 2011 at 7:59 AM, Graeme Gregory <dp@xora.org.uk> wrote:
> On 19/01/2011 15:33, Frans Meulenbroeks wrote:
>> 2011/1/19 Graeme Gregory <dp@xora.org.uk>:
>>> Hi, this email is sent as an ordinary member of OE.
>>>
>>> It seems to be on a technical level we are agreed that we should split
>>> parts of OE out into the so called openembedded-core which will have a
>>> stricter commit access and higher QA requirements on changes.
>>>
>>> I therefore think it is time to actually create the repository and let
>>> the people who are interested in merging the good stuff from poky with
>>> the good stuff from openembedded to create our "core". I don't think
>>> there is any need to wait on the political part of the Yocto/OE
>>> collaboration as its something we have agreed in principal to do anyway.
>>>
>>> I would request then that the TSC drive this forward with the server
>>> admins and create this repo so work can happen.
>>>
>>> Graeme
>> Graeme,
>>
>> Seems  a fine plan to me.
>> Do we already have an idea what would be the starting base?
>> And do we already have an idea on the QA requirements we want to impose on this?
>> Lastly we might try to define some common understanding what is core
>> and what not.
>>
>> I did some experiments with poky and found that some of the recipes I
>> needed were missing; some of them might perhaps become part of core
>> (e.g. i2ctools, squashfstools, libftdi, fastcgi), whereas others are
>> quite unlikely to end up in core (e.g. urjtag). For the latter we must
>> find another home (e.g. meta-openembedded), where hopefully we can
>> also raise the QA bar somewhat.
>>
>> I'll happily contribute to raise the quality bar. However, if the goal
>> is shuffling recipes without significant QA improvement or if QA
>> improvement is optional, I'll probably pass.
>>
>
> Well I would hope that openembedded-core has a pull model similar to
> poky/yocto but that is I think ultimately upto TSC members (with
> consultation with membership). Hopefully they shall give their opinions
> on the issue soon.
>
> I would say the obvious starting point is poky, then merge OE
> improvements into that. I think this would be less work than stripping
> down OE to core level.

Poky is a moving target too. So it will be a bit hard to follow do we plan to
sync oe-core with poky or will yocto start working on oe-core right away

>
> I think all the tools you have mentioned are bad examples of stuff to go
> into core except possibly squashfs. Core should be purely enough to get
> a busybox minimal image build in ext2/3/jffs/ubi given a machine.conf.
> Basically enough to do board bringup and no more (with package
> management capabilities). If core was recipes people "needed" it wouldnt
> really be core fastcgi is pretty specialised bit of software.
>
> Core should probably have a build bot which crunches a standard set of
> tests on each commit so unlike OE currently people don't wake up to bad
> day of debugging OE.
>
> Graeme
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: openembedded-core git repository

[Frans Meulenbroeks]

2011/1/19 Graeme Gregory <dp@xora.org.uk>:
> On 19/01/2011 15:33, Frans Meulenbroeks wrote:
>> 2011/1/19 Graeme Gregory <dp@xora.org.uk>:
>>> Hi, this email is sent as an ordinary member of OE.
>>>
>>> It seems to be on a technical level we are agreed that we should split
>>> parts of OE out into the so called openembedded-core which will have a
>>> stricter commit access and higher QA requirements on changes.
>>>
>>> I therefore think it is time to actually create the repository and let
>>> the people who are interested in merging the good stuff from poky with
>>> the good stuff from openembedded to create our "core". I don't think
>>> there is any need to wait on the political part of the Yocto/OE
>>> collaboration as its something we have agreed in principal to do anyway.
>>>
>>> I would request then that the TSC drive this forward with the server
>>> admins and create this repo so work can happen.
>>>
>>> Graeme
>> Graeme,
>>
>> Seems  a fine plan to me.
>> Do we already have an idea what would be the starting base?
>> And do we already have an idea on the QA requirements we want to impose on this?
>> Lastly we might try to define some common understanding what is core
>> and what not.
>>
>> I did some experiments with poky and found that some of the recipes I
>> needed were missing; some of them might perhaps become part of core
>> (e.g. i2ctools, squashfstools, libftdi, fastcgi), whereas others are
>> quite unlikely to end up in core (e.g. urjtag). For the latter we must
>> find another home (e.g. meta-openembedded), where hopefully we can
>> also raise the QA bar somewhat.
>>
>> I'll happily contribute to raise the quality bar. However, if the goal
>> is shuffling recipes without significant QA improvement or if QA
>> improvement is optional, I'll probably pass.
>>
>
> Well I would hope that openembedded-core has a pull model similar to
> poky/yocto but that is I think ultimately upto TSC members (with
> consultation with membership). Hopefully they shall give their opinions
> on the issue soon.

I would also encourage and support a pull model, driven by one or a
few fairly neutral developers.
>
> I would say the obvious starting point is poky, then merge OE
> improvements into that. I think this would be less work than stripping
> down OE to core level.
>
> I think all the tools you have mentioned are bad examples of stuff to go
> into core except possibly squashfs. Core should be purely enough to get
> a busybox minimal image build in ext2/3/jffs/ubi given a machine.conf.
> Basically enough to do board bringup and no more (with package
> management capabilities). If core was recipes people "needed" it wouldnt
> really be core fastcgi is pretty specialised bit of software.

I'm not really sure what would go into core, but I kinda figured it
would probably be something like poky/meta
http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta

The examples I gave are maybe not desirable in a minimal setting.
Then again I feel core should probably be a little bit more than board
bringup + busybox. I would hope that recipes like perl and python
become part of core.

Then again if oe core is similar to poky/meta the things I mentioned
might fit in better than say libid3tag.
If oe core is what is now in poky/recipes-core then I fully agree that
the things I mention do not belong there (but probably glib-2.0 does
not belong in a minimal layer either).

http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta/recipes-core

But I had the impression that most of the poky recipes should go into
oe-core (or I misunderstood that part of Richard's email).
It does not seem too wise to have two repo's with e.g. pango, zeroconf
and matchbox.
>
> Core should probably have a build bot which crunches a standard set of
> tests on each commit so unlike OE currently people don't wake up to bad
> day of debugging OE.

I'm not sure if that is needed (at least not on for every commit).
If we are aiming for a pull model, the maintainer(s) are the only ones
that can push and I would expect them to build things (maybe using a
buildbot to cover different architectures) before pushing.

Frans

Re: openembedded-core git repository

[Graham Gower]

On 20 January 2011 05:22, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2011/1/19 Graeme Gregory <dp@xora.org.uk>:
>> Core should probably have a build bot which crunches a standard set of
>> tests on each commit so unlike OE currently people don't wake up to bad
>> day of debugging OE.
>
> I'm not sure if that is needed (at least not on for every commit).

Doing this for every commit may be good from the point of view of
keeping git-bisect useful.

-Graham

Re: openembedded-core git repository

[Frans Meulenbroeks]

2011/1/19 Graham Gower <graham.gower@gmail.com>:
> On 20 January 2011 05:22, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2011/1/19 Graeme Gregory <dp@xora.org.uk>:
>>> Core should probably have a build bot which crunches a standard set of
>>> tests on each commit so unlike OE currently people don't wake up to bad
>>> day of debugging OE.
>>
>> I'm not sure if that is needed (at least not on for every commit).
>
> Doing this for every commit may be good from the point of view of
> keeping git-bisect useful.

Good point. Didn't think of that!

Frans

Re: openembedded-core git repository

[Chris Larson]

On Thu, Jan 20, 2011 at 3:21 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2011/1/19 Graham Gower <graham.gower@gmail.com>:
>> On 20 January 2011 05:22, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com> wrote:
>>> 2011/1/19 Graeme Gregory <dp@xora.org.uk>:
>>>> Core should probably have a build bot which crunches a standard set of
>>>> tests on each commit so unlike OE currently people don't wake up to bad
>>>> day of debugging OE.
>>>
>>> I'm not sure if that is needed (at least not on for every commit).
>>
>> Doing this for every commit may be good from the point of view of
>> keeping git-bisect useful.
>
> Good point. Didn't think of that!

Take a look at git test-sequence.  It's *awesome* for ensuring
bisectability on changes before pushing.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: openembedded-core git repository

[Philip Balister]

On 01/19/2011 06:48 AM, Graeme Gregory wrote:
> Hi, this email is sent as an ordinary member of OE.
>
> It seems to be on a technical level we are agreed that we should split
> parts of OE out into the so called openembedded-core which will have a
> stricter commit access and higher QA requirements on changes.
>
> I therefore think it is time to actually create the repository and let
> the people who are interested in merging the good stuff from poky with
> the good stuff from openembedded to create our "core". I don't think
> there is any need to wait on the political part of the Yocto/OE
> collaboration as its something we have agreed in principal to do anyway.
>
> I would request then that the TSC drive this forward with the server
> admins and create this repo so work can happen.

We should also have some discussion on the process for getting stuff 
into -core and how devs get commit access. Basically, we need to think 
about how to integrate the OpenEmbedded people and the Yocto people.

Philip

Re: openembedded-core git repository

[Bernhard Guillon]

On 19.01.2011 20:43, Philip Balister wrote:
>
> We should also have some discussion on the process for getting stuff 
> into -core and how devs get commit access. Basically, we need to think 
> about how to integrate the OpenEmbedded people and the Yocto people.
>

First of all I am not against a pull based model. But in my opinion we 
should start a poll to decide the commit model for core. Afterwards if 
we agree that a pull based model is well suited for core we should do 
another poll to decide who will be the "king". We should also have some 
rules for how to change the king. Also the king should only rule for a 
limited time. After this time period there should be another poll. In my 
opinion this will help people to accept what the king decides. We also 
need rules for rejects of pull requests. They should have a technical 
reason. The king should also be responsible for security issues. If I 
got it right yocto has full-time developers so one should do full-time 
security stuff for core.

I know we have the TSC but a poll does not hurt. I belief that most 
developers will agree with the pull based model.

best regards
Bernhard

Re: openembedded-core git repository

[Philip Balister]

On 01/19/2011 06:48 AM, Graeme Gregory wrote:
> Hi, this email is sent as an ordinary member of OE.
>
> It seems to be on a technical level we are agreed that we should split
> parts of OE out into the so called openembedded-core which will have a
> stricter commit access and higher QA requirements on changes.
>
> I therefore think it is time to actually create the repository and let
> the people who are interested in merging the good stuff from poky with
> the good stuff from openembedded to create our "core". I don't think
> there is any need to wait on the political part of the Yocto/OE
> collaboration as its something we have agreed in principal to do anyway.
>
> I would request then that the TSC drive this forward with the server
> admins and create this repo so work can happen.


Has anything happened on this email? Has the TSC had a meeting to 
discuss? I know it has only been a week, but people are starting to do 
work based on these ideas and need some support from the TSC.

Philip

Re: openembedded-core git repository

[Khem Raj]

On Mon, Jan 24, 2011 at 8:39 AM, Philip Balister <philip@balister.org> wrote:
> On 01/19/2011 06:48 AM, Graeme Gregory wrote:
>>
>> Hi, this email is sent as an ordinary member of OE.
>>
>> It seems to be on a technical level we are agreed that we should split
>> parts of OE out into the so called openembedded-core which will have a
>> stricter commit access and higher QA requirements on changes.
>>
>> I therefore think it is time to actually create the repository and let
>> the people who are interested in merging the good stuff from poky with
>> the good stuff from openembedded to create our "core". I don't think
>> there is any need to wait on the political part of the Yocto/OE
>> collaboration as its something we have agreed in principal to do anyway.
>>
>> I would request then that the TSC drive this forward with the server
>> admins and create this repo so work can happen.
>
>
> Has anything happened on this email? Has the TSC had a meeting to discuss? I
> know it has only been a week, but people are starting to do work based on
> these ideas and need some support from the TSC.
>

Yes I think we should start action on it soon. I would suggest to set
up the repository
as first step. As someone raised question about pull model it could be
TSC who decided
to appoint one gatekeeper based upon availability interest and
capability and it could be
rotated.secondly sane Starting point would be importing yocto and then
apply the OE improvements
on top thirdly breakdown oe into oe-meta repo to glue with the oe-core

> Philip
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: openembedded-core git repository

[Koen Kooi]

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

On 24-01-11 18:48, Khem Raj wrote:
> On Mon, Jan 24, 2011 at 8:39 AM, Philip Balister <philip@balister.org> wrote:
>> On 01/19/2011 06:48 AM, Graeme Gregory wrote:
>>>
>>> Hi, this email is sent as an ordinary member of OE.
>>>
>>> It seems to be on a technical level we are agreed that we should split
>>> parts of OE out into the so called openembedded-core which will have a
>>> stricter commit access and higher QA requirements on changes.
>>>
>>> I therefore think it is time to actually create the repository and let
>>> the people who are interested in merging the good stuff from poky with
>>> the good stuff from openembedded to create our "core". I don't think
>>> there is any need to wait on the political part of the Yocto/OE
>>> collaboration as its something we have agreed in principal to do anyway.
>>>
>>> I would request then that the TSC drive this forward with the server
>>> admins and create this repo so work can happen.
>>
>>
>> Has anything happened on this email? Has the TSC had a meeting to discuss? I
>> know it has only been a week, but people are starting to do work based on
>> these ideas and need some support from the TSC.
>>
> 
> Yes I think we should start action on it soon. I would suggest to set
> up the repository
> as first step. As someone raised question about pull model it could be
> TSC who decided
> to appoint one gatekeeper based upon availability interest and
> capability and it could be
> rotated.secondly sane Starting point would be importing yocto and then
> apply the OE improvements
> on top thirdly breakdown oe into oe-meta repo to glue with the oe-core

Ignoring the timeline a bit, since ideally we would do this around a
yocto milestone to get them to use this straight after their freeze.

The technical roadmap/todo:

* setup openembedded-core repo on oe.org
* setup oe-core ml on oe.org
* add oe-core ml to patchwork
* import yocto-core in oe-core
* start an integration branch
 o remove bitbake
 o cleanup namespace (s/yocto/OE/, s/poky/OE/)
 o split out superfluous layers (e.g. ememlow)
* start merging in OE things
 o e.g. OE gcc 4.5, toolchains for avr32, bfin, etc
* switch meta-oe to build on top of oe-core, fix issues

When that is done meta-oe can start to expand.

The non-technical roadmap/todo:

* Assign 2 gatekeepers to oe-core, one from yocto, one from OE
* sketch out decision tree (RP -> gatekeepers -> maintainers)
* work out model for meta-oe
* appoint OE member to yocto SC
* work out how to marry yocto goals (4 archs, one toolchain) to OE goals
(zillion archs, as much toolchains as we can manage)
* Work out OE roadmap and align with yocto

The above tries to restrict itself to dealing with the new oe-core, not
with how OE is going to split into layers (meta-oe, meta-graveyard, etc).
It also ignores the maintainer aspects since we will be dealing with
yocto metadata at the start. After oe-core reaches a ready enough state
we can start looking at assigning maintainers, but for the time being
let's get things done first.

So, let's start fleshing out the above roadmaps and implement them!

regards,

Koen

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

iD8DBQFNPq6WMkyGM64RGpERAmViAKCYKgJPEcLTCL+G1uugO6wQwEkfAACgrq8C
zanbxmzVZb4tgNbdwTV/fS0=
=tMf8
-----END PGP SIGNATURE-----

Re: openembedded-core git repository

[Frans Meulenbroeks]

2011/1/25 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 24-01-11 18:48, Khem Raj wrote:
>> On Mon, Jan 24, 2011 at 8:39 AM, Philip Balister <philip@balister.org> wrote:
>>> On 01/19/2011 06:48 AM, Graeme Gregory wrote:
>>>>
>>>> Hi, this email is sent as an ordinary member of OE.
>>>>
>>>> It seems to be on a technical level we are agreed that we should split
>>>> parts of OE out into the so called openembedded-core which will have a
>>>> stricter commit access and higher QA requirements on changes.
>>>>
>>>> I therefore think it is time to actually create the repository and let
>>>> the people who are interested in merging the good stuff from poky with
>>>> the good stuff from openembedded to create our "core". I don't think
>>>> there is any need to wait on the political part of the Yocto/OE
>>>> collaboration as its something we have agreed in principal to do anyway.
>>>>
>>>> I would request then that the TSC drive this forward with the server
>>>> admins and create this repo so work can happen.
>>>
>>>
>>> Has anything happened on this email? Has the TSC had a meeting to discuss? I
>>> know it has only been a week, but people are starting to do work based on
>>> these ideas and need some support from the TSC.
>>>
>>
>> Yes I think we should start action on it soon. I would suggest to set
>> up the repository
>> as first step. As someone raised question about pull model it could be
>> TSC who decided
>> to appoint one gatekeeper based upon availability interest and
>> capability and it could be
>> rotated.secondly sane Starting point would be importing yocto and then
>> apply the OE improvements
>> on top thirdly breakdown oe into oe-meta repo to glue with the oe-core
>
> Ignoring the timeline a bit, since ideally we would do this around a
> yocto milestone to get them to use this straight after their freeze.
>
> The technical roadmap/todo:
>
> * setup openembedded-core repo on oe.org
> * setup oe-core ml on oe.org
> * add oe-core ml to patchwork
> * import yocto-core in oe-core

Is this yocto core: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/
Or do you mean this:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core

> * start an integration branch
>  o remove bitbake
Not sure what you mean with that. Which BB do you propose to use?

>  o cleanup namespace (s/yocto/OE/, s/poky/OE/)
>  o split out superfluous layers (e.g. ememlow)
> * start merging in OE things
>  o e.g. OE gcc 4.5, toolchains for avr32, bfin, etc
> * switch meta-oe to build on top of oe-core, fix issues

Isn't some class merging needed?

BTW, good list.
>
> When that is done meta-oe can start to expand.
>
> The non-technical roadmap/todo:
>
> * Assign 2 gatekeepers to oe-core, one from yocto, one from OE
> * sketch out decision tree (RP -> gatekeepers -> maintainers)
> * work out model for meta-oe
> * appoint OE member to yocto SC
> * work out how to marry yocto goals (4 archs, one toolchain) to OE goals
> (zillion archs, as much toolchains as we can manage)
> * Work out OE roadmap and align with yocto

I assume maintenance will use a pull model. Correct?
>
> The above tries to restrict itself to dealing with the new oe-core, not
> with how OE is going to split into layers (meta-oe, meta-graveyard, etc).
> It also ignores the maintainer aspects since we will be dealing with
> yocto metadata at the start. After oe-core reaches a ready enough state
> we can start looking at assigning maintainers, but for the time being
> let's get things done first.
>
> So, let's start fleshing out the above roadmaps and implement them!
>
> regards,
>
> Koen
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFNPq6WMkyGM64RGpERAmViAKCYKgJPEcLTCL+G1uugO6wQwEkfAACgrq8C
> zanbxmzVZb4tgNbdwTV/fS0=
> =tMf8
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: openembedded-core git repository

[Tom Rini]

On 01/25/2011 07:49 AM, Frans Meulenbroeks wrote:
> 2011/1/25 Koen Kooi<k.kooi@student.utwente.nl>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 24-01-11 18:48, Khem Raj wrote:
>>> On Mon, Jan 24, 2011 at 8:39 AM, Philip Balister<philip@balister.org>  wrote:
>>>> On 01/19/2011 06:48 AM, Graeme Gregory wrote:
>>>>>
>>>>> Hi, this email is sent as an ordinary member of OE.
>>>>>
>>>>> It seems to be on a technical level we are agreed that we should split
>>>>> parts of OE out into the so called openembedded-core which will have a
>>>>> stricter commit access and higher QA requirements on changes.
>>>>>
>>>>> I therefore think it is time to actually create the repository and let
>>>>> the people who are interested in merging the good stuff from poky with
>>>>> the good stuff from openembedded to create our "core". I don't think
>>>>> there is any need to wait on the political part of the Yocto/OE
>>>>> collaboration as its something we have agreed in principal to do anyway.
>>>>>
>>>>> I would request then that the TSC drive this forward with the server
>>>>> admins and create this repo so work can happen.
>>>>
>>>>
>>>> Has anything happened on this email? Has the TSC had a meeting to discuss? I
>>>> know it has only been a week, but people are starting to do work based on
>>>> these ideas and need some support from the TSC.
>>>>
>>>
>>> Yes I think we should start action on it soon. I would suggest to set
>>> up the repository
>>> as first step. As someone raised question about pull model it could be
>>> TSC who decided
>>> to appoint one gatekeeper based upon availability interest and
>>> capability and it could be
>>> rotated.secondly sane Starting point would be importing yocto and then
>>> apply the OE improvements
>>> on top thirdly breakdown oe into oe-meta repo to glue with the oe-core
>>
>> Ignoring the timeline a bit, since ideally we would do this around a
>> yocto milestone to get them to use this straight after their freeze.
>>
>> The technical roadmap/todo:
>>
>> * setup openembedded-core repo on oe.org
>> * setup oe-core ml on oe.org
>> * add oe-core ml to patchwork
>> * import yocto-core in oe-core
>
> Is this yocto core: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/
> Or do you mean this:
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core
>
>> * start an integration branch
>>   o remove bitbake
> Not sure what you mean with that. Which BB do you propose to use?

Chris Larson has been doing a lot of work (and Richard has been 
confirming, testing, etc, etc) to try and keep poky's bitbake changes in 
sync with master when at all possible (the delta has gotten very very 
small, iirc).

-- 
Tom Rini
Mentor Graphics Corporation

Re: openembedded-core git repository

[Chris Larson]

On Tue, Jan 25, 2011 at 10:53 AM, Tom Rini <tom_rini@mentor.com> wrote:
>>> * start an integration branch
>>>  o remove bitbake
>>
>> Not sure what you mean with that. Which BB do you propose to use?
>
> Chris Larson has been doing a lot of work (and Richard has been confirming,
> testing, etc, etc) to try and keep poky's bitbake changes in sync with
> master when at all possible (the delta has gotten very very small, iirc).

I would personally like to see yocto use upstream bitbake with git
submodules or similar, rather than maintaining its own bitbake
directory.  I'd also like to see the bitbake sync completed, but it
seems like it's a low priority for Richard at this time.  As you say,
though, the delta is fairly small, considering.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: openembedded-core git repository

[Richard Purdie]

On Tue, 2011-01-25 at 11:19 -0700, Chris Larson wrote:
> On Tue, Jan 25, 2011 at 10:53 AM, Tom Rini <tom_rini@mentor.com> wrote:
> >>> * start an integration branch
> >>>  o remove bitbake
> >>
> >> Not sure what you mean with that. Which BB do you propose to use?
> >
> > Chris Larson has been doing a lot of work (and Richard has been confirming,
> > testing, etc, etc) to try and keep poky's bitbake changes in sync with
> > master when at all possible (the delta has gotten very very small, iirc).
> 
> I would personally like to see yocto use upstream bitbake with git
> submodules or similar, rather than maintaining its own bitbake
> directory.  I'd also like to see the bitbake sync completed, but it
> seems like it's a low priority for Richard at this time.  As you say,
> though, the delta is fairly small, considering.

I don't consider it a low priority and fully agree it needs to be fixed,
there needs to be no delta. I doubt I'd go for submodules but making it
match 1:1 commits with upstream bitbake is the intent and to script it.

The Yocto development window is closing which has influenced my priority
list. I'm also very conscious that we want to sort out a number of the
fetcher problems and we're not there with that yet so I'm having to make
some difficult choices over what I work on and in what order.

On the plus side two features have just landed in Poky/Yocto:

* Improved toolchain bootstrap process (no file overwriting)
* A sysroot per machine

which are both things we've wanted in OE for years and help in various
ways (e.g. making sstate/pstage easier and reliable).

We also merged libtool 2.4 and found a security hole that OE hadn't
spotted. Those problems have been reported to libtool upstream.

Cheers,

Richard

Re: openembedded-core git repository

[Richard Purdie]

Firstly, just for reference, the TSC is having some discussions between
its members and I'd expect some kind of result from that to be made
public soon.

I think its fine to talk about this and form a plan but I would like to
see some representation from the board and TSC over this to make it
"official".

On Tue, 2011-01-25 at 12:05 +0100, Koen Kooi wrote:
> Ignoring the timeline a bit, since ideally we would do this around a
> yocto milestone to get them to use this straight after their freeze.
> 
> The technical roadmap/todo:
> 
> * setup openembedded-core repo on oe.org
> * setup oe-core ml on oe.org
> * add oe-core ml to patchwork

For these I'd like to confirm that we have sysadmins who are happy that
there is capability there for these things and that they have time to
work on them.

I'm also thinking Yocto would want to mirror oe-core on
git.yoctoproject.org.

> * import yocto-core in oe-core
> * start an integration branch
>  o remove bitbake
>  o cleanup namespace (s/yocto/OE/, s/poky/OE/)
>  o split out superfluous layers (e.g. ememlow)

For this I'd like to time it so the changes are in sync with what Yocto
is doing. I'm tempted to suggest we preempt this a little and start
rearranging Poky now with this in mind?

> * start merging in OE things
>  o e.g. OE gcc 4.5, toolchains for avr32, bfin, etc

Last time I talked to Khem the OE gcc 4.5 toolchain didn't boot under
Poky's qemu. We have since updated the qemu in Poky but I'd like to
actually figure out what was wrong there. Khem couldn't get qemu in Poky
to work which is another issue that we need to resolve.

I am a little worried about lots of platform specific toolchains merging
straight into the core as those might be better as platform/architecture
specific layers.

> * switch meta-oe to build on top of oe-core, fix issues
> 
> When that is done meta-oe can start to expand.
> 
> The non-technical roadmap/todo:
> 
> * Assign 2 gatekeepers to oe-core, one from yocto, one from OE

From the Yocto side, Saul Wold is the person here.

> * sketch out decision tree (RP -> gatekeepers -> maintainers)
> * work out model for meta-oe
> * appoint OE member to yocto SC
> * work out how to marry yocto goals (4 archs, one toolchain) to OE goals
> (zillion archs, as much toolchains as we can manage)

This is related to my comments above. I would like to see a little
pressure to collaborate on one up to date toolchain which means
resolving our differences over gcc 4.5 and then handling the
architecture specific ones.

> * Work out OE roadmap and align with yocto
> 
> The above tries to restrict itself to dealing with the new oe-core, not
> with how OE is going to split into layers (meta-oe, meta-graveyard, etc).
> It also ignores the maintainer aspects since we will be dealing with
> yocto metadata at the start. After oe-core reaches a ready enough state
> we can start looking at assigning maintainers, but for the time being
> let's get things done first.
> 
> So, let's start fleshing out the above roadmaps and implement them!

Sounds like a reasonable plan but see my comments at the start.

The time is right to change around the code in poky to make some of the
steps easier though and I'm happy to take patches for that now (I'm
going to start looking at those changes myself too). This would feed
directly into making the above easier.

Cheers,

Richard

Re: openembedded-core git repository

[Koen Kooi]

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

On 25-01-11 16:23, Richard Purdie wrote:
> Firstly, just for reference, the TSC is having some discussions between
> its members and I'd expect some kind of result from that to be made
> public soon.

> I think its fine to talk about this and form a plan but I would like to
> see some representation from the board and TSC over this to make it
> "official".
> 
> On Tue, 2011-01-25 at 12:05 +0100, Koen Kooi wrote:
>> Ignoring the timeline a bit, since ideally we would do this around a
>> yocto milestone to get them to use this straight after their freeze.
>>
>> The technical roadmap/todo:
>>
>> * setup openembedded-core repo on oe.org
>> * setup oe-core ml on oe.org
>> * add oe-core ml to patchwork
> 
> For these I'd like to confirm that we have sysadmins who are happy that
> there is capability there for these things and that they have time to
> work on them.

Tom can create the git repo, Khem can do patchwork and I can create new
a ml.
The seperate ml makes it possible to mark it as a different project in
patchwork, which makes viewing the outstanding patch q a lot easier.

> I'm also thinking Yocto would want to mirror oe-core on
> git.yoctoproject.org.

The more mirrors, the merrier.

>> * import yocto-core in oe-core
>> * start an integration branch
>>  o remove bitbake
>>  o cleanup namespace (s/yocto/OE/, s/poky/OE/)
>>  o split out superfluous layers (e.g. ememlow)
> 
> For this I'd like to time it so the changes are in sync with what Yocto
> is doing. I'm tempted to suggest we preempt this a little and start
> rearranging Poky now with this in mind?

That would be great! I think it's safe to assume that the people
interesting in working on this are already subscribed to the poky@yocto
list, but we should cross-post to the oe-core list when that goes live
as well.

>> * start merging in OE things
>>  o e.g. OE gcc 4.5, toolchains for avr32, bfin, etc
> 
> Last time I talked to Khem the OE gcc 4.5 toolchain didn't boot under
> Poky's qemu. 

FWIW, it does boot on real hardware:

root@pandaboard-yocto:~# lsb_release -a ; uname -a
Distributor ID: Angstrom
Description:    Angstrom GNU/Linux v20110125 (yoctopus)
Release:        v20110125
Codename:       yoctopus
Linux pandaboard-yocto 2.6.35.3+ #1 SMP PREEMPT Wed Jan 12 12:01:43 CET
2011 armv7l GNU/Linux
root@pandaboard-yocto:~#

That's built with
http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/recipes-devtools/gcc
, which is a copy of yocto gcc with its SRC_URI replaces with the OE one.

> We have since updated the qemu in Poky but I'd like to
> actually figure out what was wrong there. Khem couldn't get qemu in Poky
> to work which is another issue that we need to resolve.
> 
> I am a little worried about lots of platform specific toolchains merging
> straight into the core as those might be better as platform/architecture
> specific layers.

If there are people willing to keep an architecture building and booting
it should live in the core layer. But a might-or-might-not-work layer
where architectures can migrate to and from would be an option. Both
core and might-or-might-not-work layer could live in the oe-core git repo.

>> * switch meta-oe to build on top of oe-core, fix issues
>>
>> When that is done meta-oe can start to expand.
>>
>> The non-technical roadmap/todo:
>>
>> * Assign 2 gatekeepers to oe-core, one from yocto, one from OE
> 
>>From the Yocto side, Saul Wold is the person here.

I'm available for the OE side, maybe Khem is available for that as well
so we can rotate to divide workload on the OE side.

>> * sketch out decision tree (RP -> gatekeepers -> maintainers)
>> * work out model for meta-oe
>> * appoint OE member to yocto SC
>> * work out how to marry yocto goals (4 archs, one toolchain) to OE goals
>> (zillion archs, as much toolchains as we can manage)
> 
> This is related to my comments above. I would like to see a little
> pressure to collaborate on one up to date toolchain which means
> resolving our differences over gcc 4.5 and then handling the
> architecture specific ones.

Exactly. With my armv7a hat on, the yocto one has bugs that are solved
in the OE one, but it could be the reverse for other architectures.
A technical pro of the OE version is that the patches are split up and
labeled, as well as clearly showing the gcc mainline patches(srcrev of
4.5 stable branch) instead 4.5.1 tarball and a handfull of backports.

The other differences like the fedoro DSO patch shouldn't matter, those
can be rediffed against the OE one.

>> * Work out OE roadmap and align with yocto
>>
>> The above tries to restrict itself to dealing with the new oe-core, not
>> with how OE is going to split into layers (meta-oe, meta-graveyard, etc).
>> It also ignores the maintainer aspects since we will be dealing with
>> yocto metadata at the start. After oe-core reaches a ready enough state
>> we can start looking at assigning maintainers, but for the time being
>> let's get things done first.
>>
>> So, let's start fleshing out the above roadmaps and implement them!
> 
> Sounds like a reasonable plan but see my comments at the start.
> 
> The time is right to change around the code in poky to make some of the
> steps easier though and I'm happy to take patches for that now (I'm
> going to start looking at those changes myself too). This would feed
> directly into making the above easier.

I'll wait with patches till I finish testing your tt-bootstrap branch :)

regards,

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

iD8DBQFNPvLAMkyGM64RGpERAluPAJ9VBck98OCNAxG/CBRGdR0g+S0zQgCfRKh9
vhsefu4AVLE+o/YBeLKRdEk=
=FNnt
-----END PGP SIGNATURE-----

Re: openembedded-core git repository

[Khem Raj]

On Tue, Jan 25, 2011 at 7:23 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
>
>> * start merging in OE things
>>  o e.g. OE gcc 4.5, toolchains for avr32, bfin, etc
>
> Last time I talked to Khem the OE gcc 4.5 toolchain didn't boot under
> Poky's qemu. We have since updated the qemu in Poky but I'd like to
> actually figure out what was wrong there. Khem couldn't get qemu in Poky
> to work which is another issue that we need to resolve.
>

I had issues regardless of OE gcc or poky gcc used. It was problem with qemu
built with poky. Once I used the qemu from OE all images booted well.

> I am a little worried about lots of platform specific toolchains merging
> straight into the core as those might be better as platform/architecture
> specific layers.
>

I think we could say that whatever architectures can be supported by gcc 4.5
we should not create layers for those to avoid duplication but arches which need
a completely different version of gcc could be separated out into layers

>

Re: openembedded-core git repository

[Khem Raj]

On Tue, Jan 25, 2011 at 3:05 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> Ignoring the timeline a bit, since ideally we would do this around a
> yocto milestone to get them to use this straight after their freeze.
>
> The technical roadmap/todo:
>
> * setup openembedded-core repo on oe.org
> * setup oe-core ml on oe.org
> * add oe-core ml to patchwork
> * import yocto-core in oe-core
> * start an integration branch
>  o remove bitbake
>  o cleanup namespace (s/yocto/OE/, s/poky/OE/)
>  o split out superfluous layers (e.g. ememlow)
> * start merging in OE things
>  o e.g. OE gcc 4.5, toolchains for avr32, bfin, etc
> * switch meta-oe to build on top of oe-core, fix issues
>
> When that is done meta-oe can start to expand.
>
> The non-technical roadmap/todo:
>
> * Assign 2 gatekeepers to oe-core, one from yocto, one from OE
> * sketch out decision tree (RP -> gatekeepers -> maintainers)
> * work out model for meta-oe
> * appoint OE member to yocto SC
> * work out how to marry yocto goals (4 archs, one toolchain) to OE goals
> (zillion archs, as much toolchains as we can manage)
> * Work out OE roadmap and align with yocto
>
> The above tries to restrict itself to dealing with the new oe-core, not
> with how OE is going to split into layers (meta-oe, meta-graveyard, etc).
> It also ignores the maintainer aspects since we will be dealing with
> yocto metadata at the start. After oe-core reaches a ready enough state
> we can start looking at assigning maintainers, but for the time being
> let's get things done first.
>
> So, let's start fleshing out the above roadmaps and implement them!

very well said. I think lets get started by setting up the repo.

>
> regards,
>
> Koen

Re: openembedded-core git repository

[Koen Kooi]

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

On 24-01-11 17:39, Philip Balister wrote:
> On 01/19/2011 06:48 AM, Graeme Gregory wrote:
>> Hi, this email is sent as an ordinary member of OE.
>>
>> It seems to be on a technical level we are agreed that we should split
>> parts of OE out into the so called openembedded-core which will have a
>> stricter commit access and higher QA requirements on changes.
>>
>> I therefore think it is time to actually create the repository and let
>> the people who are interested in merging the good stuff from poky with
>> the good stuff from openembedded to create our "core". I don't think
>> there is any need to wait on the political part of the Yocto/OE
>> collaboration as its something we have agreed in principal to do anyway.
>>
>> I would request then that the TSC drive this forward with the server
>> admins and create this repo so work can happen.
> 
> 
> Has anything happened on this email? Has the TSC had a meeting to
> discuss? I know it has only been a week, but people are starting to do
> work based on these ideas and need some support from the TSC.

At this point I'm going to call for a vote of non confidence in the TSC.
If they can't be bothered to speak up in an important matter like this,
we'd be better of without them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNPfJ4MkyGM64RGpERAr5bAKCJlqjvcXHIbrZR5jQjAEAhBp4NdQCffnW0
JGXHmRMZYLsptyPpDrqKKkY=
=7ASP
-----END PGP SIGNATURE-----

Re: openembedded-core git repository

[Richard Purdie]

On Mon, 2011-01-24 at 22:43 +0100, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 24-01-11 17:39, Philip Balister wrote:
> > On 01/19/2011 06:48 AM, Graeme Gregory wrote:
> >> Hi, this email is sent as an ordinary member of OE.
> >>
> >> It seems to be on a technical level we are agreed that we should split
> >> parts of OE out into the so called openembedded-core which will have a
> >> stricter commit access and higher QA requirements on changes.
> >>
> >> I therefore think it is time to actually create the repository and let
> >> the people who are interested in merging the good stuff from poky with
> >> the good stuff from openembedded to create our "core". I don't think
> >> there is any need to wait on the political part of the Yocto/OE
> >> collaboration as its something we have agreed in principal to do anyway.
> >>
> >> I would request then that the TSC drive this forward with the server
> >> admins and create this repo so work can happen.
> > 
> > 
> > Has anything happened on this email? Has the TSC had a meeting to
> > discuss? I know it has only been a week, but people are starting to do
> > work based on these ideas and need some support from the TSC.
> 
> At this point I'm going to call for a vote of non confidence in the TSC.
> If they can't be bothered to speak up in an important matter like this,
> we'd be better of without them.

I've kept a low profile on this issue since I'm obviously heavily
involved with Yocto and hence it could be argued I'm not impartial. I
had hoped someone else on the TSC would therefore pick up this
discussion but that hasn't happened. I have driven issues in the past,
this is one I really can't drive alone.

The TSC have been having trouble managing to organise meetings,
organising minutes and have not been very responsive recently. There are
a whole spectrum of reasons for that but at a time when OE really needs
technical guidance this is a problem.

The message here isn't to the oe-members list in the correct form so
this isn't an official vote at this time but if it were, I think I'd
find myself in the unusual position of voting in favour of a vote of no
confidence for a group I'm actually part of :/.

I'd actually like to see people with the technical understanding and
time to spend help guiding OE such Koen and Khem on the TSC.

Cheers,

Richard