[oe] Yocto Project and OE - Where now?

[Frans Meulenbroeks]

2011/1/19 Frans Meulenbroeks <fransmeulenbroeks at gmail.com>:
> 2011/1/18 Koen Kooi <k.kooi at student.utwente.nl>:
>  if we make the delta between the 3 be just
>>> the SRC_URI + checksums?
>>
>> Something like:
>>
>> * keep gplv2 around if upstream switched to gplv3 at some point
>
> agree; as said before suggest to reflect the switch in the name of the recipe.
>
>> * allow old stable, stable and dev (e.g. glib 2.24, 2.26 and 2.27+git)
>
> I'd say retire old stable after a while (e.g. after stable is there
> for half a year, unless of course there are compelling reasons to keep
> it).
> Wrt dev: if we want to go to a maintainers model similar to u-boot and
> linux, I would expect this to live in a separate branch or layer.
> Once proven stable the maintainers pulls it into the core archive.
>
>> * allow active contributers some leeway to test multiple subreleases
>> (e.g. busybox 1.18.[0-99]
>
> Again here, I feel it is much better to put it into a different branch
> or layer, and once stable it is pulled into the mainline.
> Again similar to what Linus and Wolfgang do.
>
>> * The maintainer can have as many versions as he wants to.
>
> my preference: not in the main layer.
>
>> * toolchain is exempt from all that since having 20 binutils versions is
>> sometimes needed when building for 20 different archs[1].
>
> Fully agree.
>>
>> But I seriously think we are overengineering this. We should have people
>> actually working on oe-core and meta-oe reach a consensus when
>> encountering problems.
>
> I beg to disagree on this.
> We have a unique opportunity at hand to improve, so it seems wise to
> raise the bar quality wise.
>
> E.g. wrt what Richard wrote in the start post
>
> [quote]
> * Creation of a subset of metadata that has a consistent high quality
>  standard:
>   - removal of legacy components (pkgconfig hacks, libtool hacks,
>     legacy staging, unneeded compiler arguments)
>   - consistent metadata layout, spacing, use of variables
>   - migration away from outdated practises (e.g. use BBCLASSEXTEND)
> [/quote]
>
> I feel when migrating recipes we should also assure that they adhere
> to a certain quality standard. That would need us to define a minimal
> standard though.
> Currently I feel we are just moving recipes, only fixing what is
> really needed to get things running (like removing legacy staging)
> whereas we could do much better.
> There are currently some things in OE that could use some improvement
> and we should take the opportunity to improve.l
>
> And yes, I have no problem in spending time to improve things, but if
> there is no consensus on where we should go this is not going to be
> effective (and actually makes it harder to improve quality wise).
> To take the bikeshed analogy up again. It does not really help if
> everyone start to paint in his own favourite color (unless maybe if
> you are still stuck in the flower power era).
>
> Frans
>
I know it is fairly schizofrenic to reply on ones own post, but I just
peeked into the meta-oe layer and found an excellent case on what we
should try to avoid when bringing over recipes from oe to meta-oe.
path: root/recipes-graphics/directfb
Mode	Name	Size	
d---------	++dfb	48	logplain
-rw-r--r--	++dfb_1.0.0.bb	588	logplain
d---------	directfb-1.2.8	50	logplain
d---------	directfb-1.4.6	41	logplain
-rw-r--r--	directfb-examples_1.0.0.bb	406	logplain
-rw-r--r--	directfb-examples_1.2.0.bb	409	logplain
-rw-r--r--	directfb.inc	2038	logplain
-rw-r--r--	directfb_1.4.6.bb	615	logplain
d---------	files	415	logplain
d---------	fusionsound-1.1.0+git20070709	54	logplain
-rw-r--r--	fusionsound_1.1.0+git20070709.bb	1479	logplain
-rw-r--r--	lite_0.9.26+cvs20070207.bb	1140	logplain

Why is there a directfb-examples_1.0.0.bb? In OE no-one is pinning
this version, and given the fact that these are examples there is
probably little reason to keep it.
Something similar for directfb-1.2.8. Maybe I overlooked things but I
could not find a the user of this dir. I guess it could be gone.

If we want to improve on quality it is probably not a bad idea to at
least have a checklist with improvement actions that should be done
when migrating recipes (e.g. remove stale patches, unused & unpinned
older versions etc etc). I know it takes time, but it can also
increase the overall quality. Let's take that opportunity.

Frans.

PS: as part of the migration it might also be a good plan to see if
recipes should be updated. I don't know too much about directfb but
maybe it makes sense to move to newer versions of e.g. fusionsound and
lite.