Move PELUX BSP layers into this layer, as sub-layers

[jonte]

This ticket is meant to create a discussion around moving the PELUX BSP layers for Raspberry Pi and Intel into the meta-pelux layers.

There are several benefits of doing so:

• It seems to be best practice, when looking at other layers (poky: http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp)
• It will reduce the number of dependencies (meta-pelux no longer needs to depend on meta-pelux-bsp-intel, because this is merged in to the same repo, for instance)
• It will be easier to keep the BSP adaptions and the main layer in sync

Potential drawbacks:

• It is not possible to use the BSP adaptions separately from PELUX (although, is this ever an intended use-case?)
• We will get more traffic in the main git repo (although the BSP layers don't have much traffic currently)

What are your thoughts?

[breakreturn]

My input here is basically that I want to protect a few key use-cases/concerns:

• It should be easy to use PELUX Baseline as a basis for a project, i.e. use of a project specific BSP layer and a project specific "top" layer with images, perhaps distro, etc.
• The BSP layer and other layers might not be worked on by the same teams in a project, e.g. the BSP layer might be delivered into the project and thus have a separate lifecycle and processes etc.
• The Blueprint SWF together with the Baseline Deployment SWF should describe how a project does the above, using PELUX Baseline as a starting point. E.g would we recommend this way of working for projects as well? Would it force a using project with their own BSP to fork the Baseline rather than use it as upstream?

Given that the above is respected, I think the technical implementation is better decided by e.g @jonte, @tobsan, @GordanM, @erikboto for example.

[GordanM]

@jonte, as per our discussion in person, I completely support the merge and removal of the meta-bsp layers as they seem to be more of a burden than help as it currently is. That is my technical understanding. Possibly we can mimic meta-boot2qt's pattern when it comes to including platform specific extras (http://code.qt.io/cgit/yocto/meta-boot2qt.git/tree/). It makes complete sense to me, especially because of the graphics (http://code.qt.io/cgit/yocto/meta-boot2qt.git/tree/meta-intel-extras/recipes/qt5/qtbase_git.bbappend). What do you think?

@breakreturn when it comes to the use-cases you've stated above: I would encourage a meeting to make sure we do not hinder the enabling aspect of PELUX. That is, after all, one of the main purposes of PELUX.

[tobsan]

The only drawback I see with this is that whenever someone builds on top of meta-pelux with a hardware of their own, they will still have to download the existing bsp data. Not sure that is a big problem, because it's not a lot of data anyway.

[GordanM]

@tobsan valid point. They would not have to download all the platform meta layers though, just the meta-platform-extras folder inside meta-pelux and during the configuration you would choose which platform you are targeting and the BSP would be deduced from that. So the overhead would be up to 10 or more .bb, .conf or .bbappend files.

[tobsan]

@GordanM Yeah, that's what I meant when saying that it isn't a lot of data :)

[breakreturn]

@GordanM We can have a meeting if needed, but I'm not sure if we have anything to discuss currently. I'll simply trust that the technical implementation that we end up with supports the use-cases I've listed and that they are included in the analysis.

If we need to clarify the use cases, let me know. And if we end up with design choices that are a compromise and we need to discuss priority, let me know as well.

[tobsan]

I think that since any user of meta-pelux will still be able to apply their own enhancements of the BSPs, this shouldn't be an issue. I'll try this out right away to see if I missed something.