OEDEM: Summary of the 'Splitting the tree' session

OEDEM: Summary of the 'Splitting the tree' session

[Michael 'Mickey' Lauer]

Hi guys,

here's the summary of the 'splitting the tree' session:

Nobody seems to disagree with splitting the metadata tree into more
managable chunks. The expected goals are:

1. Making it easier to find things,
2. Being able to mask whole groups out for improved parsing
3. Identifying core code which needs to always work, hence improving the
observed quality of OE.

Several criteria for splitting were discussed and there was a consensus
for splitting by functional complex. A tentative list of directories to
be used is:

base (10% underlying recipes)
toolchain
x11
framebuffer
gtk (includes gnome apps)
qte (includes opie and kde)
efl

The attendendees were well aware of all the inherent problems with
taxonomy and its different meaning to anybody in the first place as well
as that some recipes will always be difficult to categorize since they
are very flexible to configure. This did not prevent the consensus that
splitting up will be necessary to improve quality.

It was noted that oestats should be enhanced to be able to report a
subset of stats to start developing a test matrix of things which should
always work.

More discussion shall be carried on on this list and after the TSC has
been elected, it will make a final decision.

Cheers,

:M:

Re: OEDEM: Summary of the 'Splitting the tree' session

[Frans Meulenbroeks]

2009/11/12 Michael 'Mickey' Lauer <mickey@vanille-media.de>:
> Hi guys,
>
> here's the summary of the 'splitting the tree' session:
>
> Nobody seems to disagree with splitting the metadata tree into more
> managable chunks. The expected goals are:
>
> 1. Making it easier to find things,
> 2. Being able to mask whole groups out for improved parsing
> 3. Identifying core code which needs to always work, hence improving the
> observed quality of OE.
>
> Several criteria for splitting were discussed and there was a consensus
> for splitting by functional complex. A tentative list of directories to
> be used is:
>
> base (10% underlying recipes)
> toolchain
> x11
> framebuffer
> gtk (includes gnome apps)
> qte (includes opie and kde)
> efl
>
> The attendendees were well aware of all the inherent problems with
> taxonomy and its different meaning to anybody in the first place as well
> as that some recipes will always be difficult to categorize since they
> are very flexible to configure. This did not prevent the consensus that
> splitting up will be necessary to improve quality.
>
> It was noted that oestats should be enhanced to be able to report a
> subset of stats to start developing a test matrix of things which should
> always work.
>
> More discussion shall be carried on on this list and after the TSC has
> been elected, it will make a final decision.
>
> Cheers,
>

I think a split is a good idea, but I am not too keen on the name "base"
This suggests that it is kinda basic/core functionality. For a lot of
recipes this is not true. E.g. I am currently working on xmltv, not
really base functionality

As the split proposal is more along the graphics axe, I suggest that
instead of "base" we use something like "cmdline" or so (trying to
avoid the word "terminal" here).
Btw before someone proposes this: I'm also not too keen on a directory
"other" as it will become a junkyard of things.

Frans

Re: OEDEM: Summary of the 'Splitting the tree' session

[Detlef Vollmann]

On 11/12/09 09:38, Frans Meulenbroeks wrote:
> I think a split is a good idea, but I am not too keen on the name "base"
> This suggests that it is kinda basic/core functionality.
This is how I understand it.

> For a lot of
> recipes this is not true. E.g. I am currently working on xmltv, not
> really base functionality
And it wouldn't go into 'base'.

> As the split proposal is more along the graphics axe, I suggest that
> instead of "base" we use something like "cmdline" or so (trying to
> avoid the word "terminal" here).
> Btw before someone proposes this: I'm also not too keen on a directory
> "other" as it will become a junkyard of things.
You can't avoid that 'junkyard', whether you call it 'cmdline'
or 'other'.  And as that would be the place for those packages
that don't belong in any of the other categories, 'other' is
just the right name for that.

   Detlef

Re: OEDEM: Summary of the 'Splitting the tree' session

[Frans Meulenbroeks]

2009/11/13 Detlef Vollmann <dv@vollmann.ch>:
> On 11/12/09 09:38, Frans Meulenbroeks wrote:
>>
>> I think a split is a good idea, but I am not too keen on the name "base"
>> This suggests that it is kinda basic/core functionality.
>
> This is how I understand it.
>
>> For a lot of
>> recipes this is not true. E.g. I am currently working on xmltv, not
>> really base functionality
>
> And it wouldn't go into 'base'.

In the current proposal then there is no place for this recipe.
Guess we need to define one (and also define what should go in base.

Thinking of it it might be worthwhile to have a hierarchical clustering.
In that case xmltv could reside in a subdir of mythtv
(actually currently we already have a one level clustering as dirs can
contain multiple recipes for multiple packages (see e.g. perl)

>
>> As the split proposal is more along the graphics axe, I suggest that
>> instead of "base" we use something like "cmdline" or so (trying to
>> avoid the word "terminal" here).
>> Btw before someone proposes this: I'm also not too keen on a directory
>> "other" as it will become a junkyard of things.
>
> You can't avoid that 'junkyard', whether you call it 'cmdline'
> or 'other'.  And as that would be the place for those packages
> that don't belong in any of the other categories, 'other' is
> just the right name for that.

Well other is not yet in the proposal :-)
And left or right junkyard packages will also exist in the other trees.

BTW there may be room for a dir with packages that are
unmaintained/unsupported or whatever you want to call it.

Frans

Re: OEDEM: Summary of the 'Splitting the tree' session

[Detlef Vollmann]

On 11/12/09 09:29, Michael 'Mickey' Lauer wrote:

> base (10% underlying recipes)
> toolchain
> x11
> framebuffer
> gtk (includes gnome apps)
> qte (includes opie and kde)
> efl

There are quite a number of packages that could be built for
X11, framebuffer or qte.  I'd propose a separate directory
for that.
And of course something like 'other'.
And I'd actively discourage to have much more, as then the
problem that a package belongs to more than one category
grows, which counteract the goal to make it aesier to find
things.

   Detlef