Fix image recipes in meta-ti

Fix image recipes in meta-ti

[Cooper Jr., Franklin]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

When debugging issues in meta-arago I frequently try building recipes using  the meta-ti,meta-oe and oe-core layers. However, I always have to remove the following recipes due to "This recipe does not have the LICENSE field set" error:
cloud9-gfx-image.bb
cloud9-gnome-image.bb
cloud9-image.bb

The issue is these recipes have an include from meta-angstrom that provides this LICENSE field. Meta-ti should not have this dependency so these recipes should be fixed to address this. I personally do not think cloud9 related recipes that install  cloud9, nodejs, mplayer etc.. should even be in meta-ti which is a BSP layer but that is a completely different discussion. I also don't believe pulling in the include file that is needed from meta-angstrom is also a reasonably solution. Either these recipes need to be fixed so that they can work in meta-ti with only a dependency on meta-oe and oe-core. Or remove the recipes from this layer and pull it into meta-angstrom which I believe is the best option.
Regards,
Franklin Cooper Jr.
Texas Instruments
Application Engineer
fcooper@ti.com<mailto:fcooper@ti.com>


[-- Attachment #2: Type: text/html, Size: 3187 bytes --]

Re: Fix image recipes in meta-ti

[Kridner, Jason]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

Will meta-oe take the recipes?


-------- Original message --------
Subject: [meta-ti] Fix image recipes in meta-ti
From: "Cooper Jr., Franklin" <fcooper@ti.com>
To: "meta-ti@yoctoproject.org" <meta-ti@yoctoproject.org>
CC:


When debugging issues in meta-arago I frequently try building recipes using  the meta-ti,meta-oe and oe-core layers. However, I always have to remove the following recipes due to “This recipe does not have the LICENSE field set” error:
cloud9-gfx-image.bb
cloud9-gnome-image.bb
cloud9-image.bb

The issue is these recipes have an include from meta-angstrom that provides this LICENSE field. Meta-ti should not have this dependency so these recipes should be fixed to address this. I personally do not think cloud9 related recipes that install  cloud9, nodejs, mplayer etc.. should even be in meta-ti which is a BSP layer but that is a completely different discussion. I also don’t believe pulling in the include file that is needed from meta-angstrom is also a reasonably solution. Either these recipes need to be fixed so that they can work in meta-ti with only a dependency on meta-oe and oe-core. Or remove the recipes from this layer and pull it into meta-angstrom which I believe is the best option.
Regards,
Franklin Cooper Jr.
Texas Instruments
Application Engineer
fcooper@ti.com<mailto:fcooper@ti.com>


[-- Attachment #2: Type: text/html, Size: 2598 bytes --]

Re: Fix image recipes in meta-ti

[Cooper Jr., Franklin]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

Unless the meta-angstrom dependency is fixed then I would see them having the same issue.

On Sep 1, 2012, at 4:14 PM, "Kridner, Jason" <jdk@ti.com<mailto:jdk@ti.com>> wrote:

Will meta-oe take the recipes?


-------- Original message --------
Subject: [meta-ti] Fix image recipes in meta-ti
From: "Cooper Jr., Franklin" <fcooper@ti.com<mailto:fcooper@ti.com>>
To: "meta-ti@yoctoproject.org<mailto:meta-ti@yoctoproject.org>" <meta-ti@yoctoproject.org<mailto:meta-ti@yoctoproject.org>>
CC:


When debugging issues in meta-arago I frequently try building recipes using  the meta-ti,meta-oe and oe-core layers. However, I always have to remove the following recipes due to “This recipe does not have the LICENSE field set” error:
cloud9-gfx-image.bb
cloud9-gnome-image.bb
cloud9-image.bb

The issue is these recipes have an include from meta-angstrom that provides this LICENSE field. Meta-ti should not have this dependency so these recipes should be fixed to address this. I personally do not think cloud9 related recipes that install  cloud9, nodejs, mplayer etc.. should even be in meta-ti which is a BSP layer but that is a completely different discussion. I also don’t believe pulling in the include file that is needed from meta-angstrom is also a reasonably solution. Either these recipes need to be fixed so that they can work in meta-ti with only a dependency on meta-oe and oe-core. Or remove the recipes from this layer and pull it into meta-angstrom which I believe is the best option.
Regards,
Franklin Cooper Jr.
Texas Instruments
Application Engineer
fcooper@ti.com<mailto:fcooper@ti.com>


[-- Attachment #2: Type: text/html, Size: 3011 bytes --]

Re: Fix image recipes in meta-ti

[Maupin, Chase]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

Agreed for my two cents.

Sent from my cell phone

----- Reply message -----
From: "Cooper Jr., Franklin" <fcooper@ti.com>
Date: Sat, Sep 1, 2012 4:07 pm
Subject: [meta-ti] Fix image recipes in meta-ti
To: "meta-ti@yoctoproject.org" <meta-ti@yoctoproject.org>

When debugging issues in meta-arago I frequently try building recipes using  the meta-ti,meta-oe and oe-core layers. However, I always have to remove the following recipes due to “This recipe does not have the LICENSE field set” error:
cloud9-gfx-image.bb
cloud9-gnome-image.bb
cloud9-image.bb

The issue is these recipes have an include from meta-angstrom that provides this LICENSE field. Meta-ti should not have this dependency so these recipes should be fixed to address this. I personally do not think cloud9 related recipes that install  cloud9, nodejs, mplayer etc.. should even be in meta-ti which is a BSP layer but that is a completely different discussion. I also don’t believe pulling in the include file that is needed from meta-angstrom is also a reasonably solution. Either these recipes need to be fixed so that they can work in meta-ti with only a dependency on meta-oe and oe-core. Or remove the recipes from this layer and pull it into meta-angstrom which I believe is the best option.
Regards,
Franklin Cooper Jr.
Texas Instruments
Application Engineer
fcooper@ti.com<mailto:fcooper@ti.com>


[-- Attachment #2: Type: text/html, Size: 3210 bytes --]

Re: Fix image recipes in meta-ti

[Denys Dmytriyenko]

On Sat, Sep 01, 2012 at 09:07:31PM +0000, Cooper Jr., Franklin wrote:
> When debugging issues in meta-arago I frequently try building recipes using  
> the meta-ti,meta-oe and oe-core layers. However, I always have to remove the 
> following recipes due to "This recipe does not have the LICENSE field set" 
> error:
> cloud9-gfx-image.bb
> cloud9-gnome-image.bb
> cloud9-image.bb

FWIW, meta-arago explicitly masks those recipes, so you shouldn't be having 
those errors or have to remove the recipes:
http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-distro/conf/distro/arago.conf;hb=HEAD#l2

Also, it was discussed here just few days ago:
https://lists.yoctoproject.org/pipermail/meta-ti/2012-August/001456.html


> The issue is these recipes have an include from meta-angstrom that provides 
> this LICENSE field. Meta-ti should not have this dependency so these recipes 
> should be fixed to address this. I personally do not think cloud9 related 
> recipes that install  cloud9, nodejs, mplayer etc.. should even be in 
> meta-ti which is a BSP layer but that is a completely different discussion. 
> I also don't believe pulling in the include file that is needed from 
> meta-angstrom is also a reasonably solution. Either these recipes need to be 
> fixed so that they can work in meta-ti with only a dependency on meta-oe and 
> oe-core. Or remove the recipes from this layer and pull it into 
> meta-angstrom which I believe is the best option.

So, what do you propose? ;) Or you just volunteering to be in the middle of 
a flame war by raising this hard issue?

-- 
Denys

Re: Fix image recipes in meta-ti

[Denys Dmytriyenko]

On Sat, Sep 01, 2012 at 09:14:43PM +0000, Kridner, Jason wrote:
> Will meta-oe take the recipes?

Well, those maybe better suited for meta-angstrom instead... If you think 
about it - cloud9 is an important component of default Beaglebone images based 
on Angstrom, so images with the cloud9 in the name are naturally associated 
with Angstrom. Anybody else who'd like to use meta-ti as BSP layer outside of 
Angstrom would most probably use own images anyway...

-- 
Denys


> -------- Original message --------
> Subject: [meta-ti] Fix image recipes in meta-ti
> From: "Cooper Jr., Franklin" <fcooper@ti.com>
> To: "meta-ti@yoctoproject.org" <meta-ti@yoctoproject.org>
> CC:
> 
> 
> When debugging issues in meta-arago I frequently try building recipes using  
> the meta-ti,meta-oe and oe-core layers. However, I always have to remove the 
> following recipes due to ?This recipe does not have the LICENSE field set? 
> error:
> cloud9-gfx-image.bb
> cloud9-gnome-image.bb
> cloud9-image.bb
> 
> The issue is these recipes have an include from meta-angstrom that provides 
> this LICENSE field. Meta-ti should not have this dependency so these recipes 
> should be fixed to address this. I personally do not think cloud9 related 
> recipes that install  cloud9, nodejs, mplayer etc.. should even be in 
> meta-ti which is a BSP layer but that is a completely different discussion. 
> I also don?t believe pulling in the include file that is needed from 
> meta-angstrom is also a reasonably solution. Either these recipes need to be 
> fixed so that they can work in meta-ti with only a dependency on meta-oe and 
> oe-core. Or remove the recipes from this layer and pull it into 
> meta-angstrom which I believe is the best option.

Re: Fix image recipes in meta-ti

[Koen Kooi]

Op 2 sep. 2012, om 00:56 heeft Denys Dmytriyenko <denys@ti.com> het volgende geschreven:

> On Sat, Sep 01, 2012 at 09:14:43PM +0000, Kridner, Jason wrote:
>> Will meta-oe take the recipes?
> 
> Well, those maybe better suited for meta-angstrom instead... If you think 
> about it - cloud9 is an important component of default Beaglebone images based 
> on Angstrom, so images with the cloud9 in the name are naturally associated 
> with Angstrom. Anybody else who'd like to use meta-ti as BSP layer outside of 
> Angstrom would most probably use own images anyway...

I'd be happy to remove all those pesky beagleboard, beaglebone, pandaboard, etc related recipes, machines, images from meta-ti if they are causing such big, unsolvable problems for the TI SDK team. 

Re: Fix image recipes in meta-ti

[Cooper Jr., Franklin]

I will reiterate my initial point. The argument if the mentioned recipes should even be in meta-ti is a completely different discussion and beyond the scope of this discussion. The fact of the matter is meta-ti is broken unless you depend on meta-angstrom which is wrong. As Denys' pointed out (https://lists.yoctoproject.org/pipermail/meta-ti/2012-August/001452.html) this is a "minor" issue but an issue that other people are experiencing.

 Koen you have brought up valid points before in other discussions about not placing things in meta-ti that can break things for other people. The same logic applies here. All I want is a clean solution which will allow me to use meta-ti in a distroless environment which I do frequently. How this is accomplished I can care less.

-----Original Message-----
From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-bounces@yoctoproject.org] On Behalf Of Koen Kooi
Sent: Sunday, September 02, 2012 11:17 AM
To: Dmytriyenko, Denys
Cc: meta-ti@yoctoproject.org
Subject: Re: [meta-ti] Fix image recipes in meta-ti


Op 2 sep. 2012, om 00:56 heeft Denys Dmytriyenko <denys@ti.com> het volgende geschreven:

> On Sat, Sep 01, 2012 at 09:14:43PM +0000, Kridner, Jason wrote:
>> Will meta-oe take the recipes?
> 
> Well, those maybe better suited for meta-angstrom instead... If you 
> think about it - cloud9 is an important component of default 
> Beaglebone images based on Angstrom, so images with the cloud9 in the 
> name are naturally associated with Angstrom. Anybody else who'd like 
> to use meta-ti as BSP layer outside of Angstrom would most probably use own images anyway...

I'd be happy to remove all those pesky beagleboard, beaglebone, pandaboard, etc related recipes, machines, images from meta-ti if they are causing such big, unsolvable problems for the TI SDK team. 
_______________________________________________
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti

Re: Fix image recipes in meta-ti

[Maupin, Chase]

I agree with Denys and Franklin here.  Meta-ti should be a straight BSP layer so we should remove distro dependencies.  This is the same as moving netbase changes to meta-arago.  There may be things in meta-ti that don't belong there and they should be moved to the appropriate location

I understand that you have been using meta-ti and leading the way here, but that does not mean that we can't work together in this layer going forward.  You may have noticed that most of the TI SDK stuff has been going into meta-arago since that is where it belongs.  We are trying hard not to put things in meta-ti that will force others to use the arago distribution, I wouldask that we make sure the same applies for Angstrom as well, or any other distribution for that matter.

I'm confused where the objection is to moving these recipes that rely on the Angstrom layer into the actual Angstrom layer?  Let's discuss that topic and how we can structure this layer to meet everyone's needs.  That would likely be more productive and save us all frustration.

Sincerely,
Chase Maupin
On Sep 2, 2012, at 1:07 PM, "Cooper Jr., Franklin" <fcooper@ti.com> wrote:

> I will reiterate my initial point. The argument if the mentioned recipes should even be in meta-ti is a completely different discussion and beyond the scope of this discussion. The fact of the matter is meta-ti is broken unless you depend on meta-angstrom which is wrong. As Denys' pointed out (https://lists.yoctoproject.org/pipermail/meta-ti/2012-August/001452.html) this is a "minor" issue but an issue that other people are experiencing.
> 
> Koen you have brought up valid points before in other discussions about not placing things in meta-ti that can break things for other people. The same logic applies here. All I want is a clean solution which will allow me to use meta-ti in a distroless environment which I do frequently. How this is accomplished I can care less.
> 
> -----Original Message-----
> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-bounces@yoctoproject.org] On Behalf Of Koen Kooi
> Sent: Sunday, September 02, 2012 11:17 AM
> To: Dmytriyenko, Denys
> Cc: meta-ti@yoctoproject.org
> Subject: Re: [meta-ti] Fix image recipes in meta-ti
> 
> 
> Op 2 sep. 2012, om 00:56 heeft Denys Dmytriyenko <denys@ti.com> het volgende geschreven:
> 
>> On Sat, Sep 01, 2012 at 09:14:43PM +0000, Kridner, Jason wrote:
>>> Will meta-oe take the recipes?
>> 
>> Well, those maybe better suited for meta-angstrom instead... If you 
>> think about it - cloud9 is an important component of default 
>> Beaglebone images based on Angstrom, so images with the cloud9 in the 
>> name are naturally associated with Angstrom. Anybody else who'd like 
>> to use meta-ti as BSP layer outside of Angstrom would most probably use own images anyway...
> 
> I'd be happy to remove all those pesky beagleboard, beaglebone, pandaboard, etc related recipes, machines, images from meta-ti if they are causing such big, unsolvable problems for the TI SDK team. 
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: Fix image recipes in meta-ti

[Koen Kooi]

Op 2 sep. 2012, om 21:47 heeft "Maupin, Chase" <chase.maupin@ti.com> het volgende geschreven:

> I agree with Denys and Franklin here.  Meta-ti should be a straight BSP layer so we should remove distro dependencies.  This is the same as moving netbase changes to meta-arago.

I'm not sure if what you mean by this example. The current netbase patch is the second try to get it into meta-ti, will there be a 3rd try? 

>  There may be things in meta-ti that don't belong there and they should be moved to the appropriate location

And I completely agree.

> I understand that you have been using meta-ti and leading the way here, but that does not mean that we can't work together in this layer going forward.  You may have noticed that most of the TI SDK stuff has been going into meta-arago since that is where it belongs.  We are trying hard not to put things in meta-ti that will force others to use the arago distribution, I wouldask that we make sure the same applies for Angstrom as well, or any other distribution for that matter.

So show me where it is being forced. Really. There are no requires, only includes. So if you mean by 'forcing' that a few warnings may scroll by than, yes, it's being 'forced'. If you mean that the only way to use meta-ti is by using angstrom, than no, it's not being 'forced'. So instead of spreading more FUD, can you please use more precise language for the problem at hand? As I said above, I agree that those images don't belong in meta-ti. But funnily enough, that was not my decision. I was told to keep them there. By TI.

> I'm confused where the objection is to moving these recipes that rely on the Angstrom layer into the actual Angstrom layer?

For one, it was TI that objected to it. I don't care if some part of TI is now changing course on that. I care if some other part of TI is going to change course again in a few weeks. Just make a clear decision and stick with it instead of not doing a thing and rekindling the same old discussion every other month.
For two: They don't belong in the angstrom layer either, they are way too machine/SoC specific for that.

>  Let's discuss that topic and how we can structure this layer to meet everyone's needs.  That would likely be more productive and save us all frustration.

Like I said, I have no problem at all removing all beagle, bone and panda related things from meta-ti. In a previous incarnation of this discussion I offered to do that and was told by TI to keep everything in, both by SDO and AMBU people. So I'll offer it again now. So if you don't like that proposal, make a counter proposal.
Being an external contributor for the past 6 months has given me a good sense of what works and what doesn't work and what the level of (non)support the community can expect from TI. To be clear: Denys is doing an awesome job managing meta-ti, someone send him some cookies.

You work for TI, you get to dictate what happens in meta-ti, so make a proposal. I'm only a small part of the community, I have no illusions of being able to influence the direction of meta-ti. I can however look at your proposal and give my opinion on it.

Re: Fix image recipes in meta-ti

[Maupin, Chase]

> -----Original Message-----
> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
> bounces@yoctoproject.org] On Behalf Of Koen Kooi
> Sent: Sunday, September 02, 2012 4:11 PM
> To: meta-ti@yoctoproject.org
> Subject: Re: [meta-ti] Fix image recipes in meta-ti
> 
> 
> Op 2 sep. 2012, om 21:47 heeft "Maupin, Chase"
> <chase.maupin@ti.com> het volgende geschreven:
> 
> > I agree with Denys and Franklin here.  Meta-ti should be a
> straight BSP layer so we should remove distro dependencies.  This
> is the same as moving netbase changes to meta-arago.
> 
> I'm not sure if what you mean by this example. The current
> netbase patch is the second try to get it into meta-ti, will
> there be a 3rd try?

This will be moved to meta-arago based on your feedback.  I think there were some questions about what you meant but it is understood now.

> 
> >  There may be things in meta-ti that don't belong there and
> they should be moved to the appropriate location
> 
> And I completely agree.
> 
> > I understand that you have been using meta-ti and leading the
> way here, but that does not mean that we can't work together in
> this layer going forward.  You may have noticed that most of the
> TI SDK stuff has been going into meta-arago since that is where
> it belongs.  We are trying hard not to put things in meta-ti that
> will force others to use the arago distribution, I wouldask that
> we make sure the same applies for Angstrom as well, or any other
> distribution for that matter.
> 
> So show me where it is being forced. Really. There are no
> requires, only includes. So if you mean by 'forcing' that a few
> warnings may scroll by than, yes, it's being 'forced'. If you
> mean that the only way to use meta-ti is by using angstrom, than
> no, it's not being 'forced'. So instead of spreading more FUD,
> can you please use more precise language for the problem at hand?
> As I said above, I agree that those images don't belong in meta-
> ti. But funnily enough, that was not my decision. I was told to
> keep them there. By TI.

Who told you to keep these here?  Now that we have a better understanding of the layers and their purpose I'll close the loop within TI to make sure we give a single answer.

> 
> > I'm confused where the objection is to moving these recipes
> that rely on the Angstrom layer into the actual Angstrom layer?
> 
> For one, it was TI that objected to it. I don't care if some part
> of TI is now changing course on that. I care if some other part
> of TI is going to change course again in a few weeks. Just make a
> clear decision and stick with it instead of not doing a thing and
> rekindling the same old discussion every other month.
> For two: They don't belong in the angstrom layer either, they are
> way too machine/SoC specific for that.
> 
> >  Let's discuss that topic and how we can structure this layer
> to meet everyone's needs.  That would likely be more productive
> and save us all frustration.
> 
> Like I said, I have no problem at all removing all beagle, bone
> and panda related things from meta-ti. In a previous incarnation
> of this discussion I offered to do that and was told by TI to
> keep everything in, both by SDO and AMBU people. So I'll offer it
> again now. So if you don't like that proposal, make a counter
> proposal.
> Being an external contributor for the past 6 months has given me
> a good sense of what works and what doesn't work and what the
> level of (non)support the community can expect from TI. To be
> clear: Denys is doing an awesome job managing meta-ti, someone
> send him some cookies.

Let's consider a meta-beagle layer.  I'm thinking we should work to have meta-ti be a baseline of components we can agree on and move the rest to the appropriate layer.

> 
> You work for TI, you get to dictate what happens in meta-ti, so
> make a proposal. I'm only a small part of the community, I have
> no illusions of being able to influence the direction of meta-ti.
> I can however look at your proposal and give my opinion on it.
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: Fix image recipes in meta-ti

[Jason Kridner]

On Tue, Sep 4, 2012 at 9:53 AM, Maupin, Chase <chase.maupin@ti.com> wrote:
>> -----Original Message-----
>> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
>> bounces@yoctoproject.org] On Behalf Of Koen Kooi
>> Sent: Sunday, September 02, 2012 4:11 PM
>> To: meta-ti@yoctoproject.org
>> Subject: Re: [meta-ti] Fix image recipes in meta-ti
>>
>>
>> Op 2 sep. 2012, om 21:47 heeft "Maupin, Chase"
>> <chase.maupin@ti.com> het volgende geschreven:
>>
>> > I agree with Denys and Franklin here.  Meta-ti should be a
>> straight BSP layer so we should remove distro dependencies.  This
>> is the same as moving netbase changes to meta-arago.
>>
>> I'm not sure if what you mean by this example. The current
>> netbase patch is the second try to get it into meta-ti, will
>> there be a 3rd try?
>
> This will be moved to meta-arago based on your feedback.  I think there were some questions about what you meant but it is understood now.
>
>>
>> >  There may be things in meta-ti that don't belong there and
>> they should be moved to the appropriate location
>>
>> And I completely agree.
>>
>> > I understand that you have been using meta-ti and leading the
>> way here, but that does not mean that we can't work together in
>> this layer going forward.  You may have noticed that most of the
>> TI SDK stuff has been going into meta-arago since that is where
>> it belongs.  We are trying hard not to put things in meta-ti that
>> will force others to use the arago distribution, I wouldask that
>> we make sure the same applies for Angstrom as well, or any other
>> distribution for that matter.
>>
>> So show me where it is being forced. Really. There are no
>> requires, only includes. So if you mean by 'forcing' that a few
>> warnings may scroll by than, yes, it's being 'forced'. If you
>> mean that the only way to use meta-ti is by using angstrom, than
>> no, it's not being 'forced'. So instead of spreading more FUD,
>> can you please use more precise language for the problem at hand?
>> As I said above, I agree that those images don't belong in meta-
>> ti. But funnily enough, that was not my decision. I was told to
>> keep them there. By TI.
>
> Who told you to keep these here?  Now that we have a better understanding of the layers and their purpose I'll close the loop within TI to make sure we give a single answer.
>
>>
>> > I'm confused where the objection is to moving these recipes
>> that rely on the Angstrom layer into the actual Angstrom layer?
>>
>> For one, it was TI that objected to it. I don't care if some part
>> of TI is now changing course on that. I care if some other part
>> of TI is going to change course again in a few weeks. Just make a
>> clear decision and stick with it instead of not doing a thing and
>> rekindling the same old discussion every other month.
>> For two: They don't belong in the angstrom layer either, they are
>> way too machine/SoC specific for that.
>>
>> >  Let's discuss that topic and how we can structure this layer
>> to meet everyone's needs.  That would likely be more productive
>> and save us all frustration.
>>
>> Like I said, I have no problem at all removing all beagle, bone
>> and panda related things from meta-ti. In a previous incarnation
>> of this discussion I offered to do that and was told by TI to
>> keep everything in, both by SDO and AMBU people. So I'll offer it
>> again now. So if you don't like that proposal, make a counter
>> proposal.
>> Being an external contributor for the past 6 months has given me
>> a good sense of what works and what doesn't work and what the
>> level of (non)support the community can expect from TI. To be
>> clear: Denys is doing an awesome job managing meta-ti, someone
>> send him some cookies.
>
> Let's consider a meta-beagle layer.  I'm thinking we should work to have meta-ti be a baseline of components we can agree on and move the rest to the appropriate layer.

Chase, patches for meta-ti?

Koen, if I am the one who directed you to keep beagle stuff in meta-ti
(and I probably was and wasn't very specific in my language), it was
for the purpose of having the highest degree of collaboration. I
believe where we are landing is that the kernel mainline is the
primary point of collaboration and other attempts to collaborate on a
distro will mostly happen outside of meta-ti, such as in u-boot,
oe-core, meta-oe, etc.

I know Chase would like to keep meta-ti as a collaborative layer and
I'm not aware of any efforts to remove kernel recipes, etc. for any of
the platforms, but I'd like to free up any hard-and-fast directive
that BeagleBoard.org distros need to be made using BSPs from meta-ti.
While I certainly prefer if the TI SDK distro and BeagleBoard.org
distro used the same BSP to help customers migrate between them,
collaboration seems to be going well at a kernel and bootloader level
without having the same BSP thanks to a focus on upstream
contributions. I believe enabling everyone to work fast and
efficiently on their own distros, the mainline kernels and mainline
bootloaders is more critical than having a common BSP layer at this
point.

Let the flames begin, because I've probably said the wrong thing yet
again, but I'm hopeful something will happen, even though I don't have
a patch of my own here.

>
>>
>> You work for TI, you get to dictate what happens in meta-ti, so
>> make a proposal. I'm only a small part of the community, I have
>> no illusions of being able to influence the direction of meta-ti.
>> I can however look at your proposal and give my opinion on it.

Denys, Chase, patches and statements as to what is and isn't allowed in meta-ti?

>> _______________________________________________
>> meta-ti mailing list
>> meta-ti@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-ti
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti