2011/1/19 Graeme Gregory <[email protected]>: > On 19/01/2011 15:33, Frans Meulenbroeks wrote: >> 2011/1/19 Graeme Gregory <[email protected]>: >>> Hi, this email is sent as an ordinary member of OE. >>> >>> It seems to be on a technical level we are agreed that we should split >>> parts of OE out into the so called openembedded-core which will have a >>> stricter commit access and higher QA requirements on changes. >>> >>> I therefore think it is time to actually create the repository and let >>> the people who are interested in merging the good stuff from poky with >>> the good stuff from openembedded to create our "core". I don't think >>> there is any need to wait on the political part of the Yocto/OE >>> collaboration as its something we have agreed in principal to do anyway. >>> >>> I would request then that the TSC drive this forward with the server >>> admins and create this repo so work can happen. >>> >>> Graeme >> Graeme, >> >> Seems a fine plan to me. >> Do we already have an idea what would be the starting base? >> And do we already have an idea on the QA requirements we want to impose on >> this? >> Lastly we might try to define some common understanding what is core >> and what not. >> >> I did some experiments with poky and found that some of the recipes I >> needed were missing; some of them might perhaps become part of core >> (e.g. i2ctools, squashfstools, libftdi, fastcgi), whereas others are >> quite unlikely to end up in core (e.g. urjtag). For the latter we must >> find another home (e.g. meta-openembedded), where hopefully we can >> also raise the QA bar somewhat. >> >> I'll happily contribute to raise the quality bar. However, if the goal >> is shuffling recipes without significant QA improvement or if QA >> improvement is optional, I'll probably pass. >> > > Well I would hope that openembedded-core has a pull model similar to > poky/yocto but that is I think ultimately upto TSC members (with > consultation with membership). Hopefully they shall give their opinions > on the issue soon.
I would also encourage and support a pull model, driven by one or a few fairly neutral developers. > > I would say the obvious starting point is poky, then merge OE > improvements into that. I think this would be less work than stripping > down OE to core level. > > I think all the tools you have mentioned are bad examples of stuff to go > into core except possibly squashfs. Core should be purely enough to get > a busybox minimal image build in ext2/3/jffs/ubi given a machine.conf. > Basically enough to do board bringup and no more (with package > management capabilities). If core was recipes people "needed" it wouldnt > really be core fastcgi is pretty specialised bit of software. I'm not really sure what would go into core, but I kinda figured it would probably be something like poky/meta http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta The examples I gave are maybe not desirable in a minimal setting. Then again I feel core should probably be a little bit more than board bringup + busybox. I would hope that recipes like perl and python become part of core. Then again if oe core is similar to poky/meta the things I mentioned might fit in better than say libid3tag. If oe core is what is now in poky/recipes-core then I fully agree that the things I mention do not belong there (but probably glib-2.0 does not belong in a minimal layer either). http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta/recipes-core But I had the impression that most of the poky recipes should go into oe-core (or I misunderstood that part of Richard's email). It does not seem too wise to have two repo's with e.g. pango, zeroconf and matchbox. > > Core should probably have a build bot which crunches a standard set of > tests on each commit so unlike OE currently people don't wake up to bad > day of debugging OE. I'm not sure if that is needed (at least not on for every commit). If we are aiming for a pull model, the maintainer(s) are the only ones that can push and I would expect them to build things (maybe using a buildbot to cover different architectures) before pushing. Frans _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
