[OE-core] OE-Core Release Status

[Richard Purdie]

On Fri, 2012-09-28 at 20:02 +0200, Martin Jansa wrote:
> On Thu, Sep 27, 2012 at 10:42:46PM +0100, Richard Purdie wrote:
> > We're now at -rc2 for the October release of OE-Core. I've noticed a
> > sudden surge of patches on the list, several of which are things like
> > version increments which are no longer really appropriate at this point
> > in the release cycle.
> > 
> > Why haven't we branched?
> > 
> > The plus side of branching now would be continued patches into master.
> > The downside is that QA and autobuilder resources are concentrating on
> > release and hence not on ensuring regressions are being added. I also
> > really need my energy focused on the release rather than reviewing other
> > code. I'm out of bandwidth so I'm putting off branching.
> > 
> > There is also the risk that if we branch, people will continue with
> > master development and ignore the release branch and I'd like to apply a
> > little pressure against this.
> > 
> > So if patches are getting ignored its likely they've been deemed not
> > suited to the state of the tree right now. I may start to queue things
> > on master-next but no guarantees and I would ask people to try and help
> > make the release a good one.
> > 
> > If there are patches being ignored you think do qualify for -rcX, please
> > ping me as it is hard to keep track of everything.
> 
> I don't know what to do with tune* and qt patchset.
> 
> This one is not important, but if you like the idea then it would be
> better to get it in this release already:
> [PATCH] kernel.bbclass: include PE in KERNEL_IMAGE_BASE_NAME

The trouble is this close to release, this will likely break the
autobuilder or qemu scripts or something like that. We can't just rename
output like that without quite a bit of checking :(.

> And I have 2 patches to remove time dependent variables from images
> which I haven't sent to ML yet, because still testing if it has some bad
> sideeffect and if it's enough to resolve the issue I was seeing.
> I'll send them as RFC.
> 
> commit 9c65f68dc380be34f06c4677d6867bbb874a75d1
> Author: Martin Jansa <Martin.Jansa at gmail.com>
> Date:   Wed Sep 26 15:56:05 2012 +0200
> 
>     bitbake.conf: exclude DATETIME var dependency from IMAGE_NAME
>     
>     * resolves ERROR shown when bitbake -S is used for image:
>       ERROR: Bitbake's cached basehash does not match the one we just generated
>       (/OE/oe-core/openembedded-core/meta/recipes-core/images/core-image-minimal.bb.do_rootfs)!
>       ERROR: The mismatched hashes were 8c35cdf8a5d09c03941f081dd9f6d8dc and b5d6e2e5952770557c48c5779ddb73fc
>     
>     Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>

Hmm, that might be ok...

> commit 7173532f91a755911e4822a103c98e7b81b18cb6
> Author: Martin Jansa <Martin.Jansa at gmail.com>
> Date:   Wed Sep 26 00:57:21 2012 +0200
> 
>     rootfs_*.bbclass: exclude BUILDNAME var dependency from do_rootfs
>     
>     * I have kernel recipe which depends on other recipe to build tiny initramfs
>       image, without this change it rebuilds not only that initramfs image
>       but also whole kernel when DATE or TIME is changed and OEBasicHash enabled
>     * also resolves ERROR shown when bitbake -S is used for image:
>       ERROR: Bitbake's cached basehash does not match the one we just generated
>       (/OE/oe-core/openembedded-core/meta/recipes-core/images/core-image-minimal.bb.do_rootfs)!
>       ERROR: The mismatched hashes were 8c35cdf8a5d09c03941f081dd9f6d8dc and b5d6e2e5952770557c48c5779ddb73fc
>     
>     Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>

Doesn't the above fix obsolete this one?

Cheers,

Richard