Scott gives very good advice below.
I do something very similar with my customers, though I now use the
danny branch of poky on new projects.
I try to minimize the number of layers in a project, ideally just poky
and a custom project layer. Cutomers seem to always need a custom
kernel and boot loader, so I have never needed to use meta-gumstix, I
just include the custom bootloader and kernel recipes in the project
Sometimes a project uses a large number of recipes from
meta-openembedded. In that case I enable just the minimal set of
sub-layers from within meta-openembedded (i.e perhaps meta-systemd &
meta-networking). Having a large number of unused recipes/layers just
slows down the build and increases the chances of some unintended side
If a project uses just a handful of recipes from meta-openembedded I
just copy the needed recipes into the project layer.
Locking things down at that point is good practice! Only make changes
if the project actually needs a bug fix or feature from a new version.
On Fri, Nov 30, 2012 at 6:09 AM, jumpnowdev <scott@...> wrote:
> I think it doesn't matter much what branch or repo you start with.
> Once you run it through your own DEV/QA cycle you need to freeze
> and maintain it yourself.
> What the Gumstix developers do with their repo after that shouldn't
> be relevant. They only provided a starting point that you have now
> verified with your own QA. It's now your responsibility.
> It's the upstream changes by Yocto/OE, linux omap, u-boot, systemd,
> udev, gcc, Qt, etc..., that are more likely to break your product
> anyway, not the high-level recipe commits by Gumstix.
> Those are the projects you need to monitor.
> When working a product, I don't think it's safe to update your repos
> from anyone unless you are ready to take your project through a QA
> phase again.
> That means re-imaging new build workstations from your own internal
> QA'd repo (usually cloud hosted) and ideally maintaining your own
> fixed set of downloaded sources.
> For our customers, we take the kernel and bootloader from Steve Sakoman's
> repos, pinned to commits we've verified for the project. I think this
> is similar to the Gumstix repos.
> We use Poky direct from the Yocto project sticking with the [denzil]
> branch for now.
> Sometimes we use the meta-openembedded layer from openembedded.org.
> After the initial clone, we only pull from these repos when we are
> ready to QA again and, of course, prepared to revert. Git cherry-pick
> We generate a custom layer for the customer with patches and
> customizations to each of the above layers as appropriate.
> We haven't gone this far with any customer, but I guess the next step
> would be to cut off the PROD build workstation from the network, at
> least while it's running bitbake.
> View this message in context: http://gumstix.8.n6.nabble.com/moving-forward-with-meta-gumstix-tp4966199p4966202.html
> Sent from the Gumstix mailing list archive at Nabble.com.
> Keep yourself connected to Go Parallel:
> TUNE You got it built. Now make it sing. Tune shows you how.
> gumstix-users mailing list