Re: Best way to "freeze" Yocto for production

[Mark Hatle <mark.hatle@windriver.com>]

On 6/10/14, 12:31 PM, Marlon Smith wrote:
> Hi everyone,
>
> We've decided to use Yocto in our company's product!  And I have a question:
>
> Since Yocto is updated pretty frequently, at some point we'll need to freeze
> everything and keep a permanent copy so that we can make small changes/bug fixes
> without having to worry about anything being changed outside of our control.  My
> current theory is that we'll do a bitbake -c fetchall, then zip up the entire
> Yocto directory and save it somewhere so we'll always have a static copy.  We'll

This is really the first step.  Take you Yocto Project sources, and related 
downloads and store them for retrieval later.  You can use the:

    BB_NO_NETWORK = "1"

to ensure that the system will use your local copy and not attempt to go to the 
network for downloads.

> place our application and custom bsp layer under a separate Git repository, and
> then to do a build we'll just combine everything together and run bitbake on the
> whole thing.

This pretty much is the standard way to do it.  If your BSP is based off of 
another git tree, you can enable networking just for that one item if necessary.

> Is there a better or recommended way of doing this?

I think you have the basics down.  When it comes to upgrading and bug fixing, 
this is where doing very management resources come into play.

One way to do it is just track the Yocto Project until your product release. 
This way you get all of the latest fixes for the branch you choose.

Another mechanism (what I'd recommend for after product release, but some do it 
during development) is to watch the changes from your starting location, to the 
current state of development (either in the branch, or even master).  Using this 
information, you can determine if any of the items are fixes that you believe 
your product will require.  Use the git 'cherry-pick' option to pull down only 
the fixes you are interested in.  This dramatically slows the rate-of-change of 
your local tree.

One thing to keep in mind, you will -always- end up with some local fix that 
does not exist upstream.  You should limit these as much as possible.  For a 
single project, it's not all that painful to carry and support your changes, but 
when you start working on the next product, it's nice to be able to start with a 
newer version of the Yocto Project.  If you have a lot of local changes that 
have not gone back to the community, you'll then have to abandon them -- or 
carry them forward.  This can be time consuming, and the usual reaction is to 
stick with the older version to avoid this additional work.

You should always budget the time to get the fixes ready and send them back to 
the community, it will save you (and others) time when getting ready for the 
next project.

> Thanks again, and I'm excited to start working with Yocto!
>
> Marlon
>
>