[meta-ti] Fix image recipes in meta-ti

[Jason Kridner]

On Tue, Sep 4, 2012 at 9:53 AM, Maupin, Chase <chase.maupin at ti.com> wrote:
>> -----Original Message-----
>> From: meta-ti-bounces at yoctoproject.org [mailto:meta-ti-
>> bounces at yoctoproject.org] On Behalf Of Koen Kooi
>> Sent: Sunday, September 02, 2012 4:11 PM
>> To: meta-ti at yoctoproject.org
>> Subject: Re: [meta-ti] Fix image recipes in meta-ti
>>
>>
>> Op 2 sep. 2012, om 21:47 heeft "Maupin, Chase"
>> <chase.maupin at 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 at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-ti
> _______________________________________________
> meta-ti mailing list
> meta-ti at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti