On Wed, Jun 20, 2012 at 3:12 AM, Thilo Fromm <[email protected]> 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:[email protected] > 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 [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
