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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2013-05-10 at 17:22 -0300, 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?

There may be a time and a place for such things and its not different to
the situation you'll end up in with a meta-clutter repository where
you'll likely end up with danny-1.12 and danny-1.14 branches, or
multiple sets of recipes in a single danny branch, thereby changing the
definition of "stable" from that used in the core which will be
confusing in itself.

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

You're swapping one set of problems for another set the way I see it.

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

I've always been extremely clear that I believe the core needs to stand
on its own, including being testable. I appreciate some people disagree
with that however I believe that without this, the quality in the core
would drop substantially. Even maintaining the testability of what we
have now is actually an incredible challenge. Anyone who thinks
otherwise should spend a week triaging the autobuilder failures.

Adding mode dimensions to a problem we already struggle with seems like
a bad idea to me.

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

The layer model has its risks as well as its advantages. The risk is
that we end up too fragmented, with too many maintainers who don't
communicate and nothing ever works together.

Even as the model stands today, its showing signs of strain. I posted
patches near enough three weeks ago for meta-raspberrypi, no response. I
know there are reasons why but they're not visible. The meta-fsl layers
appear to spend more of their time not building than building and
getting people to fix those in a timely fashion can sometimes be
challenging, particularly with the split between arm and ppc and some of
the transitions going on there etc.

Right now, I think there are enough splits causing enough
interoperability issues to be going on with in the layers and no, to be
quite honest I don't think more layers is the right answer right now.

I do continue to believe in the layer model but it is still evolving and
I'd really like us to focus on the current issues.

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

From what I read of Tomas' emails, I actually think his plans differ
from that as he finds that aspect of OE-Core frustrating.

>  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 don't touch layers I don't maintain. If I did that, I would get hung,
drawn and quartered. Please at least think through things like this
before saying them :(. Can you imagine what you'd say to me if I pushed
commits to meta-fsl-arm? 

This isn't even hypothetical, I have already been "told off" for pushing
to repos I am not the official maintainer for in much less controversial
circumstances than this. The offence was not writing a detailed enough
commit message to conform to that repository's guidelines. FWIW, I
believe the maintainer was right to object.

Cheers,

Richard