The layers.openembedded.org is a community driven effort with a large number of useful layers represented on it. Some are regularly tested/updated, but some are not. The layers.yoctoproject.org is aiming to be a curated subset of layers.openembedded.org possibly? with some degree of automated testing. The intention to create some form of setup/fetcher tool similar to or building upon the https://github.com/Wind-River/wr-lx-setup makes having curated layers even more important as the tool will make accessing *any* layer easier so the core project should have curated layers to start from.
adding RP and Jefro
So I've done some thinking about this. I do understand the concerns, they are the same as I had when we originally discussed enabling adding layers from the layer index in Toaster. However, I think creating a separate layer index isn't the right thing to do for several reasons: 1) We'd create confusion about the purpose of each index and which that users should be choosing. People are often confused about what the Yocto Project is vs. what OpenEmbedded is, we should try to avoid adding to that. 2) It doubles our commitment to maintaining the infrastructure (since it's us i.e. mostly Michael H who maintains layers.openembedded.org). If we upgrade the layer index code, which we do need to do from time to time, we'll then need to upgrade two instances rather than just one. 3) Maintenance of the data will need to be done in two places, e.g. if a layer maintainer changes their email address. I'd much rather see us make some practical plans on how we'll arrive at this "curated" set of layers, and then we can have those marked in some way in the OE index such that the user (or a tool querying the index) can filter on that.
Richard and I talked about this and layer quality / testing is just one aspect - there may be other motivating factors to having a YP index, for instance it may be a value proposition of Yocto Project membership and part of the Yocto Project Compatible v2 programme. In any event from a technical perspective we should be able to resolve #3 if we set up the YP index to take its layer data from the OE index and just filter on certain criteria, so any edits would be done in the OE index and they would just flow into the YP one automatically. This is similar to the requirement for internal company indexes which has already come up (see bug 9760) so we have a chance to resolve that at the same time. Hopefully Michael's container setup for the layer index mitigates #2 somewhat, even if it doesn't solve it, but we can probably live with that. That just leaves us with #1, which I still worry about, but we'd just have to explain clearly what the difference is. In some ways it's an extension of YP's focused effort vs the much wider OE - a different view on the same table if you like.
I see this is only further creating confusion. Couldn't we just add flags to the layer index showing compatible status, testing status etc? It would completely suck having to search the layer index to find a recipe, then having to move to another layer index to check compatible and testing status.
Hi all - finally catching up to this Adding a flag to the OE layer index indicating the PASS level from RP's new script is by far the sanest thing to do. It would then be easy to derive a YP-specific layer index. Note that this does not necessarily reflect YP Compatible status, though, as YP Compatible is a branding program, not a technical compatibility program. I can predict issues within the OE community around adding a YP flag to an OE index. However, Philip's blessing goes a long way toward alleviating that. For the YP website we are currently planning to scrub the list of BSPs from the layer index by comparing it to a list of official "YP Compatible" (branding program) BSPs. I'd be happy to work on any initiative on this going forward.
Title was "Create a layers.yoctoproject.org site" but the agreement trend (which I agree with) indicated a need for a better title. Thus, new more appropriate title.
The new title is much better. We should go over this briefly at OEDEM. Likely as part of the YP compliance test.
Here's what we have now for indicating the YP Compatibility: http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/log/?h=abrindle/yp_compatible
Changes have been merged: http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/commit/?id=fdcde0071080a59e1fad17a9479f3d8ca065e8cb