[OE-core] Qt in OE-core

[Philip Balister]

On 01/08/2014 06:57 PM, Richard Purdie wrote:
> On Wed, 2014-01-08 at 23:21 +0000, Paul Eggleton wrote:
>> On Wednesday 08 January 2014 13:44:59 Trevor Woerner wrote:
>>> On 01/08/14 10:56, Paul Eggleton wrote:
>>>> However, one concern I have always had with Qt being moved out of
>>>> OE-Core though is that I very much doubt the same will happen with
>>>> GTK+ and GNOME UI components that we carry, which I think will lead to
>>>> the (perhaps erroneous, but logical) assumption in new users' minds
>>>> that we support or recommend these more than we do Qt. Given Qt's
>>>> popularity in the embedded space I don't think this would be the right
>>>> message to be sending out. Any concrete ideas on how we would address
>>>> this perception issue?
>>>
>>> Would it be worthwhile to ask that the OE TSC take on the task of
>>> defining what is "core" and what is not? Does this definition already exist?
>>
>> If we can't come up with a consensus here, then yes. The trouble is one 
>> person's idea of "core" is likely going to be very different to another's. If 
>> your UI is written using Qt, that's going to be core to what you are doing. If 
>> your UI is a custom one written using SDL you won't give two hoots about 
>> recipes for building Qt/GTK+ and everything related. Where do you draw the 
>> line?
>>
>> Although it hasn't been rigorously defined since the beginning and there are 
>> definitely some fuzzy edges, I think the selection of recipes in OE-Core has 
>> worked reasonably well. We should stop from time to time to evaluate it, but 
>> equally we should think carefully before we pull the whole thing to pieces.
> 
> Agreed. Its nice from a theoretical perspective to stand and say yes,
> there should be all these layers. The reality is a lot of the stack has
> fairly tangled and crossed up dependencies.

When making a new layer, we should think hard about what layers it needs
to depends on. Layers should try not to lead to exploding depends.

I am developing a concept in my head of a set of layers it is "safe" to
depend on.

Philip

> 
> I'm much more interested to look at things and say "which are the mostly
> commonly used pieces of software which a significant number of systems
> would use"?
> 
> Not every system has a screen, not every system has networking etc. but
> there is a common "core" OS which is used in most places and I think
> OE-Core should be aiming to provide those basics.
> 
> LSB is one guideline we can use for reference of trends. Gut feeling and
> experience are other factors that feed into this.
> 
> There are then other elements. I'm on record as strongly believing its
> not enough to have a software stack, we need to test it too and that
> having test capability in the core should be a key value. This isn't
> something found traditionally in desktop Linux however it is key to what
> we do and we therefore should differ here. (I should explain that by the
> fact we allow so much customisation, being able to easily test the
> output is important).
> 
> There is also another element which is one of the Yocto Project's
> objectives. This is to focus people around creating a small number of
> good tools rather than many all with some bad points. Its not
> specifically an OE objective but OE-Core is a collaboration between OE
> and the Yocto Project and I think it should be taken into account (and
> is a good thing in general for embedded Linux in general too).
> 
> Piglit is interesting in that context since it would be nice to focus
> around one way of testing GL rather than having many different ways. If
> putting piglit into OE-Core helps that objective then I'm in favour for
> that reason too.
> 
> So whilst its good to ask the questions, I do think what we have in
> OE-Core is pretty good and I wouldn't like to hastily change what seems
> to be working quite well at least from where I see it, particularly to
> satisfy some "clean" separation idea which looks good on paper but is
> less useful in the real world. Regardless of what we do, there are going
> to be edge cases and at the end of the day someone has to make a call.
> In the case of OE-Core that is ultimately down to me as the maintainer
> and the TSC.
> 
> We've made choices to remove some things, we've also made decisions to
> add others and this will continue and is healthy. With piglit, I'm
> leaning more in favour the more I think about it. With meta-qt5 its
> still marginal. The wishes of the existing meta-qt5 maintainers need to
> be taken into account there too.
> 
> The TSC have discussed this before and to one extent or another these
> points come up. I'm more than happy for others to add to the list or
> correct the above but this is probably as good a description of the core
> as you're going to get. Its simply not possible to avoid corner cases
> and there always will be some grey areas. Personally I think there are
> other things we need to spend time on beyond this.
> 
> Cheers,
> 
> Richard
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
>