All,
As this mailing list seems to have sparked some debate I thought it may be prudent to dump down what I have been pondering about a new 'full flash' firmware release.
I guess this is the workflow side of things; I am not dwelling on the specifics of the userspace packages just yet but I expect to bump most things up to the latest stable releases of packages (and I hope to have Xfce 4.8 packages to go in as a result of an unrelated side project of mine).
This has no bearing on the hotfix releases that EvilDragon heads up, they should continue on the existing image tree as long as needed until such time as we retire the 'Z' release.
This all needs some refinement and discussion. As it stands it is a brain dump of what I have been working towards and what I am taking about when referring to the .next stuff (or whatever contrived name we want to come up with ;)).
Firmware Image: ---------------------- This is actually a fairly simple one at 1st. Move to tracking the latest mainline org.openembedded.dev tree (done) and using the latest distribution information for Ångström, the 2010.7 based metadata (done).
The hard part is now getting to all working together and adapting our images and recipes to make use of features inside newer OpenEmbedded/Ångström metadata. That is easier said than done however it is territory we all know well enough. There will be loads of fixes, bugs, regressions, upgrades and things that are broken upstream that we will have to contend with, the sooner we get stuck into this and get images out the better.
My plan is to offer the images as tarballs to extract to EXT formatted SD cards (automated daily builds would be idea) just like we did for the 1st release. I'll also try and get the time to include the necessary boot scripts to have u-boot autoload the image if the SD is in the 1st slot so people can just untar and test. I don't want to offer UBIFS NAND images (at least not the wider userbase) until things are pretty close to ready but I will build them alongside the tarballs.
Once we have got things stable enough to start dishing out images I'll also move over all the scant documentation on installing them from the old private wiki to the public ones. Give me a week or so before images start to trickle out from me, I'll keep pushing .next to GIT in the meantime as I go if others want to play along and get stuck into build/testing/patching/being awesome (I rebase .next so remember that if you're tracking it).
As we get close to release we can snapshot the org.openemebedded.dev tree into .next and stop regular pulls. This will form our stable marker and we can cherry pick in any fixes we need from mainline on a case by case basis from that point. For now, I will pull in regularly and push up as much as we can upstream and then capture them when they come back down from the upstream trees.
Kernel: ---------------------- The kernel will always come from the git.openpandora.org kernel tree and it is up to Grazvydas to manage how things trickle up and down from mainline.
For now use the GIT tip of the stable 2.6.27 branch looking to move to the 2.6.37 kernel ASAP.
Start the move to 2.6.37 by offering images with kernels and modules for both kernels included if I can figure a way to cleanly do it. I also need to patch over AUFS2 into the kernel, I will do this the same way as I did it for .27 as a patch that sits with the recipe in the metadata tree.
Grazvydas, I would appreciate your take on this being a good idea or not? We could stay with .27 (or .35) but it seems sensible to move to a very recent kernel and I would love to be able to make use of it in userspace.
Support Bits: ---------------------- This is really all the supporting bits that we produce outside of the main tree but within the scope of the project. libPND, MiniMenu, voodoo mojo grog scripts and the like.
I would like to suggest we continue the process followed during the 1st release for now. It worked well before.
The maintainer for the bit in question just asks for a recipe SRCREV bump when they need their latest binaries rolled into in a test image and we announce the point that we freeze down the image for a release and those SRCREV's either get stuck at that level or better still we switch them to GIT tags and do formal releases of the support stuff alongside the main firmware.
The maintainers of this stuff outside the main OE or Kernel tree are free to carve things up and branch as they see fit provided they make sure the recipes are kept in sync and they don't break the build for the image with unannounced moves ;).
Toolchain: ---------------------- Continue to develop the toolchain scripts based on the work I started with meta-toolchain in OE and try and fix as may host system packaging issues as we can without resorting to hacks or just copy/pasting in files. There is some stuff from Poky/Yocto we may wish to pull in for this but I think it will come into our tree via OpenEmbedded soon enough anyway.
We may also want to tweak things so the root path for the chain can be a little more configurable, I consider that one a low priority nice to have.
The toolchain should also be the same set of binaries used to build the image, if the image is GCC 4.5 SVN blah the toolchain is GCC 4.5 SVN blah etc. etc. - OE makes that pretty easy.
We should also aim to have a toolchain and SDK ready to go with the new firmware (or say release + 2 weeks?). Normal x86 and x64 Linux builds should be fine; we can offer unofficial toolchains for other architectures if there is demand.
Is that enough rambling for one email?
Regards,
John
--
What is a grue?
The grue is a sinister, lurking presence in the dark places of the earth. Its favourite diet is adventurers, but its insatiable appetite is tempered by its fear of light. No grue has ever been seen by the light of day, and few have survived its fearsome jaws to tell the tale.