[OE-core] Coordinating inter-layer dependencies

[Martin Jansa]

On Thu, Dec 01, 2011 at 12:23:08PM +0100, Koen Kooi wrote:
> Hi,
> 
> During the past month there have been a number of updates to OE-core recipes that triggered parsing errors due to bbappend in other layers. A small seleciton:
> 
> * netbase
> * libdrm
> * xserver-xorg
> * clutter
> 
> My view is that layer maintainers need to keep an eye on potential breakage and have updates ready when patches land into OE-core. Looking back I can see that while the situation is improving a bit, it's still not working. The problem with slow updates to layers is that (with my angstrom hat on) users (and with my TI hat on) customers and coworkers can't do builds without rm'ing the bbappends or disabling the layer.
> 
> This is bad for a number of reasons:
> 
> 1) It creates unmanaged local diffs
> 2) it can cause PR to fluctuate back and forth if you rm is a bit overzealous or if you disable the complete layer.
> 
> My proposal is that OE-core recipe upgrades with known bbappends look like this:
> 
> 1) add new version with a warning about bbappends
> 2) wait a N days (2 < N < 7)
> 3) delete old version
> 
> To avoid stressing out RP and Sau! I would strongly urge layer maintainers to respond to recipe update patches with "I have a bbappend, but my review process needs time, please use the above proposal" if you need time to test and update  your bbappends.
> 
> We're all human in the end and timezone differences aren't always helping with these kinds of problems, so let's work together to minimize parsing breakage.

That's exactly the reason why I'm using contrib/shr branches and my
setup scripts are updating only from contrib/shr, so I can push changes
to all related branches almost at once and when they are ready.

Sometimes it means extra patches in contrib/shr which are not yet in
master (and sometimes they are on ML already) sometimes it means that
I'm waiting with pulling newer master to shr branch before I prepare
corresponding changes in meta-smartphone (this was the case ie for last
libdrm upgrade). But to test corresponding changes sometimes takes many
hours to even build it...

A while back I've proposed to make .bbappend without corresponding .bb
only big fat warning, but not fatal to parse. Now you cannot even build
eglibc if there is libdrm bbappend you don't care at all about..

Of course if someone ignores big fat warning and build libdrm without
bbappend and then his mesa build is failing, he has to go back and
cleansstate libdrm to build it again properly.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20111201/1454c085/attachment-0002.sig>