Re: [Gumstix-users] moving forward with meta-gumstix

[jumpnowdev <sc...@ju...>]

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
works.

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.