From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Tomas Frydrych <tf+lists.yocto@r-finger.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Date: Fri, 10 May 2013 10:05:25 +0100 [thread overview]
Message-ID: <1368176725.11129.9.camel@ted> (raw)
In-Reply-To: <518A7B37.8050308@r-finger.com>
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
next prev parent reply other threads:[~2013-05-10 9:23 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-08 15:11 proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer Tomas Frydrych
2013-05-08 15:23 ` Phil Blundell
2013-05-08 16:34 ` Tomas Frydrych
2013-05-08 15:23 ` Richard Purdie
2013-05-08 16:20 ` Tomas Frydrych
2013-05-10 9:05 ` Richard Purdie [this message]
2013-05-10 10:56 ` Tomas Frydrych
2013-05-10 11:32 ` Richard Purdie
2013-05-10 16:39 ` Tomas Frydrych
2013-05-10 17:19 ` Richard Purdie
2013-05-10 20:22 ` Otavio Salvador
2013-05-10 20:37 ` Mark Hatle
2013-05-10 21:15 ` Otavio Salvador
2013-05-13 9:30 ` Tomas Frydrych
2013-05-13 15:41 ` Phil Blundell
2013-05-13 15:44 ` Burton, Ross
2013-05-14 9:14 ` Tomas Frydrych
2013-05-14 16:55 ` Paul Eggleton
2013-05-15 9:19 ` Tomas Frydrych
2013-05-15 9:49 ` Paul Eggleton
2013-05-15 11:35 ` Tomas Frydrych
2013-05-15 11:53 ` Otavio Salvador
2013-05-15 13:20 ` Andreas Oberritter
2013-05-15 14:09 ` Paul Eggleton
2013-05-15 16:34 ` Tomas Frydrych
2013-05-15 16:54 ` Otavio Salvador
2013-05-15 17:22 ` Paul Eggleton
2013-05-15 17:30 ` Richard Purdie
2013-05-15 17:36 ` Otavio Salvador
2013-05-15 18:24 ` Paul Eggleton
2013-05-15 19:28 ` Otavio Salvador
2013-05-15 20:49 ` Phil Blundell
2013-05-16 9:01 ` Tomas Frydrych
2013-05-16 10:35 ` Phil Blundell
2013-05-16 11:21 ` Tomas Frydrych
2013-05-16 14:35 ` Phil Blundell
2013-05-17 12:30 ` Paul Eggleton
2013-05-16 9:22 ` Tomas Frydrych
2013-05-15 19:43 ` Richard Purdie
2013-05-16 9:21 ` Tomas Frydrych
2013-05-10 21:07 ` Martin Jansa
2013-05-10 22:18 ` Richard Purdie
2013-05-11 20:39 ` Otavio Salvador
2013-05-11 21:49 ` Richard Purdie
2013-05-14 16:23 ` Philip Balister
2013-05-13 9:31 ` Tomas Frydrych
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1368176725.11129.9.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=tf+lists.yocto@r-finger.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.