On Mon, Feb 13, 2012 at 12:38:47PM +0100, [email protected] wrote: > > On Mon, 13 Feb 2012 10:56:54 +0100, Martin Jansa <[email protected]> > 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 ...).
I see your point, just saying that switching branches back and forth won't work with OE. So it's possible to introduce FSO_CORNUCOPIA_BRANCH and point it to shr but for cost that we won't ever switch back to master (even to test something) without PE bumps and SRCREV updates. > 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? I think we're overthinking this "release". Gnutoo wants kernel downgrade, you're blocked pushing new stuff to master because someone will maybe update some config and need cornucopia SRCREV bump because of that.. I would say, just push it to master and we'll be very carefull with SRCREVs bumps (even for cost of local config patch) for next 14 days or so and then we "release" and bump SRCREV to get new stuff (and 3.2 kernels and systemd and whatever devs are working on). Just my 2c and I wont complain when you still decide to go with shr branch + PE bumps. Cheers, -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
