Re: Yocto Project and OE - Where now?

[Frans Meulenbroeks <fransmeulenbroeks@gmail.com>]

2011/1/22 Tom Rini <tom_rini@mentor.com>:
> On 01/19/2011 02:25 AM, Frans Meulenbroeks wrote:
>>
>> 2011/1/19 Frans Meulenbroeks<fransmeulenbroeks@gmail.com>:
>>>
>>> 2011/1/18 Koen Kooi<k.kooi@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
>
> Here's what I worry about.  It shouldn't take an overly active maintainer
> for most recipes.  Sure, some programs (and of course the toolchain) require
> some care and knowledge.  But lots of things don't. I fear we're trying to
> get to the point where if someone is going to submit a recipe for some
> program they need to sign up to make sure it's always pointing to the most
> up to date upstream and other mandates.  One of the strengths of OE today is
> that it's not overly burdensome to submit changes back and have them
> accepted.

Tom, good points.

We should not make it too difficult to submit recipes (but I would
appreciate if submitted recipes adhere to some to-be-defined minimal
set of QA rules).
But it would help to know if a recipe has an active maintainer or not.
I think I would be more inclined to fix issues or update the recipe in
case it is unmaintained.
If a recipe is maintained, I would probably first see if the
maintainer takes action (and trigger him/her). It also makes clear who
to contact  if there is an issue. Now it is not always too clear who
is working on what).

The issue is also that if you pick up a recipe that is (or seems)
unmaintained and update it, and make a mistake there is always someone
around the corner with some nasty remarks, making it not too
interesting to work on these recipes.

Wrt your coment on "submit changes back and have them accepted". I
fear I see this not as a strength. The process is ok, but it does not
work too well for those unmaintained recipes.
Typically the unmaintained recipes are in some corner of OE and not
many people care about those. So if you submit a patch to these, it is
quite common to get no feedback at all.
A policy saying: submit patch, wait two weeks for feedback, if none
given, send a ping, wait another two weeks still no feedback, does not
work too well (but the scenario I sketchted happens too often.
Now after this process I feel I can apply the patch (with 4 weeks
delay, which seems quite a lot if the patch is small), but if the
submitter has no commit rights it'll just land in patchwork waiting
for someone to pick things up.
Especially the latter scenario will cause that that person submitting
the patch will give up after submitting one or two patches.
Maybe I'm drawing a black scenario, but this is what I see happen.
>
>>>
>>> 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.
>
> They are example programs for directfb which also means they are handy demo
> programs for "hey, is directfb working on my platform and looking right".

I understand that. and I am not saying that the recipe should go. What
I wanted to say is that if we have a 1.2.0 version (of a recipe for
example progs) what is the point to keep also version1.0.0 around.
It is unpinned so I see little reason to keep 1.0.0. Of course 1.2.0
should be kept.
>
>> 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.
>
> I suppose it could be updated to 1.2.10, yes.  And directfb is enough by
> itself, although it would be nice if we went and took a stab at making it an
> option to use rather than X, when possible again.

The issue at hand is that there is no recipe directfb 1.2.8 any more.
We only have 1.4.6. However the patch files for 1.2.8 are still left,
but there seem no users left of this dir.
So basically unused files have been moved to meta-oe. I doubt that
that is desirable.
>
>> 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.
>
> OK, but what's wrong in this directory?  It's on known to work for someone
> versions, I don't see legacy staging and iirc the pkg-config changes aren't
> hacks but fixing upstream.

As mentioned above there are files in it that are not used by any
recipe, it contains a recipe that is probably better removed (the
1.0.0 version of the examples, keeping the 1.2.0 version as the sole
version).
I can also imagine the files dir could be renamed or split (I haven't
really checked if the patches are for one recipe or shared, but I
suspect the former).
I did not peek into the recipes itself but I can imagine they could
also be given a more standard layout (oe-stylize).

Nothing dramatically, just some small changes that gives things a more
constent look (both at the directory level and at the content level).
I fee the move to meta-oe could be used to raise the bar a little bit.

Wrt the LICENSE field and the recipe names (and your next post)..
I was just coining an idea. I feel it is useful to have an indication
why there are multiple versions of a recipe instead of one.
Especially in the case of recipes that have no maintainer this seems
useful information, as in that case someone who wants to change the
recipe gets an idea why it is useful to fix the old recipe too.
(the options for such a person are: fix old recipe too, if no one uses
it, it is a waste of time, do not fix the recipe and leave a possibly
broken recipe, or remove the old recipe and risk that there is a
whiner who apparently does not care to fix the recipe, but does
complain if someone does a best effort attempt to fix things.

Encoding this in the name makes it very explicit what the reason is to
have two versions and reduces the chance of errors.

For gplv2/v3 LICENSE can be used, but that does not help if e.g. we
want to keep an old version of foo because the footprint is much
smaller.
So either we need a different name, a comment in the recipe or a
README like file describing the differences).

With LICENSE the chance is a little bit higher that someone accidently
overlooks that that is the reason for having two versions. Name
encoding makes it more visible.
But if people feels relying only on LICENSE because otherwise the
namespace becomes too cluttered, that is also fine with me.

Best regards, Frans