Op 14 jan 2011, om 18:49 heeft Richard Purdie het volgende geschreven: > The vote result showed a strong opinion that Yocto and OE need to find a > way to work together which is something I'm very happy to see. I think > everyone is waiting for each other to make a move so I'm going to put > forward some ideas/discussion to try and start the ball rolling. I'm > filling out ideas here but I want to make it clear this is a straw-man > to discuss. I have given this a lot of thought though as its attention > to many of the details that will determine its success. > > The agreement for OE to take up a seat on the Yocto Steering Group seems > to be progressing and I think that part of things is moving forward well > and the board is handling it. At a technical level we need to have some > discussion though. > > I think the idea in people's minds is to create an "openembedded-core" > which would have a new development structure. There are various aims for > doing this but they include: > > * Formalising processes for making changes > * Creation of a subset of metadata that has a consistent high quality > standard: > - removal of legacy components (pkgconfig hacks, libtool hacks, > legacy staging, unneeded compiler arguments) > - consistent metadata layout, spacing, use of variables > - migration away from outdated practises (e.g. use BBCLASSEXTEND) > * Formalise cycles of development, stabilisation and release > * Ensure a form of standardised basic testing of changes and over time, > extend that testing > > We've talked about doing this at OEDEMs in the past, we keep talking > around the issue, we now have an opportunity to attempt it and to make > it a success. Part of the problem was always manpower to undertake some > of it, Yocto gives us a mechanism to help with that. > > What would we have to do to make that happen? Roughly speaking I think > the steps look like: > > * Agreed to try a new contributions model > * Setup an openembedded-core repo > * Populate that repo with some base data > * Decide where OE core patches would be queued, discussed and processed > * Document the process > * Start using it > * Profit!
I think we can start with the following right now: * setup an oe-core repo * populate that repo What I propose to do in parallel to that: * setup oe-yocto-integration mailinglist * people interesting in *working*[1] on the integration may subscribe * hook that ml up to patchwork as a new project That only leaves: * contributions model discussion * patch processing discussion * documentation * profit > For OE, we've talked about cleaning it out for a long time and I think > meta-openembedded is the solution there with some cleanup happening as > people transition the recipes they use. Apart from the weird pythondir() problem that came up last week, meta-openembedded is working quite well as layer on top of yocto. It would be nice to see more people contribution to it, though. [snip] > One other question also springs to mind which is what is the TSC's remit > in this new contribution mode As we discussed during OEDEM, the TSC needs to go through an election cycle to get some new people on. The current TSC is opaque, non-responsive and out of touch. I'm not sure a new election is going to help fix that, but it's worth a try. > Ultimately, I think the only way we're going to move forward with this > is to actually try something. So lets get started! [1] Lots of people have love to suggest colours for the bikeshed, but few people actually want to do actual painting _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
