[oe] Splitting meta-oe?

[akuster808]

On 02/20/2017 03:18 AM, Martin Jansa wrote:
> On Sun, Feb 19, 2017 at 07:31:03PM -0800, Richard Purdie wrote:
>> On Fri, 2017-02-17 at 14:45 -0500, Philip Balister wrote:
>>> And I'm with these gyus. Splitting the git repository doesn't solve
>>> any underlying problems. The real problem from my point of view is
>>> very few of use are actually paid to maintain the layers we maintain.
>>>
>>> Employers want to pay things they profit from, and that is not paying
>>> someone to maintain "core infrastructure".
>>>
>>> Layer maintainers interests change over time, and you burn out
>>> supporting people who get to do all the cool stuff with the layers
>>> you maintain. In the end, you get all the crap and non of the glory.
>>> Within this list, most people appreciate your work. Outside the
>>> community, people completely underestimate the amount of work
>>> required to keep the ecosystem running.
>>>
>>> Yeah, add my name to the list of cranky people.
>> I do think this is a valid question that Ross asks and that whilst the
>> first quick reaction is "no", its worth thinking about the pros/cons.
>>
>> The pros to me would be about better test time on patches and in theory
>> more specialist knowledge. This isn't to say Martin/Joe don't do a bad
>> job but the size of meta-oe does mean there are limits.
> If I continue to do the same "bitbake world" builds to test as many
> layers as possible, then the test time will be exactly the same even if
> we split meta-oe repository into 10 smaller repositories, probably a bit
> longer for fetching all those small repos.
>
>> The cons are more around finding suitable layer maintainers, which as
>> we all know are hard to find.
>>
>> I'd probably suggest that:
>>
>> a) We need to encourage/empower more people to maintain layers
> I think we lack people willing to contribute patches for recipes they
> use, not people willing to merge them into corresponding repository.

Correct. This does not solve the underlining issue.

We do need to think what to do about black listed recipes. Suspect its a 
separate thread.
>
>> b) Having better infrastructure, tools and processes that help a) would
>>     therefore be desirable.
Are you saying we have to make it easier for people to participate?

Please Donate to OE so we can improve the infrastructure.

If you split out each layer, each maintainer will have there own process 
that works best for them.

>> c) We need to be willing to separate out pieces for people to maintain
>>     in such layers. It might not always work out but we should be
>>     willing to try.
so a layer per recipe would be the best in this case. This wont bring in 
more help.

>>
>> As for the comments about core changes, I really do try hard not to
>> make them in many ways. The ones we do make, I'd hope are for the right
>> reasons.
> Yes everybody agreed that RSS is good change and worth breaking unused
> recipes.
>
>> No easy answers but don't shoot Ross for asking what I think is a
>> reasonable question.
> I wasn't trying to shoot him, but I still don't see how more
> repositories solve the issue of unused recipes and lack of people
> contributing to fix those still in use somewhere.

There are other implications to think about after the break-up.

1) What happens to meta-openembedded repo and or layer?
2) Do we adopt the K.O model where the sub-layers are maintained 
independently and then merge to meta-openemedded ( this could offload 
work and improve quality).
3) How do we sync branching? if we do #2, that is easier.
4) Since the maintainers will have write permissions for their own 
layers, does this mean we no longer have overall architects (a.k.a 
Martin & Koen)
5) How do we ensure the same level of support master currently benefits 
from Martin's world if those responsibilities transfer to other layer 
maintainers?
6) How do we enforce dup recipes?

If we decide to stop having a meta-openembedded layer;
7) How long do you keep it around?
8) Will the stable branches prior to the breakup only be in the aging 
meta-openembedded layer and not new scheme?
9) Do we have a meta-openembedded-classic?



>
> And I still think it's easier to send a patch to fix something instead
> of volunteering to be maintainer of the layer with the one recipe you're
> interested in fixing to merge your fix yourself.
Agree

- armin
>
> Cheers,
>
>
>