Re: proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer

[Mark Hatle <mark.hatle@windriver.com>]

On 5/10/13 3:22 PM, Otavio Salvador wrote:
> On Fri, May 10, 2013 at 2:19 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Fri, 2013-05-10 at 17:39 +0100, Tomas Frydrych wrote:
>>> On 10/05/13 12:32, Richard Purdie wrote:
>>>> On Fri, 2013-05-10 at 11:56 +0100, Tomas Frydrych wrote:
>>>>> On 10/05/13 10:05, Richard Purdie wrote:
>>>> The closely track upstream is the key part and I think the core can do
>>>> this, apart from the ~six week stabilisation window.
>>>
>>> If you mean you are prepared to do frequent point releases to keep up
>>> with clutter, that could work. But if you mean that those interested can
>>> closely track oe-core master, then that is not that useful, there are
>>> too many other changes happening at the same time. A small single
>>> purpose layer means updates (and breakages) can be very contained.
>>
>> Point releases of what? I don't mind clutter in master changing quite a
>> lot up to our stabilisation point. Once we've released, I don't mind
>> someone else picking up a danny-clutter branch or something like that
>> which is backporting specific changes.
>
> So we're going to have <branch>-<pet package> branches? I think this
> does not scale and I am at Tomas side. The layer seems the right thing
>   to do so it does not need to be done by branch and avoid confusing
> users.
>
>>>> My argument for this is that I really do want to stress out the graphics
>>>> stack we have, clutter provides a good way to test some of those
>>>> components, particularly some of the more unusual parts. Currently its
>>>> mostly build test however we do have plans to make that runtime too. I
>>>> do think that clutters unusual usage of the stack makes it particular
>>>> useful in this role. I'd appreciate help from anyone who can help make
>>>> this all work.
>>>
>>> I am all for this, but does using clutter for automated tests require
>>> for the clutter packages to be in oe-core? The only thing you can stress
>>> test in oe-core using clutter is mesa, which is only applicable to the
>>> i915/i965 chip sets. I think it would be useful if any such tests could
>>> be applied to other graphics stacks provided by BSPs; I think all of the
>>> BSPs would benefit from this.
>>
>> We'd be able to test mesa and the software fallbacks under qemu which
>> would be a start. If we can get those working with a decent framework
>> for the tests, I'm hoping wider BSP testing would follow. I don't have
>> unlimited resources available but I can try and get the software
>> infrastructure to the point where doing the testing could be picked up
>> by someone else relatively easily.
>
> You could do just the same but adding meta-clutter to the AB setup for
> testing. One thing does not conflict with the another.
>
>> It is a big help in trying to achieve this if we don't have many
>> different layers involved as that would complicate the problem, even
>> coordinating layer releases between different maintainers is tricky
>> right now and trying to develop something like this over layer
>> boundaries sounds like adding to the complexity to the point I'd rather
>> just scrap the idea :(.
>
> Well if layers make life harder it invalidates one of points of Yocto
> which I always liked and depends on heavily - modular design.

One of the key pieces of the oe-core, it must be able to work without any 
additional layers.  It also much be able to be tested without any additional layers.

I personally don't have a preference for the clutter and related items on where 
they live... but I do want to make sure that oe-core can standalone as a 
starting point for people to develop devices.  Part of being standalone means 
that it is capable of being tested.

--Mark

> I am sure we all want a solid release so I am also sure Tomas wouldn't
> put experimental version of clutter near of release. We are eating our
> own dog food so we are all interested in make it work, not the
> opposed. In this case I think it can be well coordinated.
>
> One possible thing is you could require AB used layers to be at
> git.yoctoproject.org so in case of broken recipes (bbappend or so) you
> could  rename it.
>
>>> I'd really like for people to be able to just pick up uptodate and
>>> working clutter packages for the major platforms the actively maintained
>>> BSPs support.
>>
>> Agreed.
>>
>>>   Every so often someone asks about clutter for XYZ (usually
>>> the Beagleboard or RPi) on the clutter list: this should be readily
>>> available somewhere.
>>
>> I'd hope the recipes in the core would be in a good state in this
>> regard.
>
> Good weekend for everyone :-)
>
> Regards,
>
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>