Hi, I'd like to get rid of the linaro_android_4.0.3_snowball/linaro_android_4.0.3_pandaboard/linaro_android_4.0.3_origen/... branches where they aren't absolutely necessary - they tend to cause a lot of extra maintenance work and possible mistakes (committing a fix for a bug affecting everyone only on a board specific branch etc).
I think for frameworks/base, this should do it: http://review.android.git.linaro.org/#change,1321
The code on linaro_android_4.0.3_snowball also takes out the check for ro.nohardwaregfx, but I think that's not actually necessary (simply don't set it if you don't need it...) and removes the definitions of eglGetSystemTimeNV() and friends from eglext.h (shouldn't be necessary, code that tries to use those functions that don't exist on snowball will simply fail to link instead of erroring out on the invocation). linaro_android_4.0.3_pandaboard and linaro_android_4.0.3_origen don't seem to do anything actually needed.
Please take a look at the proposed change and if you think it's not going to work, let me know why ;)
ttyl bero
On 12/28/2011 02:09 AM, Somebody in the thread at some point said:
Hi, I'd like to get rid of the linaro_android_4.0.3_snowball/linaro_android_4.0.3_pandaboard/linaro_android_4.0.3_origen/... branches where they aren't absolutely necessary - they tend to cause a lot of extra maintenance work and possible mistakes (committing a fix for a bug affecting everyone only on a board specific branch etc).
I think for frameworks/base, this should do it: http://review.android.git.linaro.org/#change,1321
The code on linaro_android_4.0.3_snowball also takes out the check for ro.nohardwaregfx, but I think that's not actually necessary (simply don't set it if you don't need it...) and removes the definitions of eglGetSystemTimeNV() and friends from eglext.h (shouldn't be necessary, code that tries to use those functions that don't exist on snowball will simply fail to link instead of erroring out on the invocation). linaro_android_4.0.3_pandaboard and linaro_android_4.0.3_origen don't seem to do anything actually needed.
Please take a look at the proposed change and if you think it's not going to work, let me know why ;)
I think what you're doing will work... but it reminds me a lot of landing team situation where we also need to maintain various flavours of kernels all tracking the same moving basis.
The scheme we use to simplify this involves using rebase trees instead of keeping a history, and then adding a much smaller, more contained per-board series on top of the common basis. That per-board series is easier to maintain because it's just the necessary changes in one place with no history needed; rebasing everything on the common basis is then scriptable easily (we can give you the scripts).
If you don't like the sound of that... what's stopping you issuing a single rootfs with all the pieces in there, and runtime actions selecting what gets a look-in?
-Andy
linaro-android@lists.linaro.org