On Tue, May 31, 2011 at 9:57 AM, Koen Kooi <k...@dominion.thruhere.net>wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 31-05-11 15:31, John Willis wrote: > > Hi, > > > > This is something that came up in a conversation with Koen and I thought > it > > might be prudent to open the debate on the list to get some feedback > about > > the best way to approach this workflow without generating any ill feeling > or > > unintentional marginalisation. > > > > The scenario is quite simple... > > > > I have started to clean up and refactor the old OpenPandora recipes into > > something that aligns a lot more closely with OE-Core/Meta-OE and > > Meta-Angstrom going forward. This is purely a personal project (that I > > welcome help with) and is not necessarily tied to the main OpenPandora > > 'entity'. It is mostly for my own benefit as I have a few other > > projects/machines that I would like to apply the same working pattern. > > > > The forking and keeping bits in various trees with no very clear > distinction > > has always been a problem in the past and I want to minimise this going > > forward making best use of layers. I also want to ensure some ground > rules > > are set before I start committing or working on this in earnest (it's a > > 'free time pet project' for me so I don't want to waste my time creating > a > > rod for my own back, I can do that on a myriad of other projects ;)). > > > > At the moment I have https://github.com/openpandora/meta-openpandora, > this > > is the old OpenPandora overlay refactored into something more akin to the > > new layer layout. At the moment this layer has both machine level BSP > type > > stuff in it and the general 'not for mainline' OpenPandora overlay stuff > > that makes up the stock image (some custom libs, a logo and some > image/task > > files etc.). > > > > My plan is to move meta-openpandora into a true hardware BSP layer so > that > > you can just add this to give you full hardware support for the > OpenPandora > > to any existing combination of OE layers (e.g. kernel, bootloader, > netbase, > > formfactor, basefiles etc.). As part of this the rest of the 'not for > > mainline/cruft' stuff would need to find its way into a companion layer > (say > > meta-openpandora-vendor or some such). > > > > Is this a good idea? > > I think that's a very good idea. Let me know when you want to have the > openpandora BSP added to the angstrom bblayers.conf by default. > Awesome! I love my OpenPandora, but I find it difficult to align my BeagleBoard work with anything I can utilize on the Pandora or vice-versa today. Having a meta-openpandora with pre-built Angstrom packages, the ability to use Narcissus, etc. will be fantastic. As well, having the ability to use some of the OpenPandora experience tools, will be great if they are available for use. > > regards, > > Koen > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFN5PO2MkyGM64RGpERAtjNAJ0dKMXhaucKJi0lscVki9Vd0zn83wCguIFk > elmWgWXeeaWl8CyiG3nVP0o= > =0MTX > -----END PGP SIGNATURE----- > > > _______________________________________________ > Angstrom-distro-devel mailing list > Angstrom-distro-devel@linuxtogo.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel > _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
