[oe] Yocto Project and OE - Where now?

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Wed Jan 19 08:45:44 UTC 2011


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




More information about the Openembedded-devel mailing list