Firstly, just for reference, the TSC is having some discussions between its members and I'd expect some kind of result from that to be made public soon.
I think its fine to talk about this and form a plan but I would like to see some representation from the board and TSC over this to make it "official". On Tue, 2011-01-25 at 12:05 +0100, Koen Kooi wrote: > Ignoring the timeline a bit, since ideally we would do this around a > yocto milestone to get them to use this straight after their freeze. > > The technical roadmap/todo: > > * setup openembedded-core repo on oe.org > * setup oe-core ml on oe.org > * add oe-core ml to patchwork For these I'd like to confirm that we have sysadmins who are happy that there is capability there for these things and that they have time to work on them. I'm also thinking Yocto would want to mirror oe-core on git.yoctoproject.org. > * import yocto-core in oe-core > * start an integration branch > o remove bitbake > o cleanup namespace (s/yocto/OE/, s/poky/OE/) > o split out superfluous layers (e.g. ememlow) For this I'd like to time it so the changes are in sync with what Yocto is doing. I'm tempted to suggest we preempt this a little and start rearranging Poky now with this in mind? > * start merging in OE things > o e.g. OE gcc 4.5, toolchains for avr32, bfin, etc Last time I talked to Khem the OE gcc 4.5 toolchain didn't boot under Poky's qemu. We have since updated the qemu in Poky but I'd like to actually figure out what was wrong there. Khem couldn't get qemu in Poky to work which is another issue that we need to resolve. I am a little worried about lots of platform specific toolchains merging straight into the core as those might be better as platform/architecture specific layers. > * switch meta-oe to build on top of oe-core, fix issues > > When that is done meta-oe can start to expand. > > The non-technical roadmap/todo: > > * Assign 2 gatekeepers to oe-core, one from yocto, one from OE >From the Yocto side, Saul Wold is the person here. > * sketch out decision tree (RP -> gatekeepers -> maintainers) > * work out model for meta-oe > * appoint OE member to yocto SC > * work out how to marry yocto goals (4 archs, one toolchain) to OE goals > (zillion archs, as much toolchains as we can manage) This is related to my comments above. I would like to see a little pressure to collaborate on one up to date toolchain which means resolving our differences over gcc 4.5 and then handling the architecture specific ones. > * Work out OE roadmap and align with yocto > > The above tries to restrict itself to dealing with the new oe-core, not > with how OE is going to split into layers (meta-oe, meta-graveyard, etc). > It also ignores the maintainer aspects since we will be dealing with > yocto metadata at the start. After oe-core reaches a ready enough state > we can start looking at assigning maintainers, but for the time being > let's get things done first. > > So, let's start fleshing out the above roadmaps and implement them! Sounds like a reasonable plan but see my comments at the start. The time is right to change around the code in poky to make some of the steps easier though and I'm happy to take patches for that now (I'm going to start looking at those changes myself too). This would feed directly into making the above easier. Cheers, Richard _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
