On Wed, 2013-05-08 at 17:20 +0100, Tomas Frydrych wrote: > On 08/05/13 16:23, Richard Purdie wrote: > > On Wed, 2013-05-08 at 16:11 +0100, Tomas Frydrych wrote: > >> I think it would makes sense to move clutter related packages from > >> oe-core into a dedicated layer: > >> > >> * AFAIK nothing in oe-core requires cogl/clutter/mx, > >> > >> * The packages in oe-core are effectively unmaintained, several upstream > >> releases behind, and pretty much unusable, > >> > >> * The somewhat random nature of clutter and cogl releases makes it hard > >> to sensibly manage these packages within the oe-core release cycle, but > >> a dedicated layer could follow the upstream developments. > >> > >> > >> I have started work on new clutter and related packages for use by > >> meta-guacamayo at https://github.com/Guacamayo/meta-clutter, but I'd be > >> more than happy for the layer to live somewhere else and become the > >> canonical location for clutter-related bits and pieces. > > > > I have no idea why you've always felt the need to maintain the clutter > > pieces in your own layer rather than interacting with the ones in > > OE-Core instead which I'd love to see better maintained. I'm not aware > > of any barrier that has prevented that. > > It's mostly a matter of timing. Clutter does not provide LTS releases, > it pretty much deprecates the previous stable branch as soon as new > stable branch is started, so tracking the upstream reasonably quickly > matters. The timing for the danny oe-core release and the arrival of > clutter 1.12 was such that it simply could not have made it into > oe-core. Needing 1.12 I had no option than to package it elsewhere. > > Yes, I could have submitted clutter 1.12 recipes to oe-core in some form > and shape in the last 6 months, and we would have had a less outdated > package in oe-core; but nevertheless outdated, since again the clutter > 1.14 release came too late to make it into dylan. I can see this > happening again and again.
The trouble is you can make this argument for every single piece of software in OE-Core. There was nothing stopping you pushing the 1.12 work back into what became dylan as soon as it opened up for changes. There was also nothing you maintaining an a branch of danny with the 1.12 updates backported into it. > If there is a good reason to maintain clutter, cogl and mx in oe-core, > then I'll make patches for 1.14, but I am not convinced there is a good > reason, and that everyone would be better served by a dedicated layer. A dedicated layer will still have timing issues, it will just move onto your personal schedule rather than the OE-Core one and whilst this will obviously suit you, it likely won't suit all other users. I suspect the bigger problem here is that clutter is hard to write recipes for since it needs to suit a number of different targets and configurations. Going to the effort of doing a generic implementation in OE-Core is hard, whereas creating your own layer means you can customise to your usecase and not worry about the other cases. I suspect your reply to this will be that anyone wanting to add other cases can send you patches. The implication is that the layer will become much more specialised/focused than the core recipes currently are. My preference would still be to fix up the recipes in the core, than have some specific branches for danny/dylan with the 1.12/1.14 components in if/as needed. We can create the core recipes so they're properly configurable to the different usecases. >From what I gather you're going ahead with meta-clutter anyway though :/. Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
