RFC: creating "extras" layer

RFC: creating "extras" layer

[Denys Dmytriyenko]

Koen, et al,

This is a RFC for creating an additional "extras" layer inside meta-ti to 
contain pieces and components that are either slightly outdated (i.e. old 
Davinci boards, hawk/crane etc.) or have best-effort status (TI81x, anything 
DSP-related, etc.) or require non-standard dependencies besides OE-Core 
(systemd?) with the possibility of moving them back to "main" meta-ti in the 
future, once they become "first-class citizens", i.e. gain current and 
continuing support.

The initial split (which is still "work in progress"), following the above 
description (except the systemd for now) can be checked at:

http://arago-project.org/git/?p=meta-ti.git;a=shortlog;h=refs/heads/split

I do understand this is, like any other restructuring, an invasive change, but 
is required to properly position "meta-ti" and the support behind it. I'm open 
to a discussion and any constructive criticism - feel free to comment. Thanks.

-- 
Denys

Re: RFC: creating "extras" layer

[Maupin, Chase]

Sounds like a good plan

Sincerely,
Chase Maupin
On Jun 11, 2012, at 3:17 PM, "Denys Dmytriyenko" <denis@denix.org> wrote:

> Koen, et al,
> 
> This is a RFC for creating an additional "extras" layer inside meta-ti to 
> contain pieces and components that are either slightly outdated (i.e. old 
> Davinci boards, hawk/crane etc.) or have best-effort status (TI81x, anything 
> DSP-related, etc.) or require non-standard dependencies besides OE-Core 
> (systemd?) with the possibility of moving them back to "main" meta-ti in the 
> future, once they become "first-class citizens", i.e. gain current and 
> continuing support.
> 
> The initial split (which is still "work in progress"), following the above 
> description (except the systemd for now) can be checked at:
> 
> http://arago-project.org/git/?p=meta-ti.git;a=shortlog;h=refs/heads/split
> 
> I do understand this is, like any other restructuring, an invasive change, but 
> is required to properly position "meta-ti" and the support behind it. I'm open 
> to a discussion and any constructive criticism - feel free to comment. Thanks.
> 
> -- 
> Denys
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: RFC: creating "extras" layer

[William Mills]

On 06/11/2012 09:17 PM, Denys Dmytriyenko wrote:
> The initial split (which is still "work in progress"), following the above
> description (except the systemd for now) can be checked at:
>
> http://arago-project.org/git/?p=meta-ti.git;a=shortlog;h=refs/heads/split

I'm glad to see this work going.

I was surprised to see that the extra layer was embedded into the 
existing one.  Is that right?

When we talked before we spoke of two layers at the top level.

Re: RFC: creating "extras" layer

[Denys Dmytriyenko]

On Tue, Jun 12, 2012 at 09:10:33AM -0400, William Mills wrote:
> On 06/11/2012 09:17 PM, Denys Dmytriyenko wrote:
> >The initial split (which is still "work in progress"), following the above
> >description (except the systemd for now) can be checked at:
> >
> >http://arago-project.org/git/?p=meta-ti.git;a=shortlog;h=refs/heads/split
> 
> I'm glad to see this work going.
> 
> I was surprised to see that the extra layer was embedded into the
> existing one.  Is that right?
> 
> When we talked before we spoke of two layers at the top level.

It should work fine. Making both of them at the top level kind of implies you 
can use one or another. Since extras is always dependent on the main layer, it 
makes sense to embed it in. Plus this way it's less namespace polluting...

-- 
Denys

Re: RFC: creating "extras" layer

[Koen Kooi]

Op 11 jun. 2012, om 20:17 heeft Denys Dmytriyenko het volgende geschreven:

> Koen, et al,
> 
> This is a RFC for creating an additional "extras" layer inside meta-ti to 
> contain pieces and components that are either slightly outdated (i.e. old 
> Davinci boards, hawk/crane etc.) or have best-effort status (TI81x, anything 
> DSP-related, etc.) or require non-standard dependencies besides OE-Core 
> (systemd?) with the possibility of moving them back to "main" meta-ti in the 
> future, once they become "first-class citizens", i.e. gain current and 
> continuing support.

If it's going to be split this way I'd like to move all beagleboard.org related things out of meta-ti and into it's own seperate repo. If the beagle recipes are demoted to 2nd class citizens we have no incentive anymore to be in meta-ti.

Re: RFC: creating "extras" layer

[William Mills]

On 06/12/2012 09:44 AM, Koen Kooi wrote:
>
> Op 11 jun. 2012, om 20:17 heeft Denys Dmytriyenko het volgende geschreven:
>
>> Koen, et al,
>>
>> This is a RFC for creating an additional "extras" layer inside meta-ti to
>> contain pieces and components that are either slightly outdated (i.e. old
>> Davinci boards, hawk/crane etc.) or have best-effort status (TI81x, anything
>> DSP-related, etc.) or require non-standard dependencies besides OE-Core
>> (systemd?) with the possibility of moving them back to "main" meta-ti in the
>> future, once they become "first-class citizens", i.e. gain current and
>> continuing support.
>

> If it's going to be split this way I'd like to move all beagleboard.org related things out of meta-ti and into it's own seperate repo.

We should do whatever makes the most sense and serves all the user's 
use-cases.  Angstrom beagleboard is an important use case but so is 
oe-core only on beagleboard and AM335x etc.  We also need people to 
understand what things are being built and tested every night vs 
something that was pretty much working when it was tried 6 months ago.

> If the beagle recipes are demoted to 2nd class citizens we have no incentive anymore to be in meta-ti.

I thought it was just the older beagleboard stuff that was moving?  Or 
are you complaining that not every feature of your current builds are 
available using just oe-core?

It is true that we are trying to do two things here:
1) separate things that require layers beyond oe-core
2) separate things that are not tested and supported to the same level

It was your assertion that we did not want too many layers. 
Unfortunately that means things that require layers beyond oe-core need 
to be in the second layer.  Sorry if you see that as being a second 
class citizen.

There are large parts of beagleboard and beaglebone that do work with 
only oe-core and are built and tested regularly.  Finding the right 
place for these pieces should, I think, be the focus of the discussion.

As I have said before, If you want a seperate layer/repo to support the 
specifics of Angstrom beagleboard/beaglebone _I_ think that would be fine.


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

Re: RFC: creating "extras" layer

[Koen Kooi]

Op 12 jun. 2012, om 09:22 heeft William Mills het volgende geschreven:

> On 06/12/2012 09:44 AM, Koen Kooi wrote:
>> 
>> Op 11 jun. 2012, om 20:17 heeft Denys Dmytriyenko het volgende geschreven:
>> 
>>> Koen, et al,
>>> 
>>> This is a RFC for creating an additional "extras" layer inside meta-ti to
>>> contain pieces and components that are either slightly outdated (i.e. old
>>> Davinci boards, hawk/crane etc.) or have best-effort status (TI81x, anything
>>> DSP-related, etc.) or require non-standard dependencies besides OE-Core
>>> (systemd?) with the possibility of moving them back to "main" meta-ti in the
>>> future, once they become "first-class citizens", i.e. gain current and
>>> continuing support.
>> 
> 
>> If it's going to be split this way I'd like to move all beagleboard.org related things out of meta-ti and into it's own seperate repo.
> 
> We should do whatever makes the most sense and serves all the user's use-cases.  Angstrom beagleboard is an important use case but so is oe-core only on beagleboard and AM335x etc.  We also need people to understand what things are being built and tested every night vs something that was pretty much working when it was tried 6 months ago.
> 
>> If the beagle recipes are demoted to 2nd class citizens we have no incentive anymore to be in meta-ti.
> 
> I thought it was just the older beagleboard stuff that was moving?  Or are you complaining that not every feature of your current builds are available using just oe-core?

I don't have *any* builds that do what they need to do with only oe-core + meta-ti. Till that changes I lack any form of incentive to actively work on oe-core only efforts. I'm not saying that to be mean, just to make my position really clear. 

> It is true that we are trying to do two things here:
> 1) separate things that require layers beyond oe-core
> 2) separate things that are not tested and supported to the same level
> 
> It was your assertion that we did not want too many layers. Unfortunately that means things that require layers beyond oe-core need to be in the second layer.  Sorry if you see that as being a second class citizen.
> 
> There are large parts of beagleboard and beaglebone that do work with only oe-core and are built and tested regularly.  Finding the right place for these pieces should, I think, be the focus of the discussion.
> 
> As I have said before, If you want a seperate layer/repo to support the specifics of Angstrom beagleboard/beaglebone _I_ think that would be fine.

No, in such a scenario I would want all the beagleboard.org stuff removed from meta-ti and have only *one* repo/layer with beagle stuff in it. Doing a split like you say will involve too much extra work to be worth the time and effort. Especially if the 'extras' layer will include all the bitrotted stuff as well.

From a beagleboard.org perspective an oe-core only build is useless at this moment[1], the non-core bits are the ones that make the experience great. I do see that meta-ti needs to support an oe-core only option for their officially supported machines. Since the beagleboard.org boards are not supported by TI it makes sense to move them out and have the beagle layer depend on meta-ti for things like dsp and 3d support.

regards,

Koen

[1] Which of course can change in the future when oe-core gets reworked e.g. move systemd there.

Re: RFC: creating "extras" layer

[Denys Dmytriyenko]

On Tue, Jun 12, 2012 at 08:44:59AM -0500, Koen Kooi wrote:
> 
> Op 11 jun. 2012, om 20:17 heeft Denys Dmytriyenko het volgende geschreven:
> 
> > Koen, et al,
> > 
> > This is a RFC for creating an additional "extras" layer inside meta-ti to 
> > contain pieces and components that are either slightly outdated (i.e. old 
> > Davinci boards, hawk/crane etc.) or have best-effort status (TI81x, anything 
> > DSP-related, etc.) or require non-standard dependencies besides OE-Core 
> > (systemd?) with the possibility of moving them back to "main" meta-ti in the 
> > future, once they become "first-class citizens", i.e. gain current and 
> > continuing support.
> 
> If it's going to be split this way I'd like to move all beagleboard.org 
> related things out of meta-ti and into it's own seperate repo. If the beagle 
> recipes are demoted to 2nd class citizens we have no incentive anymore to be 
> in meta-ti.

Disclaimer: no beagles were harmed in the making of this film...

Seriously though, none of the beagle recipes (requiring systemd or not) were 
moved yet for several reasons:

1. As done with some other recipes, it's possible to have systemd services w/o 
inheriting systemd.bbclass, i.e. do it manually - I was planning on looking 
into this option in the near future.

2. There was a recent discussion about systemd work being started in OE-Core 
and it was confirmed on today's call that the new Intel team in Romania is 
gearing up to integrate systemd into OE-Core in the very near future.

3. And, of course, a separate systemd layer in meta-oe might help, if done 
properly and allowing easily target both systemd and sysvinit from the same 
recipe...

Anyway, it is not my intention to demote beagle support to 2nd class citizens. 
After all, beagles are the most supported platforms in meta-ti right now and a 
very good example for other platforms to follow...

I hope you are not just looking for any excuse to move out of meta-ti - we 
just need to work on a better positioning of meta-ti...

-- 
Denys

Re: RFC: creating "extras" layer

[Enrico]

On Tue, Jun 12, 2012 at 3:17 AM, Denys Dmytriyenko <denis@denix.org> wrote:
> ....
> with the possibility of moving them back to "main" meta-ti in the
> future, once they become "first-class citizens", i.e. gain current and
> continuing support.

What's the official TI plan for this? I mean:

- what platforms is TI going to support? what platforms is TI going to
keep current?

- are there any plans to keep support for the dsp-related things?

I imported and fixed the dsp-related things from oe-classic, and Koen
was the only one that helped me.

I posted some patches for gst-ducati for omap4, with help from Koen
and Rob Clark, and nobody cared.

I know the concept of "opensource" and "community" but  it seems to me
that TI has no interest in all of this, just look at the current
platform support after the extras split.

The point is that you will not stop people complaining (like Steffen
some days ago) just saying: "oh it's in extras you are lucky if it
builds".

So the question is: are there any plans in TI to properly support its
platforms or will this continue to be a place where to drop some code,
forget about it and then move it to an extra layer?

Enrico

Re: RFC: creating "extras" layer

[Steffen Sledz]

On 13.06.2012 16:15, Enrico wrote:
> On Tue, Jun 12, 2012 at 3:17 AM, Denys Dmytriyenko <denis@denix.org> wrote:
>> ....
>> with the possibility of moving them back to "main" meta-ti in the
>> future, once they become "first-class citizens", i.e. gain current and
>> continuing support.
> 
> What's the official TI plan for this? I mean:
> 
> - what platforms is TI going to support? what platforms is TI going to
> keep current?
> 
> - are there any plans to keep support for the dsp-related things?
> 
> I imported and fixed the dsp-related things from oe-classic, and Koen
> was the only one that helped me.
> 
> I posted some patches for gst-ducati for omap4, with help from Koen
> and Rob Clark, and nobody cared.
> 
> I know the concept of "opensource" and "community" but  it seems to me
> that TI has no interest in all of this, just look at the current
> platform support after the extras split.
> 
> The point is that you will not stop people complaining (like Steffen
> some days ago) just saying: "oh it's in extras you are lucky if it
> builds".
> 
> So the question is: are there any plans in TI to properly support its
> platforms or will this continue to be a place where to drop some code,
> forget about it and then move it to an extra layer?

It's really a great pity that there is no (official) response from TI to this . :(

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: RFC: creating "extras" layer

[Jason Kridner]

On Fri, Jun 15, 2012 at 2:58 AM, Steffen Sledz <sledz@dresearch-fe.de> wrote:
> On 13.06.2012 16:15, Enrico wrote:
>> On Tue, Jun 12, 2012 at 3:17 AM, Denys Dmytriyenko <denis@denix.org> wrote:
>>> ....
>>> with the possibility of moving them back to "main" meta-ti in the
>>> future, once they become "first-class citizens", i.e. gain current and
>>> continuing support.
>>
>> What's the official TI plan for this? I mean:
>>
>> - what platforms is TI going to support? what platforms is TI going to
>> keep current?

BeagleBoard-xM and BeagleBone have support in the TI Linux SDK, are
getting patches applied in the mainline Linux kernel by TI developers
and will continue to be refreshed.  I'm sure other TI platforms may be
supported and given refreshes, but I'm only aware of the
BeagleBoard-related activities.

>>
>> - are there any plans to keep support for the dsp-related things?

The staffing on this is minimal, but there will be some refreshes in
the future.  Investment continues and can be clearly noted with things
like the availability of linux on C6000 in the mainline kernel now,
along with the requisite C6000 support in GCC.  I have some activities
planned for later this year to improve the DSP and M3/PRU
communications, but there are some more urgent issues to fix in the
mainline kernel relative to the processors on BeagleBoard,
BeagleBoard-xM and BeagleBone currently.

>>
>> I imported and fixed the dsp-related things from oe-classic, and Koen
>> was the only one that helped me.

Koen has been sponsored by TI in the past.

>>
>> I posted some patches for gst-ducati for omap4, with help from Koen
>> and Rob Clark, and nobody cared.

Rob Clark is a TI employee.  I appreciate your contributions.

>>
>> I know the concept of "opensource" and "community" but  it seems to me
>> that TI has no interest in all of this, just look at the current
>> platform support after the extras split.

Can we please stick to discussing where we can help, rather than
motivation?  I'm 100% confident that there is interest at TI for
supporting open source and community developers.  It isn't always at
the level I'd like, but it continues to grow overall and I think we
are being very open in this process.

>>
>> The point is that you will not stop people complaining (like Steffen
>> some days ago) just saying: "oh it's in extras you are lucky if it
>> builds".
>>
>> So the question is: are there any plans in TI to properly support its
>> platforms or will this continue to be a place where to drop some code,
>> forget about it and then move it to an extra layer?
>
> It's really a great pity that there is no (official) response from TI to this . :(

TI has official support for BeagleBoard-xM and BeagleBone in Arago
(currently based on OE Classic).  I feel, however, that we aren't
doing enough to collaborate with community developers on these vendor
kernels/BSPs, though we are starting to catch our stride on upstream
contributions (TI is now the #2 semiconductor contributor to the Linux
kernel per [1]).

Work will start in earnest in the next month to move this support to
meta-ti.  The current proposal seems to be an attempt to clear-up
responsibility and organization ahead of that effort.

[1] http://www.remword.com/kps_result/3.4_whole.html

>
> --
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: RFC: creating "extras" layer

[Steffen Sledz]

On 20.06.2012 06:37, Jason Kridner wrote:
> On Fri, Jun 15, 2012 at 2:58 AM, Steffen Sledz <sledz@dresearch-fe.de> wrote:
>> On 13.06.2012 16:15, Enrico wrote:
>>> ...
>>> So the question is: are there any plans in TI to properly support its
>>> platforms or will this continue to be a place where to drop some code,
>>> forget about it and then move it to an extra layer?
>>
>> It's really a great pity that there is no (official) response from TI to this . :(
> 
> TI has official support for BeagleBoard-xM and BeagleBone in Arago
> (currently based on OE Classic).  I feel, however, that we aren't
> doing enough to collaborate with community developers on these vendor
> kernels/BSPs, though we are starting to catch our stride on upstream
> contributions (TI is now the #2 semiconductor contributor to the Linux
> kernel per [1]).
> 
> Work will start in earnest in the next month to move this support to
> meta-ti.  The current proposal seems to be an attempt to clear-up
> responsibility and organization ahead of that effort.
> 
> [1] http://www.remword.com/kps_result/3.4_whole.html

Hi Jason,

thanx for this answer. Just a short question? I can't see if this is your personal view or an official TI statement?

Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: RFC: creating "extras" layer

[Jason Kridner]

On Wed, Jun 20, 2012 at 2:59 AM, Steffen Sledz <sledz@dresearch-fe.de> wrote:
> On 20.06.2012 06:37, Jason Kridner wrote:
>> On Fri, Jun 15, 2012 at 2:58 AM, Steffen Sledz <sledz@dresearch-fe.de> wrote:
>>> On 13.06.2012 16:15, Enrico wrote:
>>>> ...
>>>> So the question is: are there any plans in TI to properly support its
>>>> platforms or will this continue to be a place where to drop some code,
>>>> forget about it and then move it to an extra layer?
>>>
>>> It's really a great pity that there is no (official) response from TI to this . :(
>>
>> TI has official support for BeagleBoard-xM and BeagleBone in Arago
>> (currently based on OE Classic).  I feel, however, that we aren't
>> doing enough to collaborate with community developers on these vendor
>> kernels/BSPs, though we are starting to catch our stride on upstream
>> contributions (TI is now the #2 semiconductor contributor to the Linux
>> kernel per [1]).
>>
>> Work will start in earnest in the next month to move this support to
>> meta-ti.  The current proposal seems to be an attempt to clear-up
>> responsibility and organization ahead of that effort.
>>
>> [1] http://www.remword.com/kps_result/3.4_whole.html
>
> Hi Jason,
>
> thanx for this answer. Just a short question? I can't see if this is your personal view or an official TI statement?

It is my personal view based on knowledge of Sitara Linux SDK product
development plans.  Take a look at [2] for information on
collaboration with TI on SDKs and for BeagleBoard-xM and BeagleBone
support.

[2] http://processors.wiki.ti.com/index.php/Sitara_Linux_Software_Developer%E2%80%99s_Guide

[This time hitting the reply-all button]

>
> Steffen
>
> --
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058

Re: RFC: creating "extras" layer

[Thilo Fromm]

Hello Denys,

> This is a RFC for creating an additional "extras" layer inside meta-ti to
> contain pieces and components that are either slightly outdated (i.e. old
> Davinci boards, hawk/crane etc.) or have best-effort status (TI81x, anything
> DSP-related, etc.) or require non-standard dependencies besides OE-Core
> (systemd?) with the possibility of moving them back to "main" meta-ti in the
> future, once they become "first-class citizens", i.e. gain current and
> continuing support.

Denys, did you just imply that ti81x has no current and continuing
support? I'm just curious because our TI field application engineer
keeps telling us that it is fully supported and will receive a kernel
update soon.

Can you please go into detail on what platforms will be supported in the future?

> The initial split (which is still "work in progress"), following the above
> description (except the systemd for now) can be checked at:
>
> http://arago-project.org/git/?p=meta-ti.git;a=shortlog;h=refs/heads/split
>
> I do understand this is, like any other restructuring, an invasive change, but
> is required to properly position "meta-ti" and the support behind it. I'm open
> to a discussion and any constructive criticism - feel free to comment. Thanks.

From a platform perspective your split makes a lot of sense imho.
Especially if there is no active maintenance (let alone development)
for the "extras" platforms. The euphemistic choice of naming puzzles
me, though. I take it that by "extras" you actually mean "deprecated"
or "unmaintained"? If so then please consider naming it that way.
"extras" really suggests some added sugar to the "core" recipes of
meta-ti, which doesn't really coin what you intend to do with it. If
you need to be euphemistic please at least choose a name in the right
context, like something along the lines of "attic", or "basement".

Regards,
Thilo

-- 
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Architect
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515 932 228   mailto:fromm@dresearch-fe.de
Fax: +49 (30) 515 932 77    http://www.dresearch.de
Amtsgericht: Berlin Charlottenburg, HRB 130120 B
Ust.-IDNr. DE273952058
Geschäftsführer: Dr. M. Weber, W. Mögle

Re: RFC: creating "extras" layer

[Jason Kridner]

On Tue, Jun 19, 2012 at 9:31 AM, Thilo Fromm <fromm@dresearch-fe.de> wrote:
> Hello Denys,
>
>> This is a RFC for creating an additional "extras" layer inside meta-ti to
>> contain pieces and components that are either slightly outdated (i.e. old
>> Davinci boards, hawk/crane etc.) or have best-effort status (TI81x, anything
>> DSP-related, etc.) or require non-standard dependencies besides OE-Core
>> (systemd?) with the possibility of moving them back to "main" meta-ti in the
>> future, once they become "first-class citizens", i.e. gain current and
>> continuing support.
>
> Denys, did you just imply that ti81x has no current and continuing
> support? I'm just curious because our TI field application engineer
> keeps telling us that it is fully supported and will receive a kernel
> update soon.
>
> Can you please go into detail on what platforms will be supported in the future?
>
>> The initial split (which is still "work in progress"), following the above
>> description (except the systemd for now) can be checked at:
>>
>> http://arago-project.org/git/?p=meta-ti.git;a=shortlog;h=refs/heads/split
>>
>> I do understand this is, like any other restructuring, an invasive change, but
>> is required to properly position "meta-ti" and the support behind it. I'm open
>> to a discussion and any constructive criticism - feel free to comment. Thanks.
>
> From a platform perspective your split makes a lot of sense imho.
> Especially if there is no active maintenance (let alone development)
> for the "extras" platforms. The euphemistic choice of naming puzzles
> me, though. I take it that by "extras" you actually mean "deprecated"
> or "unmaintained"? If so then please consider naming it that way.
> "extras" really suggests some added sugar to the "core" recipes of
> meta-ti, which doesn't really coin what you intend to do with it. If
> you need to be euphemistic please at least choose a name in the right
> context, like something along the lines of "attic", or "basement".

I believe this interpretation is a good reason not to make this split
at this time.  While I appreciate that some platforms will have more
resources given to updates at various times than others, I don't
believe this split generates an easy-to-grok understanding of the
platform status.  I'd suggest providing links to automated test
reports and something akin to a MAINTAINERS file for a better
indication of platform/recipe status/ownership.

>
> Regards,
> Thilo
>
> --
> Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Architect
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
> Tel: +49 (30) 515 932 228   mailto:fromm@dresearch-fe.de
> Fax: +49 (30) 515 932 77    http://www.dresearch.de
> Amtsgericht: Berlin Charlottenburg, HRB 130120 B
> Ust.-IDNr. DE273952058
> Geschäftsführer: Dr. M. Weber, W. Mögle
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: RFC: creating "extras" layer

[Thilo Fromm]

Hello Jason,

>> From a platform perspective your split makes a lot of sense imho.
>> Especially if there is no active maintenance (let alone development)
>> for the "extras" platforms. The euphemistic choice of naming puzzles
>> me, though. I take it that by "extras" you actually mean "deprecated"
>> or "unmaintained"? If so then please consider naming it that way.
>> "extras" really suggests some added sugar to the "core" recipes of
>> meta-ti, which doesn't really coin what you intend to do with it. If
>> you need to be euphemistic please at least choose a name in the right
>> context, like something along the lines of "attic", or "basement".
>
> I believe this interpretation is a good reason not to make this split
> at this time.  While I appreciate that some platforms will have more
> resources given to updates at various times than others, I don't
> believe this split generates an easy-to-grok understanding of the
> platform status.  I'd suggest providing links to automated test
> reports and something akin to a MAINTAINERS file for a better
> indication of platform/recipe status/ownership.

I feel this would obfuscate the state of support for different TI
platforms even further. Denys made a technological decision which
makes sense. Your arguments against the split are more likely to be
driven by marketing. Not separating the platforms even now when we
have statements about which platform will receive support in the
future and which would not really does not help transparency. Finding
platform support recipes within a "meta-deprecated/" sub-layer is way
more telling than having a note way down a README or a MAINTAINERS
file.

As Denys noted, every platform which is supported can be moved out of
the new meta-layer and back into its original place anytime. If you
don't like a platform being in "extras/" (or, better,
"meta-deprecated/"), just start supporting it.

Regards,
Thilo

-- 
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Architect
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515 932 228   mailto:fromm@dresearch-fe.de
Fax: +49 (30) 515 932 77    http://www.dresearch.de
Amtsgericht: Berlin Charlottenburg, HRB 130120 B
Ust.-IDNr. DE273952058
Geschäftsführer: Dr. M. Weber, W. Mögle

Re: RFC: creating "extras" layer

[Jason Kridner]

On Wed, Jun 20, 2012 at 3:12 AM, Thilo Fromm <fromm@dresearch-fe.de> wrote:
> Hello Jason,
>
>>> From a platform perspective your split makes a lot of sense imho.
>>> Especially if there is no active maintenance (let alone development)
>>> for the "extras" platforms. The euphemistic choice of naming puzzles
>>> me, though. I take it that by "extras" you actually mean "deprecated"
>>> or "unmaintained"? If so then please consider naming it that way.
>>> "extras" really suggests some added sugar to the "core" recipes of
>>> meta-ti, which doesn't really coin what you intend to do with it. If
>>> you need to be euphemistic please at least choose a name in the right
>>> context, like something along the lines of "attic", or "basement".
>>
>> I believe this interpretation is a good reason not to make this split
>> at this time.  While I appreciate that some platforms will have more
>> resources given to updates at various times than others, I don't
>> believe this split generates an easy-to-grok understanding of the
>> platform status.  I'd suggest providing links to automated test
>> reports and something akin to a MAINTAINERS file for a better
>> indication of platform/recipe status/ownership.
>
> I feel this would obfuscate the state of support for different TI
> platforms even further. Denys made a technological decision which
> makes sense. Your arguments against the split are more likely to be
> driven by marketing. Not separating the platforms even now when we
> have statements about which platform will receive support in the
> future and which would not really does not help transparency. Finding
> platform support recipes within a "meta-deprecated/" sub-layer is way
> more telling than having a note way down a README or a MAINTAINERS
> file.
>
> As Denys noted, every platform which is supported can be moved out of
> the new meta-layer and back into its original place anytime. If you
> don't like a platform being in "extras/" (or, better,
> "meta-deprecated/"), just start supporting it.

I agree in principal that clearly annotating recipes without support
is critical to avoid wasting the time of developers.  My concerns
include:
* Patch churn moving recipes in-and-out of the extras layer
* Duplication of recipes between the main layer and the extras layer
* Conflict between BSP components
* Recipes in the main layer that are no better supported that recipes
in the extras layer

The way I see it is that Denys, with the full support of TI, has
ultimate responsibility for support of all of meta-ti and should hold
myself and others both inside and outside of TI individually
responsible to support our contributions.  If he feels that these
sections are not up to his standards to be able to support in the main
layer, then I regretfully acknowledge and respect his decision.  It is
simply my opinion that he should seek other methods to hold the
developers accountable for the quality of these components, rather
than push them out.  He's most aware of his ability to assert such
control over the quality of that code.

It wasn't my intention that a MAINTAINERS file was a method for
identifying poor-quality code, but rather to enable Denys to hold
individuals accountable.  Further, it wasn't my intention that
publishing of test results would be used as a perpetual excuse for not
fixing issues, but rather to highlight them to help focus the
maintainers on what issues to solve and give Denys the tools he needs
to identify code that should be pushed out such that meta-ti can be of
consistently good quality, especially around the time of Yocto-related
snapshots.

>
> Regards,
> Thilo
>
> --
> Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Architect
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
> Tel: +49 (30) 515 932 228   mailto:fromm@dresearch-fe.de
> Fax: +49 (30) 515 932 77    http://www.dresearch.de
> Amtsgericht: Berlin Charlottenburg, HRB 130120 B
> Ust.-IDNr. DE273952058
> Geschäftsführer: Dr. M. Weber, W. Mögle