On Fri, Apr 08, 2011 at 12:31:25AM +0100, Neil Jerram wrote: > Martin Jansa <[email protected]> writes: > > > In short: > > There are couple of layers > > oe-core with well tested core stuff and higher quality requirements for > > patches > > meta-oe for recipes/classes and other usefull stuff from "old" oe > > meta-efl similar rules like meta-oe but having only stuff related to efl/e17 > > meta-shr recipes/classes used only in SHR > > > > meta-angstrom recipes/classes used only in Angstrom > > meta-ti bsp layer for ti devices > > etc... > > > > each layer has own maintainers which apply stuff sent in form of git > > pull requests, so there is lower chance that someone will accidentaly > > break something (something like linux kernel is using for subtrees) > > Ah, OK. And this is what you're overall calling shr-core?
Yes, it will replace shr-unstable when it's ready, but before that, I'm calling it shr-core (as shr based on openembedded-core). Currently I'm pushing most patches to both repositories (old OE master and appropriate layer), when I consider shr-core stable enough to be called shr-u I won't push it to OE master (and probably nobody else will). > I suppose, then, that this may be the "happy medium" that I was looking > for in the previous email? I hope so. > And if it is, would you agree that we then probably won't need SHR-T any > more? Instead, we can just snapshot SHR-C every now and then. SHR-T are just snapshots of SHR-U every now and then already, so with SHR-C becoming new SHR-U later it should stay the same. Cheers, -- Martin 'JaMa' Jansa jabber: [email protected]
pgpKLDBrGLSK9.pgp
Description: PGP signature
_______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
