On 5/10/13 3:22 PM, Otavio Salvador wrote:
On Fri, May 10, 2013 at 2:19 PM, Richard Purdie
<[email protected]> 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: [email protected] http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
