[meta-ti] RFC: creating "extras" layer

[Jason Kridner]

On Wed, Jun 20, 2012 at 3:12 AM, Thilo Fromm <fromm at 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 at 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