All, After spending a few years working with a several-years old forked and heavily-modified version of BitBake, my company is looking at switching to using Yocto to build embedded Linux for its printers. I've been playing with/writing tools and process around Yocto for a couple of months now, and I'm getting to the point where I can produce integration builds without a problem.
Now I'm starting to think about how our release process should work with pure Yocto and I'm running into a conundrum. Before I get into that, though, let me very briefly explain how we release code currently in terms of Yocto as it is today. This is not exactly what we do, but if I had to explain the real process, it would take a while because of all the customization we bolted on top of our forked BitBake. Basically, we have a branch in a repository containing the equivalent of local.conf, and we put fixed revisions of every package for that release into the local.conf file within that branch. As patches for a release come in, the local.conf file is updated to point to the new patches. I was thinking about doing something very close to that in actual Yocto, except I'd store only the revisions/branches that were different from what the bb file prescribed in local.conf. I ran that idea by a couple of colleagues separately and they both immediately pointed out a concern: they didn't want to have two different places that could manage the revision of the package, i.e. local.conf and the package bb file. They don't like how that works in the system we have today. Instead, they wanted to branch all the metadata and have people update individual bb files with different revisions as necessary. That leaves only one place to manage the revision: the package bb file. Doing all that branching concerns me (it seems heavier-weight than it needs to be, at the very least), but I can't say specifically why branching the bb files is harmful. If you guys can think of a reason why, let me know. If you think it's reasonable, let me know that too. I'm also starting to think there might be a better way to handle this with Yocto's concept of distros (perhaps have a distro for printer X, and a different one for printer Y, each pointing at versions of code that are good for the respective printer), but my research so far hasn't given me enough information on distros to know if this is a reasonable approach. (I've poked through some of the documentation and the mailing list archives.) So, what do you all do for releasing code? Does anyone have a situation similar to mine? (I can't imagine I'm unique, but maybe I'm more special than I thought.) Even if you don't have a situation like mine, what would you suggest I do for releasing code for our printers? Kind regards, Jerrod
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto