[meta-ti] [PATCH 1/3] matrix-gui-browser: port from arago overlay

[William Mills]

OK this part is off list.

Go look at meta-intel and then look at the meta-ti your guys are 
purposing.   Now, your an engineer in a hurry and you need to choose 
between intel ATOM and TI ARM.  Which one looks simpler, clearer, and 
well organized.  Which do you want to use?

We are already way behind on simplicity of message.  We need to keep as 
much stuff out of here as we can.

On 01/27/2012 02:46 PM, Maupin, Chase wrote:
>> -----Original Message-----
>> From: Mills, William
>> Sent: Friday, January 27, 2012 11:51 AM
>> To: Maupin, Chase
>> Cc: Koen Kooi; meta-ti at yoctoproject.org
>> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from
>> arago overlay
>>
>> On 01/27/2012 08:50 AM, Maupin, Chase wrote:
>>
>>   >  but I definitely don’t think matrix belongs in meta-arago
>>
>> Why, justify.  Yes matrix needs to be different than the distro
>> definition on arago but As you point out below the only people
>> using
>> Matrix are Arago and Koen in Angstrom.  I think this comes down to
>> not
>> wanting the word "arago" occurring in the Angstrom layer stack.
>>
>> meta-ti should be about using TI chips.  Matrix and other demo
>> programs
>> we put together for our demo distro are not essential to using TI
>> chips.
> I guess we have a difference of opinion on how we see meta-arago.  I don’t separate that layer into distro and non-distro.  I was really planning on meta-arago being all the stuff related to the arago/SDK distribution.  Meta-ti is for TI packages that can be used by other distros.  That being said I'm OK with meta-ti being split into a BSP layer and everthing else, but I don't know exactly what that buys us.  Does it particularly hurt someone that pulls in meta-ti to have access to matrix if they don't use it?  I pull in things from meta-oe or oe-core that I don’t "need" but they are there anyway.
>
>>> 1. As of now matrix is only maintained by TI and used by TI (and
>> Koen to some extent) on our products.  So I would put this in a
>> layer that we maintain because it would seem strange to me to have
>> to go through another set of maintainers to update the SRCREV of
>> the package we are developing.  Particularly if no one is using it.
>>> 2. If people wanted matrix they could still include our layer to
>> get it.  If we see that happening a lot a there is a request from a
>> group of people to have this then we could push it lower, but if we
>> are the only ones using it and who care about it then I don't see
>> the reason to move this lower in the layer stack.