On Mon, 13 Feb 2012 10:56:54 +0100, Martin Jansa <martin.ja...@gmail.com> wrote: > Heyho, > > when we talked about FSO_CORNUCOPIA_BRANCH I thought that you want to > use different branch for all OE builds, it could work also as you have > prepared it, but when switching branch you would need to set different > SRCREVs to every recipe using FSO_CORNUCOPIA_BRANCH which is a bit more > difficult then > FSO_CORNUCOPIA_BRANCH ?= "shr" > in distro.conf > > I guess you're using autorev so it will work for you (using > master+autorev), but for shr branch switch you had to update all SRCREVs > and maybe also bump PEs because branch is part of key to LOCALCOUNT db > :/ and without bump it will start with gitr0+hash and downgrade.
Ok, thanks for the point. Thats something I don't really thought about :) > Thinking about it now.. maybe we can stuck with master and fixed SRCREV > on values we have now for release (so you can push new stuff and it > won't be in release). Is it ok for you? I don't know if that is the right solution. I want to introduce another branch for SHR and cornucopia as cornucopia and all of it's component will evolve in the future but we need a stable and bug free version in SHR and I don't think the master branch is the correct origin for this. We can stick to a stable SRCREV version for the release but bumping cornucopia SRCREV is something that is needed quite often (for example as configuration has changed ...). We can be more strick with SRCREV bumps or start to release the relevant FSO components more often which are the base for SHR then. For example I want to change some dbus API and the relevant changes for this are already in master. SHR now wants to bump SRCREV as configuration for some component has changed. The new SRCREV now takes the API changes to SHR which breaks SHR components and we have our bug. Patches could be a solution here but do we want to have patches in meta-shr or meta-fso until the SHR components are ready to play with the new API? regards, Simon PS: I added shr-devel@lists.shr-project.org to CC as we should really move with our discussions about such topics into the public so people see we're working and not dead :) _______________________________________________ Shr-devel mailing list Shr-devel@lists.shr-project.org http://lists.shr-project.org/mailman/listinfo/shr-devel
